Books for software engineers and managers
How strongly do I recommend It Doesn't Have to Be Crazy At Work?
6 / 10
Like all the Basecamp / 37signals books, It Doesn’t Have to Be Crazy At Work can be read in a few hours, cutting through the nonsense and offering some common sense advice for product development teams.
This book won’t offer you any earth shattering ideas, but will act as therapy for readers feeling overworked and stressed.
Top Ideas in This Book
Product design ideas apply to designing your company and culture.
The authors argue that your best product should actually be the company itself. By focusing on the company, you create the opportunity for greatness within your customer facing products.
Many engineers transitioning from individual contributor roles to people management experience a great loss – they no longer control their own time.
Day after day fills with meetings and check-ins.
To catch up we work harder, only to find we’ve accepted even more meeting requests. We’ve forgotten the first rule of holes: stop digging.
To achieve calmness and clarity as a software engineering manager, you need to reclaim your calendar.
Our work is enriched by close relationships with coworkers. But we shouldn’t confuse them with our actual family.
The authors provide a good, alternative way to think about work and family: “The best companies aren’t families. They’re supporters of families.”
As an engineering manager, you’ll do well to think about ways to better support your employees in building a healthy and happy family.
Consider where best practices originate – usually from companies that look nothing like yours.
If you’re a small software company, take best practices from Google, Facebook, or whoever else with a grain of salt.
When we talk about best practices, we’re really discussing standards of performance.
Standards are incredibly important to improving quality, but they should only be established by people with the expertise to actually understand the work. This is where standards often go awry – they’re pulled in from some unrelated company that looks nothing like yours, then handed down from above on a stone tablet.
In a call back to their first book Getting Real, Fried and Heinemeier Hanson call for product work to be done by teams of three.
Anecdotally, I’ve experienced success throughout my career using teams of three both as a manager and software engineer.
Three people maintain momentum better than two person teams, which are more subject to the wild swings of human emotion and energy.
Teams of four and more require management and communication overhead adds up between individual contributors.