This is a very pragmatic book, and it is also quite thin. The author is Addy Osmani, the person in charge of the Google Chrome project. The content is a compilation of his past experiences and soft skills guidance.
I will note down some parts of the book that I personally found impactful, there are 33 points.
notes
Mastery of technology means delivering high value per hour worked. This means you can identify which tasks bring value and help the team focus on those tasks. It also means knowing how to avoid work that does not add value. The best engineers can even guide the entire team to avoid work that does not add value.
Critical thinking is thinking purposefully to form your own conclusions. It allows you to focus more on root causes and avoid potential future problems.
Avoid falling into the trap of assuming correlation implies causation. Someone with critical thinking may question such assumptions and ask why we believe it to be true.The long-term value of learning fundamentals is their transferability, while the short-term value is helping you make better decisions. Transferable skills have macro and micro aspects. Macroscopically, the basic principles of programming languages are mostly the same, and frequently applying the basic principles can generate tremendous value.
Microscopically, syntax may be familiar but the skills are not transferable. You should also not overfocus on fundamentals, the key is to learn for application.
Having a solid foundation of knowledge allows you to make better decisions and go further, such as considering frameworks or avoiding choosing the wrong technologies.
"You haven't mastered a tool until you understand when it
should not be used." - @kelseyhightowerFocus on the user/developer experience, don't make decisions based on specific solutions (e.g. just using Laravel because it's good).
Use boring (proven) technologies, then consciously choose the tools most suited to solving the problem. FOMO may not be an effective approach in tech - understanding how to use things is important, but the focus should still be on delivering value, unless those technologies can increase the value you produce.
The best time to learn new technologies is by using new projects - use the Feynman learning technique to accelerate learning.
To enable a project to evolve, become its caretaker rather than its owner - document it well so it can continue when you're gone.
The value of software lies in the accumulated knowledge of its producers, not the code itself - don't rewrite code for no reason, you're discarding collective knowledge.
YAGNI (You aren't gonna need it) means don't add features until needed, focus on what really delivers value. But maintain appropriate abstraction - avoid premature abstraction (AHA). Decoupling solutions for specific problems while trying to extract reusability is better.
The best modules are those with maximum benefit and minimum cost. Interfaces should be narrow, functionality deep.
A good mindset for legacy code is to not assume every line is relevant - understand it then remove unnecessary parts.
Defining "done" is important when tackling problems - avoids unnecessary future revisions. This could include meeting acceptance criteria, passing tests, documentation, etc.
Debug messages show the truth, don't keep making small changes trying to fix issues.
Design docs are part of software engineering, not an afterthought. Coordinate reviews of design docs, compare to original as it evolves to validate addressing issues.
Focus communication on kindness - may take more time but makes others more willing to communicate for effective outcomes. Avoid jargon, match vocabulary to audience.
Saying no is better than over promising.
A senior engineer should be skilled at designing software systems and human/team systems. You can lead a diverse engineering team, delegate tasks, guide them to focus on code quality, performance and simplicity. Provide feedback when needed, defend them when necessary. You should also be able to market yourself, your work, and problem-solving abilities for exposure in the organization. Overall, manage relationships well internally and with management.
Guide junior engineers to ask the right questions in a way that lets them know you're glad they asked.
Strongly defend your views but re-examine assumptions when new evidence arrives.
Teach the team to fish - coordinate internally and externally, aim to increase team output. More senior means focusing more on managing relationships with management and the team.
Team efficiency is efficiency - accept imposter syndrome, it can motivate you to learn.
Understand the business model, your code hugely impacts business logic. Insight into commercial software is key to influencing, as you're closer to the market so naturally do impactful things.
Start from the user experience and work backwards to required tech.
Mentoring is guiding - suggest ideas for mentees to try. If they can't solve a problem, show your approach and thinking for reference e.g. debugging steps rather than the answer directly.
Don't try to do too much at once, focused deep work time is very important.
Estimates can be updated anytime, software estimates are inherently complex until requirements are deeply understood, then they become more accurate. A better way is rough estimate, detailed estimate, staged rollout.
A leader confidently admitting not knowing something is powerful. This confidence reduces expectations for senior engineers to know everything. You absolutely don't need all the answers, but admitting you're human and committed to solving problems together is most important.
Tech debt repayment should be regular time allocated by tech leads for cleanup - prevention over cure.
Focus on the problem - issues in other projects may also be issues in yours.
"Surround yourself by excellence and work with people who are
the best as what they do" - Brian Staufenbiel
source
https://addyosmani.com/blog/software-engineering-soft-parts/
Top comments (0)