> I've gone back and forth on whether managers should code and my opinion is: don't stop coding... Over time it means you'll have a harder time talking to engineers because you'll forget how they think and how they become bored.
For me, this is the money quote. Like rands, I've gone back and forth on this over the years as well, but I do strongly believe that you cannot effectively manage a team if you do not understand what it is that they do, at least at a high level.
You don't need to be as good at coding as the engineers who work for you, but you must know enough to empathize with them, and to help mediate dead-locked discussions.
I'll admit that there are exceptions, and effective s/w managers who can't code do exist, and I'll also admit that finding such managers is probably not a scalable task, but I feel it's something that every company should strive for.
I'm borderline if managers should code or not, but as soon as you get to manage a team, and the job doesn't require it, do stop coding!
It is not your job anymore, and if over the next 5-10 years you start having a hard time talking to engineers, than maybe you weren't that good of a programmer to matter. Frameworks change, but general programming knowledge doesn't. Even if an engineer says something like "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" as an excuse to not deliver and if you think it is important for the rest of the project, you should easily check google to understand what is going on, but you don't need to know rails 7!
Once you stop programming, your skills will degrade like a musician who stops practicing, you'll eventually forget what its like to be a programmer like a parent forgets what its like to be a teenager. You'll lose your ability to connect with programmers, but hopefully by that time you are managing managers who manage programmers, or something like that.
Google can't fill these information gaps, and any manager who trusts Google over their engineers is probably a toxic one at that.
A musician will have his skill decline, but his appreciation and understanding of music probably wont. I think this is the key point. Yes, after 10 years, the manager won't be as able to code something in the project (nor should he) but he won't just magically forget what O notation or graph theory is all about.
I think a better analogy maybe coaching. Some coaches were players before coaching, while others weren't, but their understanding of the sport isn't linked to them actually playing the sport.
A coach would observe their players play everyday, and review their performance quite directly. Their bodies are not able to do it anymore, but they are "still in the game" so to speak. A bad development manager is often never looking at their programmers' code (or if they do, they might not understand it), only seeing and evaluating indirect results of their work. Even a good dev manager is not looking at their programmers' code very much, but at least they understand what is going on and are able to themselves in their programmers' shoes.
Organizational "visibility" is why it is so important for programmers to attend and speak up at meetings; the organization is incapable of valuing what they do directly. Also, "managing up" is the secret to getting things done with a non-coding boss.
But that is exactly the point I'm trying to make. A coach won't be able to do a dribble (soccer) or sprint for the header goal, the same way a manager shouldn't be writing the unit tests or OAuth login, but both are involved in their fields and don't magically forget the rules of the sport or what OOP is.
I'm not advocating that bad managers should learn through google, but if you were a good developer and didn't program for 10 years, if the time came to decide between TDD or BDD for the project (though that should be a Team Lead or CTO job, not a PM) he should be able to brush up quickly. Maybe not decide if you should use Shoulda or xUnit or whatever, but have a general picture of what the developers they are managing are talking about.
What do binary decision diagrams (BDDs) have to do with TDD (test driven development)?
If this manager hasn't been doing development for 10 years, he is a lot cause. But this doesn't have much to do with programming, just being involved in building software. But in cases where their experience isn't fresh enough, they will have a tendency to either be static (we will write our web project in COBOL, because that is what I used to use dammit) or be very trendy to a fault (I heard post modern node-oriented programming was hot, let's use that for our compiler).
Just like parents do not forget teenage years rather the experience of being a teenager is much different, so programming evolves and changes. But your point is still true, while non-programmers can appreciate the result, it is a job for professionals at thge top of their game.
I would disagree that general programming knowledge doesn't change. While most of the ideas currently on the forefront of software engineering were invented decades ago, many of them have only hit mainstream very recently. While pure functional programming isn't used very often on large projects, current best practices prefer a declarative functional style whenever possible.
While a "for" loop may not have changed, someone who has only coded C++ may not understand why it's often the wrong way to iterate over a collection in modern environments. They might not understand why you'd use function parameters instead of inheritance, or lots of tiny single-method classes instead of one class that handles every aspect of a data type.
While these may seem like simple implementation details, they can lead to different approaches to problem solving, and conflicts over programming style that you might need to mediate. For example, if one of your group's goals is test coverage, then it would be helpful to have done some TDD, and know what characteristics are more or less conducive to testing.
While none of these ideas is brand new, there are a lot of teams that have only recently started embracing them, and a manager who hasn't kept up is probably not going to be a very good fit on a team that has.
Especially this. Even worse: they might hear that functional programming is the new trendy thing, and for loops are passe. That you should always bury your control flow in a lot of small callback functions without the appropriate amounts of equational reasoning that must go with it, killing your ability to really debug your programmer. Or they might hear about TDD, and apply it in a very wrong way because they really don't get development very well. Actually, the only thing worse than a non-coding manager is a manager who tries to "keep up" without really being in the game.
A good dev manager is able to see the good over the fad.
Managers need to code. However, managers need to manage first.
"Management" doesn't always mean tell people what to do (it rarely does if you're doing it right,) Managing could mean protecting your team from all the boring shit work, it could mean making sure that your team's goals are in sync with other teams, it could mean making sure that people are prioritizing their work around what needs to be done rather than what would be fun to do, etc.
Is there any distinction made between project management and people management in a startup? The developer manager must manage development first and foremost, it is a bit weird if they are handed project management responsibilities also, which can generally be handled by a less senior person, perhaps one who doesn't even code.
If there are other teams, I would assume we aren't talking about a small startup anymore. But even if we were talking about a small startup with one team working on a product, it makes sense to delegate project management tasks to someone in the team who isn't managing the team.
A developer manager should be able to protect their team from shit work because they know what shit work looks like in the first place. They should also understand the parts at a high enough level to make informed decisions, and they at least know who knows the details so they can get input from the right people when problems arise.
More the just frameworks change. More importantly, if you did not coded for 10 years, it is only that what you remember is outdated. It is also that what you remember is an idealized high level version of what it really was.
That kind of manager that bases his decisions on quick google searches without understanding whole system is the worst kind of manager. If there are trade offs involved and possible bad consequences in the context of your database, your search will ignore that.
Ultimately, "In rails 7, you can't splice the header from the body of the message stream sent over airsockets" is not level of detail non-coding manager should deal with. That is for the rest of the team to either propose other solutions or make it work with the rejected one.
The managers role is not to make technical decisions, his job is to ensure that other team members will help that "excusing" engineer to find solution. Managers role is to detect engineers seem to need help too often, but he is looking for pattern there - not one quick search over what might be controversial issue.
<quote>
The managers role is not to make technical decisions, his job is to ensure that other team members will help that "excusing" engineer to find solution. Managers role is to detect engineers seem to need help too often, but he is looking for pattern there - not one quick search over what might be controversial issue.
</quote>
That is exactly what I tried to say (maybe in the wrong way). A manager's job isn't to make technical decisions or help the engineer with code. It is to have an higher level view of the project, how it is going, and be able to help make it through. So, picking the rails 7 example, in this case the manager should be able to read about it and say, "Hey engineer X, have a chat with Bob in the frontend team, he may be able to help you out since he has experience with socket communication". Not decide to change rails to node because he read a blog post about how great node is.
I don't think a manager should be the one deciding deadlocked decisions. Managing a team is a full-time job, you don't have time to keep up with the codebase without compromising one or both. Promote someone you trust to tech lead and give them final say on technical decisions while they remain a coder, and concentrate on being the interface between your team and the company.
For me, this is the money quote. Like rands, I've gone back and forth on this over the years as well, but I do strongly believe that you cannot effectively manage a team if you do not understand what it is that they do, at least at a high level.
You don't need to be as good at coding as the engineers who work for you, but you must know enough to empathize with them, and to help mediate dead-locked discussions.
I'll admit that there are exceptions, and effective s/w managers who can't code do exist, and I'll also admit that finding such managers is probably not a scalable task, but I feel it's something that every company should strive for.