# Addy Osmani - Software Engineering - The Soft Parts (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/38504383) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Addy Osmani]] **Full Title**:: Software Engineering - The Soft Parts **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [readwise.io](https://readwise.io/reader/document_raw_content/40915912) **Host**:: [[readwise.io]] **Highlighted**:: [[2024-03-09]] **Created**:: [[2024-03-09]] ## Highlights - When starting off a new project, begin with "boring" tech (but well understood) and then intentionally decide out of it to select the best tool for a problem. ([View Highlight](https://read.readwise.io/read/01hrg4h1b3txd29n3y1p86wybq)) ^690176787 - Take half an hour each day to read a chapter from a textbook, listen to a technology podcast, read development blogs or learn a new programming language. ([View Highlight](https://read.readwise.io/read/01hrg4m1k4d2z3wrv5y89vh8ge)) ^690177074 - After the initial crunch, another way to think of evolving your role is towards being a caretaker, rather than an owner. A caretaker might focus on scaling themselves out. ([View Highlight](https://read.readwise.io/read/01hrg4q5e4r583athcx7zek72r)) ^690177156 - One of the greatest skills you can master is learning how to learn. This should be a priority over say, just going deep on particular programming language or framework. ([View Highlight](https://read.readwise.io/read/01hrg4r56ttmk17e16mg41c44x)) ^690177181 - Earn experience by writing a lot of relevant code or learning from existing code. The results should help you write efficient code in that language. ([View Highlight](https://read.readwise.io/read/01hrg4sfdaypym699nc2sfrxys)) ^690177206 - Write code specifically for the problem at hand, but try to spot places where you can afford to make it a little generic. ([View Highlight](https://read.readwise.io/read/01hrg4tpp47q5yt263dqdhfdwr)) ^690177263 - I prefer to take the middle ground between extreme abstraction and extreme simplicity by making code just a little generic. The AHA (Avoid hasty abstractions) principle promotes a similar idea (https://bit.ly/softskills-aha). ([View Highlight](https://read.readwise.io/read/01hrg510a4kgmh61ybhjrhqc8m)) ^690177528 - I've worked at many companies where folks assume what is legacy code is untouchable or is designed the way it is for a good reason, lost to the sands of time. This can lead to fear of change where you just keep on adding abstractions to a weak foundation. ([View Highlight](https://read.readwise.io/read/01hrg5b4pbd7kr9qtywwb65jmv)) ^690178460 - While one person can document the design, the actual design process occurs during a series of whiteboard meetings, random in-person discussions, slack threads, or email/phone discussions. Only after you put it down on paper can you identify contradictory commitments and see if the different parts you had discussed fit together. ([View Highlight](https://read.readwise.io/read/01hrgd2z0d6kzkfwvmj34cnrkn)) ^690198399 - Very often you will find that it's better to make any decision rather than no decision at all. It at least allows others to know what direction you're leaning towards. ([View Highlight](https://read.readwise.io/read/01hrgdeanqr4t9yr9xn76385c6)) ^690198908 - Teach your team to fish. Don't always solve problems for them, but gently guide them to develop the skills to solve themselves. ([View Highlight](https://read.readwise.io/read/01hrgdhnmkw83q5mxshg1dwpdf)) ^690199646 - The world’s best engineering feats are accomplished by a team of engineers, not individuals. So, if you are trying to accomplish more, or show you're ready to become more “senior” in your company, multiply your effectiveness through collaboration and mentorship. Demonstrate how this adds value not only to yourself, but to other members of your team. ([View Highlight](https://read.readwise.io/read/01hrgdkpa81re0c5yxthnngfjs)) ^690199697 <!-- New highlights added March 16, 2024 at 11:37 AM --> - Mentoring need not be a formal process. You can look for opportunities to mentor others or allow yourself to be mentored even informally. ([View Highlight](https://read.readwise.io/read/01hrk4hwnv1hf4rr0mx2mab1wk)) ^690652658 - Mentoring is about guiding people to discover answers themselves rather than giving them ready-made solutions. ([View Highlight](https://read.readwise.io/read/01hrk4j5tkrt9fcnc15grs195y)) ^690652690 - If someone fails to figure out solutions by themselves, show them how you would approach the problem and why you chose a particular pattern to solve it. ([View Highlight](https://read.readwise.io/read/01hrk4jqng6brxf6c02r21tjwg)) ^690652858 - Update estimates as your understanding of problems improves ([View Highlight](https://read.readwise.io/read/01hrk4nxz3t9trnkdwa134t08h)) ^690653069 - I have found that consistently prioritizing tackling technical debt is sometimes hard as you can't always quantify the bugs that didn't manifest or outages that didn't happen because you "paid debt down enough". Sustaining team interest in this kind of work and rewarding it during performance reviews is also really important. The cost of the "cure" however can be so much higher once problems really start to pile up over time. ([View Highlight](https://read.readwise.io/read/01hrk4qfqcrr7mvymjedhy673f)) ^690653375 - Instead, you want to ask "what's the right end-to-end solution to this problem?" and walk back to what project or changes to a series of projects will holistically address this need best. ([View Highlight](https://read.readwise.io/read/01hrk6a4c9ebykyhr200kns73r)) ^690660170