From Junior to Senior: In high school or at university, you were taught the theory. Read to understand how to apply that theory effectively in the real world.
Working well doesn’t mean just solving problems; it means solving them RIGHT.
I came from the Spectrum. In BASIC, structured programming was difficult to implement, so I was a survival programmer. “Coder To Developer” (Gunderloy) taught me about the pride of developing good code and the practical utility of doing it right, instead of just making it work. Later, I read “The Pragmatic Programmer” (Hunt & Thomas) to solidify what I’d learned. Experience isn’t a matter of years; it’s a matter of learning.
“Rapid Development” (McConnell) taught me many things, but most importantly, that being a Senior had nothing to do with having many years doing the same thing. It’s about learning as quickly as possible to do things better.
“They studied professional programmers with an average of 7 years of experience. They found a 20-to-1 ratio between the best and worst programmers for their first draft. A 25-to-1 ratio in the time they needed to find a bug. The worst programmers wrote programs five times larger and ten times slower. However, they found no relationship between the programmer’s years of experience and their quality or productivity.”
“Rapid Development” (McConnell)
Creative tasks require concentration.
I found “Code Complete” (McConnell) very helpful, a substantial book to be read in small doses. Among the things I took from it, the first definition of being “in the zone” or “in flow.”
“This mental juggling is one of the most challenging aspects of programming, requiring more concentration than other activities. This is why programmers complain about ‘rapid interruptions,’ which is like asking a juggler with three balls in the air to hold your grocery bags.”
Code Complete (McConnell)
“Soft Skills: The Software Developer’s Life Manual” (Sonmez): A kind of management guide for developers that goes beyond software and covers all aspects of life, including finance, health, or relationships. Buy a few copies for the developers you want to promote.
Books that helped me transition from Senior to Team Lead: Managing people is to programming what conducting an orchestra is to playing the violin.
If you’re interested in a management career:
“Making Things Happen” (Berkun) is not only full of advice to guide you through all project situations but also contains advice contrary to popular wisdom.
Just as the conductor is responsible for making the music sound harmonious, you are responsible for making things happen in your project.
Estimating, is it cheating? One of the most complex and requested aspects in the industry is estimation. Knowing how (and especially why) to do them is a differentiator. Fulfilling the estimate is not the goal (nothing easier!). Estimation is something that helps you produce better software.
“The Heroic Effort Complex. If things end well, survivors think that this heroic effort is the main reason for their success. However, there are many bad habits behind this logic.”
“Making Things Happen” (Berkun)
“Agile Estimating and Planning” (Cohn): Change-driven projects challenge traditional estimation techniques. It’s full of advice and examples that can be used in everyday work. Project Managers who forget their history are doomed to repeat it.
If you work in software, the equivalent of Greek myths is “The Mythical Man-Month” (Brooks). With this book, you discover that all your problems, ALL, were experienced by others 50 years ago. What’s new is only what we’ve forgotten.
If you’re not SO INTERESTED in management but want to remain tied to the technical side, there’s an equivalent for Technicians who will manage technicians: “Herding Cats: A Primer for Programmers Who Lead Programmers” (Rainwater).
“Planning is usually something your boss launches [it has to be ready by Christmas], and you have to fill in the details. Two steps forward, one step back. It’s a recursive process. You’re continually shaping a big plan to fine-tune the details you’ll manage.”
“Herding Cats: A Primer for Programmers Who Lead Programmers” (Rainwater).
And another one for planning without having to plan (so much): “Getting Real” (37signals): A smaller, faster, better way to build software. The Basecamp team has updated it with “Shape up,” but my recommendation is to start with the classic.
From Project to Product: It’s VERY different, and you need to know why, or you’ll end up working on a “proJuct”!
The key to projects is constraints. Time, cost, scope… you know. But how would you manage a project if you had no constraints at all? They explain it in “The Deadline” (DeMarco), which is a pleasant and easy-to-read novella.
Quality, the great forgotten when it’s time to cut time and cost and expand scope. Some advice for implementing systematic quality without costing you your life in “The Checklist Manifesto” (Gawande). Also on quality, “The Ice Cream Maker” (Chowdhury) is a novella where step by step, you’ll see what it means to implement a management system.
I remember my coach used to tell me, “Don’t judge the goalkeeper on their best day. Judge them on their worst. When they play poorly, will they make you lose the game? Or are they good enough to keep you competitive even on their worst day? Well, I judge companies the same way. How do they perform when problems arise?”
The Ice Cream Maker” (Chowdhury)
Toyota changed the way products are manufactured in the automotive industry. If you want to make quality products, you should take a look at it. “The Toyota Way” (Liker).
“People do what their bosses tell them. If that’s consistent, if they’re not confused by different priorities, they’ll learn what really matters and what doesn’t. The top two priorities are ‘quality-first’ and ‘safety-first.’ Extra effort. Extra care. It’s the kind of culture we expect to create, and it guides our business.”
The Toyota Way” (Liker).
If you work in software, the equivalent of reading “The Toyota Way” is “Lean Software Development” (Poppendieck).
From the technical side to the management side: it’s like an economist starting to learn Java.
Creating good solutions is one thing. Creating solutions you can sell, and knowing how and why you can sell them, is another. “7 Powers: The Foundations of Business Strategy” (Helmer) provides a framework for understanding why some products succeed while others, possibly objectively better, fail. You can start applying it to your daily work from page 10.
When you move away from the technical side, delegating is not an option but part of your job. “If You Want It Done Right, You Don’t Have to Do It Yourself!” (Genett) provides the basic rules for delegating effectively.
- Prepare well what you’re going to delegate.
- Explain the task, its deadlines, and the level of authority you grant clearly.
- Establish regular follow-ups, including after the task is completed.
If you’ve ever said, “The Japanese say ‘yes’ when they mean ‘no,'” “These Americans are so rude,” or “I can’t trust the deadlines I get from Latin America,” “The Culture Map” (Meyer) is your book. The word of the year was “Kuuki Yomenai,” which means “the one who can’t read the air,” someone who doesn’t understand the unspoken. If I’m in a meeting in Japan, and someone is showing disagreement not explicitly but implicitly, I have to read the environment to appreciate that disagreement.
One of your most important jobs will be to say No. “When I Say No, I Feel Guilty” (Smith) provides techniques to improve your assertiveness, which is incredibly helpful for introverted technicians.