I concluded reading a book titled Software Engineering: The Soft Parts about a month ago. Addy Osmani wrote the book — Think of a resource that empowers you to become a great employee, an efficient leader and a high-performing engineer—that is precisely what the book seeks to achieve.
While I read, I wrote. I also pondered some of my past experiences; some of the information here was my reality, and others still needed to be. Sharing this might be helpful to a ton of people. Hence, here are some learnings I gathered from my most recent reading:
1. Set Career Goals
As much as you can, write down goals for your career and ensure that the code you write daily helps you steadily hit that goal.
2. Invest in Critical Thinking
Try to make your thoughts clear before you start writing code; use pen and paper to visualise if necessary.
3. Divide And Conquer
Learn to Divide and Conquer: always break seemingly large problems into lower bits.
4. Understand The Fundamentals
In software engineering, the fundamentals can be classified into macro and micro levels. The macro level entails programming concepts like data structures, algorithms, architecture and performance optimisations. The micro level involves the language, frameworks or tech stack. The macro level should be of utmost concern as they are inherited essentials of the micro level.
6. User Always Comes First, Then Technology Follows
Examine what the user needs, and work backwards by trying to use the technology that bests suits the user’s requirements and needs. Sometimes, there are personnel, hiring or speed constraints. Regardless choose the best option between these constraints.
7. Learn Everyday
Learn something new every day.
8. Read Other People’s Code
Read the source code of the new and bubbly frameworks you admire—“The main value in software is not the code produced but the knowledge accumulated by the people who produced it.”
9. Leaders Also Make Mistakes
It’s powerful for leaders to admit when they don’t know something; good leaders also recognise when they make mistakes.
10. Be a T-Shaped Engineer
Aim to be a master of a skill and to have basic knowledge of other skills to get by on a project—a T-shaped engineer. Sometimes we love to satisfy our curiosity and explore new technologies, but building capacity in a particular tech stack would make you a force to reckon with.
11. Less (Code) is More
Less code is always better code; adding redundant functionality increases the complexity of your code.
12. Technical Debt Isn’t Always Bad
Always prioritise speed, progress and simplicity; sometimes, this might result in technical debt. A technical debt is okay if the cost of the debt has been counted, and plans to pay the debt as soon as possible are implemented.
13. Abstract Complex Code
When complex solutions require complex code, a good practice is to abstract complex code. For example, complex functions, interfaces, or classes can be abstracted in a separate file, package or module.
14. Not All Old (Code) is Gold
While there might be good reasons for some specific code to exist in production, when working with legacy code, we should still question whether every line is needed or could be done better.
15. Define Project Requirements and Completion Criteria
Defining the criteria for a project’s completion helps save time and unnecessary revisions. We must also remember that we are never satisfied with every feature we have built.
16. Make Deployments in Digestable Sizes
Releasing updates in smaller chunks to users help to manage risks better. Large changes could have more significant impacts on users.
17. Read Error Messages and Stack Traces
Always read error messages and stack traces before looking for solutions elsewhere.
18. Document Systems and Processes
Creating documentation for your internal design system is super important, and it helps all stakeholders on the project in the long run (new and old)
19. Communication is The Most Crucial Part of Your Job
Admittedly, Communication can be challenging for engineers, but it is extremely important — possibly the most crucial part of our job.
20. More Growth Equals More Communication
As we grow in our roles and climb the corporate ladder, we must understand that this equates to more communication. Promotions almost always require us to have better communication skills.
21. Know When to Speak in Technical Terms
Avoid using OVERLY technical jargon when talking to a business-focused stakeholder. However, a business person needs to be aware of technology decisions from a low level.
22. Simplify Product Decisions and Outline Possible Implications
When talking to decision-makers like Product Managers, it is best to describe available options and the implications of all of these options.
23. Progress Updates Are Only Concerned With Hitting Project Goals
When giving status/standup updates, we should always provide an update that is particularly relevant to the project’s goals.
After discovering these crucial lessons, I have since tried to be conscious of them and act accordingly. There are still many more lessons from the same book, and I will share those in another article.