Books for software engineers and managers
Categories:
Favorite,
CTO,
Engineering Manager,
Tech Lead,
Product Manager,
Startup Founder
How strongly do I recommend Ask Your Developer?
9 / 10
Ask Your Developer is perfect for people who want to read 1-2 books per year about software. Written by the founder and CEO of Twilio, this book is conversational and will plant a few ideas in your mind at both strategic and tactical levels.
Top Ideas in This Book
Jeff Bezos realized early that Amazon was a software company not a retail company. Amazon’s ability to develop custom distribution software differentiated them from competitors using generic systems.
Businesses need employees to be their best. Written differently, businesses need to cultivate systems and environments that enable employees to be their best, to reach their full potential.
The authors of Peopleware describe a similar situation, in which the highest performing teams obsess about being the best and pursue that vision relentlessly.
You can’t just tell people to experiment in hopes of driving innovation. You must invest time and money into infrastructure to decrease the marginal cost of experimentation, which opens the door for innovation.
Nearly everyone in Coders at Work said math isn’t that important and here the founder of Twilio repeated that message, saying that programming is more like art and music than math.
This is one point I think recruiters, product managers, and designers misunderstand about developers. They think most software engineers are analytical, organized, and introverted. They have formed a persona that doesn’t match reality. Most developers love creative expression including visual art and design.
When you appreciate the creativity required to build software, you connect more deeply with the humans building it and create the opportunity for great products.
Autonomy, mastery, and purpose motivate people. To achieve autonomy you must have the ability to make decisions. The only autonomy that matters is the ability to do something differently than your boss would.
When the system went down last, how did individuals in the organization react? Was there panic, fear, blaming, resentment, isolation? You will probably need to dig further than surface level answers as many teams will say they do blameless post-mortems but on a deeper level you find trust issues cross-functionally or even within the team.
Many organizations employ stream-aligned teams but pride still comes down to membership in a functional group like engineering. While you do want to cultivate a culture of engineering, each engineer’s first team should be the stream-aligned team they belong to.
Growing companies (or “well established” companies) can get process-happy, believing that growing up means imposing a lot of constraints to reduce risk of deviation. Beware companies where internal considerations like consistency, turf wars, and control outweigh external considerations like time to market and product strategy.
Customers can be internal or external, but everybody should be working on a customer problem and understand who the customer is.
As a hiring manager that interviews software engineers, too many candidates talk about what they’ve built but fail to demonstrate an understanding of why they’re building that functionality or who the customer is.