I’m old, and one benefit of being old is that I’ve seen things. I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Ori… Ok, maybe not those things, but still… things. And let me tell you something about one thing I believe many of us should be more aware of.
For years now it’s been a common practice to expect programmers to head into management as a natural progress in their careers. Yep, even I envisioned my own career to have that route at some point. Reasoning looks legit on first thought: technology changes very rapidly, knowledge gets obsolete and it gets harder and harder to keep up as you get older. At some point you get tired, pass the torch to younger peers and accept that management position you are offered. Your social status grows, paycheck probably too, and all looks great.
Except that, more often than not, it isn’t.
Let me explain.
In general, skills required to be a good programmer are orthogonal to skills that make a good manager and, although there are exceptions, most programmers will simply suck at management or be mediocre at best. There’s no doubt that there are some individuals who could successfully make this switch and excel in their new roles (I know some and I have no doubts that you do too), but there are way more of those who end up as mediocre and often unhappy managers.
If you are a programmer reading this, there’s a great chance you prefer math, so let’s play a numbers game: if we agree that only a fraction, let’s say 10%, of general population are good at programming and equal proportion would make a good manager, intersection of those two groups is roughly 10% of 10% == 1% of workforce. Those 1% will indeed make great managers with excellent technical background, but the others will end up forever lost, both for the company, but also for themselves.
This is something that recently gets talked more and more and more about and even has a fancy name: Peter principle.
Note to managers
Don’t promote your programmers into managers. More precisely, don’t force that promotion on them, either directly or indirectly.
Instead, appreciate them for what they are and it will benefit everyone. Those appreciations may be as simple as a larger number on a monthly check or a better office (if you still haven’t migrated to WFH) or anything else that motivates them. And you know what motivates most of them and costs nothing? Respect. Respect your programmers at least as much as you respect your line managers. Management is important for every company (especially on the highest levels), but every software company will benefit more from experienced programmer than from mediocre manager. To give you a parallel: if you ever need a surgery, would you pick the hospital to go to based on managers that run those hospitals or surgeons they employ?
Software companies need managers, there’s no doubt about that, but at the same time they need experienced programmers even more, and each time an experienced programmer goes into management, most of their present expertise is lost, often forever (…like tears in rain). That will damage not only them, all the juniors that will lose a good mentor, but also the company itself and everything it has invested into the education of those programmers.
Note to programmers
Don’t be afraid to learn new things. Lots of them. Indefinitely. No one says it will be easy, but there are many ways in which you can keep your long-lasting programming career manageable. (pun intended)
First of all, stop chasing the goal of trying to know everything there is. Amount of existing knowledge, not to mention new one that is thrown our way on a daily basis is colossal. However, there is no point in burning yourself out. Our industry is still young, we iterate a lot and chasing every New Technology will lead you nowhere. Instead, focus on mastering common patterns. If you don’t know what those patterns are, wait a little bit, they will emerge, don’t worry. At some point you’ll notice that often some New Technology is nothing more than (over)simplified version of something you already know under a different name.
Focus on novel patterns that build on top of what you already know. Far from it that there won’t be bits of knowledge that will become irreversibly obsolete, but those are far less common than one may initially think. Most of what we build these days depends on something someone built before us and knowing those fundamentals (also known as Old Tech) will make you a much more resourceful programmer, even if you may not use that knowledge directly in the product you are building today.
Don’t be afraid to “skip a beat” and ignore some New Technology if your guts tell you it will be a dead end. In our industry we experiment a lot and not every experiment ends up as a success. Which new technology will end up as a success and which one will fail is not easy to predict, so be prepared to iterate: if you initially decided to jump the wagon and invest into learning something new, don’t be reluctant to drop it if it doesn’t end up delivering on its promises, but also don’t stubbornly ignore something that looked like a dead end in the beginning, but it turned out to be a success. Admitting to yourself that you misjudged something is among the hardest things in any profession, but I’m yet to meet someone who was right every time.
Sometimes it may seem that you have time either for building things or learning something new. And on many occasions those efforts will look like they are interfering with each other, but it would be wrong to look at building things as “not learning”. Practical experience you’ll get from building products is often more valuable than learning a new library or a framework, because practical knowledge is much harder to transfer in writing. Building is learning.
To end in a positive vibe, note that time actually works for you. Amount of knowledge one has to master to become productive grows monotonically. So, the sooner you start, the more time you will have to grasp it all. When I started, we had computers whose RAM was in kilobytes and disks in megabytes (if any). CLI was the only UI there was, we had effectively one programming language (C) and one platform (desktop). I consider myself lucky that I had so many years at my disposal to learn everything that came my way. Yes, some of that knowledge I’ll never use again, but most of the new stuff I learned over time just augmented something I learned before.