An Elegant Puzzle
There's a saying that people don't leave companies, they leave managers. Management is a key part of any organization, yet the discipline is often self-taught and unstructured. Getting to the good solutions of complex management challenges can make the difference between fulfillment and frustration for teams, and, ultimately, the success or failure of companies. Will Larson's An Elegant Puzzle orients around the particular challenges of engineering management--from sizing teams to technical debt to succession planning--and provides a path to the good solutions. Drawing from his experience at Digg, Uber, and Stripe, Will Larson has developed a thoughtful approach to engineering management that leaders of all levels at companies of all sizes can apply. An Elegant Puzzle balances structured principles and human-centric thinking to help any leader create more effective and rewarding organizations for engineers to thrive in.
Stats for nerds
41recommend
68mentions
60people
2019–2026years
68% recommend29% neutral3% critical
Mentions per year
What Hacker News says
- It's funny when popular blog writers get criticised for turning blog posts into books (usually while leaving the original posts accessible) when I feel this is way more honest than doing exactly what you say. Resilient Management by Lara Hogan and An Elegant Puzzle by Will Larson do the former and are two of the most useful SW Management books I've ever read.
- One intuition for the variability argument comes from binary search, where you learn the most when you eliminate half the possibilities. You can apply the same logic to your product development or testing strategy by intending to fail more frequently. (In the testing context, this could look like testing at a higher level of integration.) This adds variability to the process but you will learn more and faster, which typically results in economic upside.
In terms of resources, Will Larson's An Elegant Puzzle hits on some of these themes and is very readable. However, he doesn't show much of his work, as it were. It's more like a series of blog posts, whereas Reinertsen's book is more like a textbook. You could also just read a queuing theory textbook and try to generalize from it (and that's where you'll read plenty about high-capacity queues, for example).
- The only non-negotiable is information clearly stating what the goal of your team is, how it directly affects the mission of the company, and how much progress your team made towards the goal during the sprint.
I recommend “An Elegant Puzzle” by Will Larson if you are asking this sort of question. It’s as close as we have to a bible on being a technical PM. It totally changed my perspective on getting things done as a team of software engineers, and also led me down a treasured path of systems thinking and psychology. It’s simply an excellent book for someone like you to read.
- The maxim of office happiness is "strong relationship > any problem." If you find yourself constantly couching your language like this with someone, it is an "organization smell" that you need to gain more familiarity with that person! Once you have established rapport, and you both feel free to express yourself a little roughly at times, you spend less time reflecting on your communication and more time exchanging the information needed to build.
If you find yourself having to talk like this all the time at work I recommend reading "An Elegant Puzzle" by Will Larson.
- There are a number of decent books.
"Become an Effective Software Engineering Manager", "The Manager's Path", "Becoming a Technical Leader", "An Elegant Puzzle", "Resilient Management".
But your best bet is either finding an experienced manager who's willing to coach you, or working with a management coach.
(There's a number of folks blogging as well. Gergely Orosz, Laura Hogan, Camille Fournier,...)
- Ill mention a few books and how they've helped me become a better programmer.
- Structure and Interpretation of Computer Programs: this helped me understand the different types of recursion; how a problem can be modeled for the code to solve and how those designs can evolve and how the paradigm I'm using (functional or OOP) can help me
- Refactoring: this book helped me understand the different patterns we can use to alter code. Giving them a name and symptoms is a great way to apply and communicate with other coders. I recommend this book to everyone.
- The little Lisper: this really helped me get recursion. Like really. Although I could use a refresher.
- Clean code: look... this book is bad. Like, really bad. But, at the time I read it, and in the languages I used (Python, C, R) we didn't have many rules on how to write and organize our programs. And I wanted to improve on that skill. And this book gave me pointers and made me think about those ideas. I don't recommend it around, because for many people Clean Code can become a dogma really easily. But if you can question and critique and reach out to other resources and is an advanced beginner to coding, I can see this book bringing value.
- An Elegant Puzzle and Staff Engineer by Will Larson: those helped me get clarity on the role of the technical team in an organization. A team that produces code as the main driver of impact in a product/service. I lump them both because I read them back to back and don't remember, exactly, which is which. But une is more focus on a tech leader and the other a tech specialist.
- Unix and Linux System Administration Handbook: whenever I need to interact with some unix technology, this book delivers in terms of giving me a nice historical view and presenting the common tooling around the tool. This helps me interact with stuff programmatically much better. Be it GRUB, X, SAMBA, this book gave me the necessary introduction I needed, much more organized and thought out and with useful references than the average blog post you will find in the wild.
And I'd like to recommend this Ask HN on problem solving books
Related
Staff Engineer
8 recommend · 13
Problem Solving Through Problems
3 recommend · 3
A pattern language
110 recommend · 368
Game Programming Patterns
120 recommend · 161
The Alignment Problem
7 recommend · 12
Cracking The Coding Interview
178 recommend · 553
