The Effective Engineer
is a book recommend by many excellent engineers. I expect that after reading this book I spend my time more efficiently as a developer. Many parts of the books overlap with the concept of DevOps and Scrum nowadays you know when you already work for years. The rest parts that I don’t have that clear concept after reading the book, I document and summarise them here.
is a book recommend by many excellent engineers. I expect that after reading this book I spend my time more efficiently as a developer. Many parts of the books overlap with the concept of DevOps and Scrum nowadays you know when you already work for years. The rest parts that I don’t have that clear concept after reading the book, I document and summarise them here.
Focus on high value activities
- How can I complete this task using less effort(time&brain power)?
- How can I increase the value produced by this activity?
- Is there something else that I could spend my time on that would produce more value?
Example:
- Automating parts of the development or testing process that have thus far been done manually, so that you can iterate more quickly.
- Prioritizing tasks based on how critical they are for launch so that you maximize the value of what you finally ship.
- Talking with the customer support team to gain insights into the customers’ biggest pain points, and using that knowledge to understand whether there’s another feature you could be working on that would produce even more value with less development effort.
Optimize learning
At work
Study code for core abstractions written by the best engineers at your company. Read through code in some of the core libraries written by early engineers. Start with ones that you’ve used before. Ask yourself if you would’ve written similar code and how you might learn from their examples. Understand why certain choices were made and how they were implemented, and see if earlier versions of code were rewritten to address shortcomings. You can also do the same with any well-designed, open source projects that your company uses or is considering using.
Write more code. If you feel that programming is your weak point, shift time away from other activities like meetings and product design, and spend more of it building and writing code.
Master the programming languages that you use. Read a good book or two on them. Focus on developing a solid grasp of the advanced concepts in that language, and gain familiarity with core language libraries. Make sure that at least one of your languages is a scripting language that you can use as your Swiss army knife for quick tasks.
Send your code reviews to the harshest critics. Optimize for getting good, thoughtful feedback rather than for lowering the barrier to getting your work checked in. Ask for a more detailed review on those implementations you’re not as confident about. Discuss software designs with your company’s best designers in order to avoid writing great code for a design that doesn’t work well.
Enroll in classes on areas where you want to improve.
Participate in design discussions of projects you’re interested in. Don’t wait for an invitation. Ask project leads if they’d mind you being a silent observer or even a participant in a design meeting. If mailing lists are open internally, add yourself or read through key conversations in the archives.
Work on a diversity of projects. If you find yourself always doing similar tasks using similar methods, it’s going to be hard to pick up new skills. Interleaving different projects can teach you what problems are common across projects and what might just be artifacts of your current one. Moreover, research on learning confirms that the interleaved practice of different skills is more effective than repeated.
Make sure you’re on a team with at least a few senior engineers whom you can learn from. If you’re not, consider changing projects or teams. This will help increase your learning rate for the remaining 80% of your time.
Jump fearlessly into code you don’t know. After years of observation, Bobby Johnson, a former engineering director at Facebook, concluded that engineering success was highly correlated with “having no fear in jumping into code they didn’t know.” Fear of failure often holds us back, causing us to give up before we even try. But as Johnson explains, “in the practice of digging into things you don’t know, you get better at coding.
Outside Work
Learn new programming languages and frameworks. New skills can expand your mind and teach you how to think in different ways. Keep a running list of the programming languages, software tools, and frameworks that you want to learn, and set goals to spend time and master them.
Invest in skills that are in high demand. You can check by job postings
