Yes, engineering managers absolutely should understand how to code, and understanding concepts like technical debt, unreliability of estimation, etc. goes without saying. And it's awesome for a manager to be familiar enough with the tools and work to be able to implement a quick critical bugfix or similar when unexpectedly necessary.
But if they're a good manager, it's far better for the organization for them to be spending their full time managing. Let coders code and managers manage, as long as they're both good at their jobs. The author's argument makes as much sense as saying a professional baseball coach should be spending 30% of his game time actually playing with his team.
And honestly, this is just BS:
> Once a person stops coding for a significant portion of time, critical connections to the concerns of developers atrophy.
Citation needed. It sounds as fake as supposed facts like we only use 10 percent of our brains, or other hogwash.
Your argument sounds good in theory, but a lot of us have the experience that 'good managers' are unicorns.
Before my start-up, I was a dev manager. And a damn good developer. I knew what technical difficulties my team had, and understood them, because I was the first place they came for an extra set of eyes. I ran defense from upper management because I knew the concerns, and I was the one with the voice. Because I'm also an open-book style manager I didn't play the "they don't need to know" card, but I could handle those things without them first having to mount a case to me every time.
I've watched A LOT of "I used to code" managers, and almost to a man, they are a disasters.
Exactly this. If you are a PM at a Valley outfit & can't code right now, your team simply pretends to respect you, while going off & doing its own thing. Its just one of those empirical things. Doesn't matter if you "used to code" once upon a time. Things are moving at a breakneck pace & if you don't keep up, you are really going to get left behind.
I will also say that if you are a PM at a non-Valley outfit like a bank or one of those outsourcing firms, the exact opposite holds true. You should probably not code & spend all of your time managing. IBs especially frown at MDs & VPs taking on hands-on roles instead of managing & filling out gantt charts. My Manager at Goldman used to write compilers using javacc to automate risk algebras - he regularly got the stink eye. He used to tell me "they just want me to run the spreadsheets" :)
A manager is responsible for controlling, administering and maintaining the work being done by their subordinates. A big chunk of that is determining what work is yet to be done, if it's on time, what needs to be done to support the existing work, communicating with other teams, doing research, quashing harmful discourse and building morale. They organize, prioritize and double-check the tasks assigned and meet with their subordinates to ensure everything is going smoothly. They plan, develop, monitor, communicate, and assess their employees and their work. And of course they attend countless, constant meetings.
If as a manager you can do all that and then have 2.5-3.5 hours a day left to write code, bravo.
A baseball coach knows if the pitcher isn't doing so well, because he's watched the games. How does a manager know if the new API is unwieldy, or if errors in one component are causing serious grief?
I mean, you can ask employees to blame their peers, but some won't want to, and some will be a little too eager.
Do you have a citation for this? I've had some stretches in my career where I went a long time without doing any significant coding, and have always been able to ramp back up to speed quickly when needed.
Both my parents used to code (my dad on punchcards and my mom on a massive mainframe). It took significant time for either of them to pick up HTML for side projects.
Even in my own life, I was a developer from 10 to 18 (working 14 to 18, school 10-14) then I took about 7 years off to go do physical sciences. While I retained the basics like for loops and function calls, I totally lost a good portion of the rest of it.
At least in your case, you not only stopped coding but you stopped being around code or dealing with code. That is very different from not coding for 30%. Good chances that if you coded say 5-10% a week and spent the remaining time thinking about code architecture or code reviews, you'd be in a much different position.
I know this wasn't your point, but there are more businesses in the world than just "Valley outfits" and "non-Valley outfits like banks or those outsourcing firms"...
At least two of those of which I can recall were women. But the idiom is "to a man". It might be sexist of me to change a gender neutral idiom to be masculine, but using an innocuous masculine idiom is not harming anyone or promoting stereotypes. It's just using an idiom, man. or woman. or child. or political correctness bot.
I don't quite agree with that. Specialization is a good thing, but having managers and coders seems too much specialization. It leads to the situation where a manager could fix something small in the same time he communicates someone to fix it. Or situations where the manager slowly loses touch with technology. It's not likely someone will "understand" programming over the years without doing it constantly. And over time the manager's value to the team withers away.
I like this idea that there are no managers who manage and engineers who engineer. Instead, there's maybe one person who takes the responsibility of managing work, but does programming or other non-managing work the rest of the time. The engineers can also do a bit of managing, but they'll focus on the engineering.
The assumption is of course, that managing work can be automated away sufficiently and the team is a not huge. These are realistic assumptions, but are often untrue because of organizatonal flaws (or flaws with the manager).
The baseball coach argument doesn't really fit here, because baseball is not reinvented every 5 years. Programming quite often is. A C++ systems programmer probably can't understand much about HTML5 frontend programming. But a manager with C++ background can learn.
It is rarely the fix is "something small" when you have dev-manager leading the team of 5.
The actual fix might be small (changing one line), but the real effort to:
1) Make sure there's unit-test, integration-test
2) Make sure nothing breaks
3) Maybe test the deployment script
4) Maybe test the database migration
is rather involved. If the dev-manager knows all of these steps then sure, why not. But that's like saying that QA should be able to do the same thing too (after all, QA should be a little bit more technical and more in-depth than the dev-manager).
While these are nice, I rarely see them work like that.
I'm not against it, but I just don't think that there is "simple fix" when a dev-manager present (because it implies the size of the project and the size of the software).
I am reminded of a chart of sorts that described "what the software engineer forgot" when describing how long a task would take.
"Oh that's 5 minutes." You forgot logging in, powering on the computer, searching for the particular lines of code, a quick test that the fix didn't break anything, and then [if applicable] shunting over to version control.
Well, I didn't say that every project and every change is something small. I said that there's a subset of changes that are sufficiently small and don't even require new tests (like some small stylesheet change). I think it's rather strange to claim that small fixes don't exist at all.
Even a stylesheet change could require the dev manager to pull down a local copy of the site, get it running locally, make the change, then push it - that could take days if something goes wrong. For an engineer who already has a local working copy, it really is a quick change. Of course, it would be very quick if he simply edited the live code - but I, for one, would have some very stern words for a manager who thought he could get away with doing that.
> It leads to the situation where a manager could fix something small in the same time he communicates someone to fix it
And when you have 50 small things? Or when the one small thing turns out to have been bigger than you thought, and you waste time trying to do the work that the engineers are probably more familiar with because one of them has been working on the same thing for months? Or when you have managing to do?
> Or situations where the manager slowly loses touch with technology
This is what design reviews are for.
> It's not likely someone will "understand" programming over the years without doing it constantly
I don't necessarily ride bikes over the years. But I understand it well enough to look at a bike and see how it works, or tell someone else where to go and how to ride it.
> Instead, there's maybe one person who takes the responsibility of managing work,
Like a manager?
> but does programming or other non-managing work the rest of the time
What 'rest of the time'? You mean when they're not fulfilling the first obligation you gave to them, which is managing work?
> The engineers can also do a bit of managing, but they'll focus on the engineering.
Why not just let them focus on the engineering? Why give them extra crap to do when somebody else was already tasked with managing the work?
> The assumption is of course, that managing work can be automated away sufficiently
You can't automate managing work. That's why it's called "management". Because you have to do work to manage it.
> and the team is a not huge. These are realistic assumptions, but are often untrue because of organizatonal flaws (or flaws with the manager).
Or because the organization is just big and the workload is high.
> baseball is not reinvented every 5 years. Programming quite often is.
Programming has not been "reinvented" in the last 40 years. It's pretty much the same, with some languages and tools re-addressing the same issues that were seen decades ago. Programming evolves, but so far it has never changed so much that an old programmer can't figure out what's going on with a new language or tool or system after looking at it for a while.
When you're a manager, you don't sit in an ivory tower and stick your fingers in your ears and expect to know what the hell is going on. You are constantly reading documentation released from teams within the company and become aware of changes between releases, hopefully well before they come into effect. You can even set up and maintain a development environment to run unit tests to verify your application works, reviewing build reports, and so on.
I think the reason so many people underestimate what takes up a manager's time is mostly they're people who never learned how to be a manager; they're often glorified team leads with the privilege to fire someone. It does a disservice to the people who have skills that don't apply to programming.
This is why I sincerely believe secretaries are important. Managers... do the managing. Secretaries... take care of the administrative. Life is so much better when this stuff "just works".
Agree with this. The best manager I have had (in an engineering consultancy) used to be on the tools, but refused to do any more 'real work'. Instead he spent all of his time managing the team of ~30. Eventually upper management decided he needed to do 'real work', and it didn't work out.
What I've noticed with technical people who come into a management role, is that they're either able to put down the tools, or they aren't. If they aren't able to step away, they're functionally useless as a manager, because they spend all their time down squirrel holes, ignoring the management stuff.
Management is an art, and the benefits a good manager provides often seem intangible, but are nevertheless extremely valuable. I still miss the leadership and people management skills of that good manager today, and it hurts to think we traded everything he provided for the assumption that he should have spent x hours doing technical work, much less efficiently than the people he was managing. Sigh...
>And when you have 50 small things? Or when the one small thing turns out to have been bigger than you thought, and you waste time trying to do the work that the engineers are probably more familiar with because one of them has been working on the same thing for months? Or when you have managing to do?
Well, of course a manager shouldn't make a small fix is managing work takes all the time. And the manager would make better time estimates and be familiar with the code if he actually did code 30% of the time.
>This is what design reviews are for.
I don't think they're sufficient, but do help. Kinda like reading code from a keynote describing a new language doesn't really make you learn it, it'll give an overview to 99% of people.
>I don't necessarily ride bikes over the years. But I understand it well enough to look at a bike and see how it works, or tell someone else where to go and how to ride it.
I agree with you. Note that if that bike is transformed into an airplane in five years, knowing how bikes work doesn't help much explaining how airplanes work.
>Like a manager?
Yes, I'm not against a person who is named 'manager' (titles don't really matter), but I think the manager should do some coding on the project.
>What 'rest of the time'? You mean when they're not fulfilling the first obligation you gave to them, which is managing work?
Yes, I mean that. A good manager will not micro-manager, and if the team is not huge and the organization is not flawed, there will be time for some coding.
>Why not just let them focus on the engineering? Why give them extra crap to do when somebody else was already tasked with managing the work?
It can be efficient. Often an engineer knows some managing work to do. If the engineer won't do the managing, he has to communicate the work to the manager. This communication takes time, which could be used to quickly do the small managing job.
>You can't automate managing work. That's why it's called "management". Because you have to do work to manage it.
Of course you can. Managing work has been automated a lot. Just because not all managing work has been automated doesn't mean it hasn't been automated. A lot of things that managers did 50 years ago are now automated. Hell, most experts had a personal secretary working under them just to make things work, because everything had to be done manually.
>Or because the organization is just big and the workload is high.
Yes, situations differ.
>Programming has not been "reinvented" in the last 40 years. It's pretty much the same, with some languages and tools re-addressing the same issues that were seen decades ago. Programming evolves, but so far it has never changed so much that an old programmer can't figure out what's going on with a new language or tool or system after looking at it for a while.
This is just arguing against rhetoric.
>When you're a manager, you don't sit in an ivory tower and stick your fingers in your ears and expect to know what the hell is going on. You are constantly reading documentation released from teams within the company and become aware of changes between releases, hopefully well before they come into effect. You can even set up and maintain a development environment to run unit tests to verify your application works, reviewing build reports, and so on.
Good. That may not be optimal.
>I think the reason so many people underestimate what takes up a manager's time is mostly they're people who never learned how to be a manager; they're often glorified team leads with the privilege to fire someone. It does a disservice to the people who have skills that don't apply to programming.
Your argument is "you're wrong because you're bad".
If you're looking for anecdata, I can tell you that after stopping coding and doing "business stuff" for a while, including the "engineering management" role, I did catch my perspective shifting away from that of a developer, towards that of a business guy. Adding some coding to my routine has helped get that back, besides a number of other benefits.
The problem that I've found with engineering managers who don't code anymore is that they are stuck in the mindset of the last project they worked on. I've spent a lot of time talking to managers about decisions that they make which I think are poor, but they "know better." They aren't on the front lines when it comes to knowing about libraries, languages, infrastructure and lots of other development related topics. I agree that if managers stayed in their lane, it would be great; but that rarely happens.
Once they quit programming back in the 2000 and they did not learn the newer techniques, they're out of touch.
A simple example would be when it comes to test automation. Back in the 2000, automating GUI tests with _high_ coverage might be acceptable. Fast forward to today, we all learned that there is a very high cost on end-to-end functional testing that involves complex UI so we tend to write 10% of UI test automation, 20-30% of integration tests, and the rest falls into the unit-testing bucket.
That's just the tip of the iceberg. Other areas of improvement ever since: dealing with build, dealing with continuous integration, continuous deployment, source control, etc.
You really believe that programming is such a unique area that people cannot be fully aware of such developments without actually practicing them?
Gimme a break.
I'm aware of Coffeescript, Backbone, Angular e.a., and I never did one inch of javascript or front-end coding in my life. Hell, the last time I did anything on the client side we were still doing laying with tables and one pixel transparent gifs...
Just because it says "manager" on my business card doesn't mean I had my head stuck up my arse since. It may no longer be my job to do, but it's still my job to know.
I specifically mentioned "if they did not learn new techniques".
By learning, I'm referring to reading, go through some of the examples a little bit, but does not necessary practice the tools.
I'm merely agreeing with the parent that there are cases where managers stop reading the tech side and focus solely on the management aspect (risk management vs JS frameworks).
If the manager still hold on the traditional approaches, he/she would insist to have more UI test automation as opposed to spend time and invest more on unit-test.
dealing with build, dealing with continuous integration, continuous deployment, source control, etc.
It's not like build systems and source control were invented after 2000. Or basic CI/CD practices for that matter (though perhaps not as automated as today).
However, in the case of build systems, they have been reinvented a dozen times annually since then (mostly make clones).
>> Once a person stops coding for a significant portion of time, critical connections to the concerns of developers atrophy.
> Citation needed. It sounds as fake as supposed facts like we only use 10 percent of our brains, or other hogwash.
I don't have a citation, but this seems obvious to me. It also bears out in my own experiences. Delivering great software requires deep thought and long, uninterrupted periods of concentration [1], and managing requires rapid context switching.
When I was lead developer at a web consultancy in Austin, I mostly attended meetings and context-switched between one of dozens of projects. I never had uninterrupted blocks of time to analyze problems deeply. When I left, it took me a good six weeks of coding before I felt I could really push on hard problems again.
I had trained my brain to context switch every 5 minutes, and so it expected to keep doing so. I still knew all the syntax, and remembered how everything played together, but breaking business stories down into their component parts was difficult. I couldn't hold the program in my head.
[This bears out in the physical world, too: we would not expect a 100-yard sprinter to necessarily be able to run marathons.]
I really think you are failing to recognize that to actually understand technical issues managers need to code. Most managers are terrible at their jobs precisely because they are totally out of touch with these technical realities. At best they are clueless. At worst managers actually think they know better than their engineers and develop a hostile relationship with them.
> The author's argument makes as much sense as saying a professional baseball coach should be spending 30% of his game time actually playing with his team.
This is a bad comparison because baseball hasn't significantly changed in the last 100 years, but software development changes significantly every 5 year to 10 years.
Over a 40 year career in software development, a typical person will see major fundamental shifts at least 4-5 times.
So yes, if you are directly managing engineers, you should be coding at least some of the time.
If you can't or don't want to contribute code, you should quickly move into upper management and focus on coaching middle managers.
No he won't. He'll see the same shift 4-5 times with different marketing buzzwords attached. Anyone who got his first management job managing "systems programmers" 40 years ago will be perfectly au fait with "devops" today. Anyone who did ASN.1 will be perfectly comfortable with XML or JSON. Anyone who did IMS will be perfectly comfortable with NoSQL (in fact anyone who did IMS in the 70s would find MongoDB laughably primitive). I could go on and on...
IBM was doing virtual machines in the 1970s too. Thin client, which is all a web browser is, has been around a long time, in fact a web browser would be recognizable to anyone who had developer for the old 3270 terminals. Or with the client-side execution of scripts, anyone who remembers NeWS from the 1980s.
Very, very little in the 2010's is "new", it's just abit shinier this time 'round.
Spending 30% of my time coding is just self-indulgent. My team knows I can code, knows I understand their work, and they need me to do the crap they can't afford to deal with, so they can focus on coding.
Also, I'm way to unreliable as a coder because my work can be interrupted at any time. Time blocking a few hours doesn't work, because being a developer is not just writing code for a few hours.
If I want to code in production, I have to participate in code reviews, handle pull request, take part in ad hoc discussions. Otherwise I'm just a tourist getting in the way. If I want to code as a hobby, I should just do it in my own time.
That's where managers often go wrong; they think a team of developers is something to be shaped. It's more like a movie director and his or her team, and the manager is a producer, providing resources and clearing away obstacles. In a well-functioning team there may be little need for active "managing," and when a manager takes it upon himself to do this, he can get in the way.
The coach/player metaphor is an extremely weak analogy for Software Engineering. Sports aren't changing nearly as rapidly as software engineering is. If you don't watch a soccer/basketball/football/baseball for 10 years and come back, it's basically the same game. The last 10 years of software engineering have changed so much with mobile, map-reduce, responsive design, P/B/S/I/A - aaS offerings, dev-ops tools, cloud computing systems, new languages, etc...
I remember a specific example of a manager I had (great Guy) who wanted to build a searchable database of public certificates. When he asked me about what we should build, I said -- Just make one search box (like Google) and allow them to type in whatever they want and we can do the parsing on the backend. He counters saying, well I think we should go with the 50+ input form (That's what he was used to building on all of his old projects). If it was now, I would definitely be more vocal about his software design decisions because he was just rusty and not in touch with the current state of design/dev. I actually got permission to build both interfaces, since it wasn't really much work to build the single search box, and 95% of the usage came though the single search box.
I don't think managers need to program, but they need to be doing the equivalent of watching tape, studying other teams, understanding new/changing game rules, learning tradeoffs of different equipment, and keeping up with their domain. All of my experiences with managers that are active in the development community have been amazing. Managers that weren't have always been terrible.
>The coach/player metaphor is an extremely weak analogy for Software Engineering. Sports aren't changing nearly as rapidly as software engineering is. If you don't watch a soccer/basketball/football/baseball for 10 years and come back, it's basically the same game. The last 10 years of software engineering have changed so much with mobile, map-reduce, responsive design, P/B/S/I/A - aaS offerings, dev-ops tools, cloud computing systems, new languages, etc...
Watching? perhaps. Coaching? No. And that is why I don't think the analogy is weak.
I'm very familiar with two sports, basketball and football. I'm intimately familiar with football. The subtle changes that most fans, particularly casual fans, don't see is what makes coaches who they are and what makes great coaches worth their weight in gold. Not to mention coaches that can get the most out of specific skillsets of players[1].
As just one example. The pistol became all the rage last year with several running QBs running it for their teams. The good teams could, for the most part, coach their players on this style of offense and how to counter it. It was a different style of offense that wasn't used in the NFL and the teams and players had to react...the coaches had to to actually coach them on how to play the zone reads etc etc.
Even further, a coach has to be ready to adapt mid-game, mid-drive and in situations. Game conditions dictate them be ready for quite a bit and ready to coach up their players at an instant...or better still...have previously coached them on such a situation. The game, to the fan, might look the same, but not to the coaches.
This is why for people who are familiar with coaching and managing software, they do hold up. Both are at their core about leading a group of people to a common goal, articulating the goal, the way and (sometimes) the how.
So, in summation, you still don't want your coach running routes. You want your coach getting ready for the game and coaching everyone in that manner.
[1] - I mentioned specific skillsets of players. The pistol was an example of this. You have young, inexperienced mobile QBs who can do a few things well. You adapt to their skills b/c you know, while they have potential, they don't have Peyton Manning's situational football IQ yet (if ever) and ability to read defenses. So you simplify, mold the system around their skills. Good managers do this with developers as well. A manager is not going to just "off you go" to a developer. They need to know strengths and weaknesses. Even with my experienced managers, directors and such, I have a firm grasp on personalities, trigger points, strengths and weaknesses.
I think this works as long as the engineering managers follow a few guidelines:
* Don't code 20% of a full solution with your 30% time and expect the other engineers to pick up your work and finish the other 80% to make it production ready. If you can't cross the halfway point with a task, don't take it on.
* If you do need an engineer to make your code production ready or fix a bug in it, don't act like you did him/her a favor by "getting it off the ground". They are doing YOU a favor by finishing your work for you!
* Be humble and expect to take massive amounts of criticism from engineers who take a lot of pride in their code and spend their careers perfecting it.
* Avoid becoming overly defensive and asking engineers to relax their established code quality guidelines or test coverage to accommodate your compressed schedule.
When I ran my own company as technical co-founder. I wrote POC's to demonstrate something was possible or what I wanted to habe built. I had no issue in throwing away all this code.
I didn't write production code. I fixed bugs or refactored...
To echo your first point, I think the best task for an engineering manager is fixing bugs. It lets them keep in touch with the code base, is generally small enough that it can be compatible with constant interruptions, and demonstrates a much needed humility.
This is a fascinating thread to read. I would love to know when people comment if they also consider themselves a manager, or have managed in the past. The reason is that I find management is a very different skill set than coding, and spending 30% on something that isn't making you a better manager would seem to be counter productive.
That said, I totally get the angst over managers who have never been coders. Sort of like Scully relating the sale of computers to being similar to selling 'colored water' (Pepsi vs Coke). Not so much in my experience.
There is also the question of scale, if you're a 20 person company I can easily see everyone writing code as well as doing other things, 50, 100, 2000 person company? Not so much.
And there is the question of perspective, a solid engineer is there to make the best thing they can, within the constraints of available CPU, memory, and storage resources. A solid manager is there to take a limited amount of money and time and ship the best thing their team can make within those constraints. So sometimes managers decide things one way, and engineers argue for a different way, it's always helpful to be able to see the problem from the other person's shoes. And yet my experience is that line managers, often drawn from the ranks of engineers, are more able to see the constraints the engineer is working under than the engineer is able to see the constraints the manager is working under.
I don't know if there is a 'right' way to blend those two roles. I suspect that if you're in a large company as a manager and spending a third of your time coding, you might want to check with your manager on how they perceive your performance. If you're in a small company and write no code you might want to check with your team to see if they feel they have it covered or not. But I can't imagine there being a 'blanket rule' like spend X% of your time coding that would have anything close to universal applicability.
Totally agree with everything you said here. The general response here is (understandably for HN) biased a bit too far in favor of coders.
As a lifelong programmer who only reluctantly does management, I have to say that it sometimes seems just as hard for an engineer to understand what a good manager does as it is for a manager to understand what an engineer does. It's easy to make fun of a non-technical person because the terminology they don't understand is concrete but people management is every bit as difficult.
Perhaps the problem is that it's relatively easy to weed out an incompetent programmer, but bad middle managers can often blend in or otherwise find ways to make themselves look good to upper management. In that sense a manager who codes is at least some kind of positive signal.
But as a pure programmer I have to say this: two of the best managers I've had were not technical in any way shape or form. It's a mistake to think a good manager has to be technical in all cases. Good managers can add value in invisible ways dealing with the higher ups and shielding the team from politics and distraction. If the technical team is good and the manager has the appropriate level of trust then lack of specific technical knowledge need not always be a problem.
As you say, it varies according to circumstance, but a lot of commenters here seem ignorant to the fact that there's more to the job than simply understanding the programmers world.
> spending 30% on something that isn't making you a better manager would seem to be counter productive.
You're assuming coding doesn't make you a better manager... what if it does?
>There is also the question of scale, if you're a 20 person company I can easily see everyone writing code as well as doing other things, 50, 100, 2000 person company? Not so much.
Bill Gates shipped code up until 1989 [1]. Microsoft was between 3000 and 4000 employees at the time. Sure, he may be the exception that proves the rule, but maybe there's something to the notion that coding managers have a better sense of the technical market... of course, it depends on what market you are in.
I've spent most of my time as a coder, but have managed from 1-12 people from time to time.
Its a fair point, certainly understanding what the code is doing makes you a better manager. Sometimes that understanding is best done by coding up some things to test your understanding. I would be concerned though if, as the manager, your code was required to be complete prior to shipping the product. That would be a red flag for me.
The worst manager I've had, tried to often pretend he had any idea what he was talking about when pitching some gibberish during the 10min standup talk. He would often make suggestions like "and if you use Apache Solr? ". My face would be like ":/" and had to explain a subtle no (cause he was paying my salary). If he wouldn't be putting up that act, and just work the team dynamics without trying to provide technical solutions to experienced coders who will be like ":/", he would actually fare pretty well I think.
But I must say if you are presented with a tough technical problem, and human resources to solve it, but you fail to comprehend the problem and how you should direct your resources in solving it, it's going to be a tough cookie to make any impact other than wasting your time, and precious developer hours trying to do something you can't.
The best one I've had I worked with for a long time as a colleague freelancer, and 0 hour contract directly under him until we expanded to a 15-20 workforce.
He was an experienced PHP'er, and would argue even a better salesman and networker.
He would almost never write any code, but when push came to shove he would provide the fix within minutes time after a client made an upset call after hours.
Most importantly: Other than being able to point out strength and weaknesses of his employee's, he was never afraid to acknowledge his own, and always assumed our expertise over his. ( unless someone really f'd up of course :) )
I would much rather my manager (if I had one, which I don't) be a good /manager/ and a non-engineer, rather than being a bad manager and a bad engineer.
I want my manager to have a great engineering background, but not be interested in the actual engineering except for purposes of helping the engineers get their jobs done. In other words, build a good team, remove obstacles and get the heck out of the way.
This is the correct answer. The manager's job is to manage the people, not the project. That's what a tech leads and PMs are for.
A good people manager works to keep their employees comfortable, aims to avoid conflicts (and resolves them if they arise despite these efforts), mentors and coaches people to develop new skills, and shields them from politics. Doing the work of an individual contributor just gets in the way of that. The manager should be familiar with and understand what their people do, but leave the actual performing of that work up to them.
Today, I quit my team because of the manager. Nice guy, but zero knowledge of our code base, no interest to learn it, and no connection to what the problems we, as developers, were encountering. He didn't know, and didn't want to know.
With each proposal to address major technical debt issues, he had no context, no understanding, and would only reply with demands that we prove to him that our projects were impossible without addressing technical debt. (Side note: nothing is impossible, as long as you're willing to add more technical debt).
Between this, and other major problems, I'd had enough. I needed out.
I told him that I was taking vacation for the rest of the week (5 day weekend, wooo) and when I come back Monday, his manager and HR are going to help me find a new team (as they had previous agreed to). I'm fortunate to work for a company where that is possible.
Having a manager who codes 30% of their time might be asking too much, but having a manager working with developers who does not even read the code is not enough.
I hate this term "technical debt." I understand where it is coming from but it sounds like made up fairy dust and can be a little hard to take seriously.
It's a good enough analogy to what the problem is. You are buying a solution today at the cost of continued payments when you try to make solutions tomorrow.
Is it always bad? Hell no. When you need something right now, then you take a loan from the ol' technical debt bank. You get your product today instead of in a week. That can make or break a product.
But failure to acknowledge what it is, debt which you pay interest on in terms of time and effort, is a recipe for doom.
Sadly I think the term has been diluted a bit through overuse. I even hold myself to blame in sometimes referring to things as technical debt that are more accurately described as bit rot or just useful version upgrades (the ruby is particularly insidious about this).
I am just playing devils advocate here, but you said the manager had zero interest in your challenges. Did you have an interest in his challenges, why he is pushing for certain dead lines etc?
I don't know where to begin with this. This is just nuts!
This might work for some snazzy valley startup with 16 people all working on the same code base, but this is just completely, shall I say, naive and shortsighted. It smacks of someone who hasn't been involved in anything big, complex or been in the industry for any length of time.
Some people don't like to use sports analogies, but I do so I will.
An NFL team typically has a head coach, an offensive coordinator, a defensive coordinator, a special teams coach, QB/WR/RB/DB/LB/Oline/Dline coach as well as a strength coach, among some more in certain cases. Then there are the players. Offensive, defensive, special teams.
Imagine you are the head coach. Should you spend 30% of your time doing ANYTHING any of the players are doing? Should the OC or DC being doing the drills or what not? Maybe, maybe working out, but probably not like the players.
My position is akin to the OC on an NFL team. I'm in charge of teams of teams of people. Developers (in different areas/focuses), QA, infra, release, ops etc etc. This is LOTS of people. So, if I'm "coding" 30% of my time, I'm effectively looking at only one area. Should I be spending 30% (or some % number) of my time doing jobs in those other areas? And do I want my managers in those areas to do those things? Well, probably not. I want them to understand them, yes, have done that job previously, yes. More over, I want someone who can 1. engage the team 2. direct the team 3. hold the team responsible 4. tell me (or others) "no" and intelligently show the way for their area and 5. lead up and down. Coding is literally so far down the list it isn't funny.
So, no, a manager shouldn't be coding 30% of their time. If they want to and it doesn't get in the way of their actual job, fine, but that is not their job. Their job is to set or enact direction, lead and protect their team.
To go back to the NFL example. If I'm the head coach, I want the OC to know exactly the type of offense I want to run, put in the system in place, coach the coaches on that system and make sure everyone is on the same page. I don't want them running routes with the WR or practicing blocking drills with the linemen.
Some people say they need dual 30" monitors to code, I'm not going to disagree with their personal preferences. But other people (like myself) see zero difference in productivity between that and a 13" Macbook Air screen, which I've been coding on for years.
The whole "real machine" thing is just ridiculous cowboy posturing, unless you're doing video game development or something. A Macbook Air is just fine for web development.
Tiny screens, especially high res ones, are fine for coding. But working on laptops all day isn't great.
If you code all day, you will probably develop back problems if you don't sit with good posture.
You need to sit straight in a good chair, and look at a monitor at eye level about 2 arms lengths away. You need to type on a keyboard with good typing posture.
If you don't, then you will be okay for a few years, and then you won't.
I've seen RSI write off good programmers. It's pretty horrible - they build their lives and self esteem around a job, and then they can't do it. Bad RSI means that you can't touch a keyboard.
I've never seen any solid research linking slouching to back problems later in life. There's plenty of studies that correlate "bad" posture with discomfort, but none that I'm aware that correlate slouching with future back problems controlled by a group that does not slouch. I'd love to be corrected though.
You are right - I am basing this on my subjective experience.
Also, I suspect that this is a problem if 80% of your time you are at a desk typing, but if you move around a lot, it's not going to be such a problem.
That said, if you are coding at a desk all the time, a quick google finds research that backs up the posture -> injury thing.
No, I think you are coding on a budget or something. I have no idea. But you can increase your productivity once you move beyond coding in this small screens. You are being limited. Now, can you code amazing things on small screens and bad things on big ones? Well, this is a juvenile point. But, there is a difference and it is not cowboy posturing.
Maybe it depends on the sort of coding you're doing? And also how you use the computer.
I have both a Macbook Air and Macbook Retina - I have to say, I much more enjoy the Retina - more RAM (16Gb) and it feels snappier to multi-task.
I also tend to have a fair amount of browser tabs open (docs and stuff), so personal usage will influence things.
The author is the CTO of MongoDB - which is written in C++ - so speculation - maybe waiting 3x longer for a compile (or whatever the multiple is) is annoying?
Ever since they stopped the print edition. Actually before that, since they had the sci-fi guy on the back page who every week would change the colour scheme of his wordprocessor and write a whole article about it.
I remember reading once that doctors who manage other doctors still practice medicine part of their day. If so, why, when they have a business that also changes quickly and is actually life threatening, is that the case? Perhaps they realize remaining in touch with your field is valuable. Here are some papers with findings that indicate how practicing doctors as hospital administrators improve the quality of their hospitals above those hospitals that have just business managers. http://www.amandagoodall.com/papers.html
Why then is it the norm that so many developers who move into management do so to "get away from developing"?
It seems unique to development, or maybe just uniquely easy to see when someone is clueless about technical matters.
Anecdotally, all my worst managers were "out of touch" but thought they still were hot stuff technically. My best were either completely non-technical and trusted their team, or were developing at least 1/4 of the time (and he worked mostly automating all the crap work we hated and fixing bugs).
If you have to be told you should still be writing code you've probably already lost it (or never had it to begin with). I'm surprised by the people here arguing so strongly against something that is just common sense to anyone who truly cares about software development. Sure the 30% figure is debatable, but you're splitting hairs if that's what you think this is about.
There are too many people who are completely incompetent in management positions who effectively hide their lack of knowledge and skills because they are never put to the test. Moreover one shouldn't want to completely lose touch with the processes and techniques of development and design of software. How much involvement in code is required to be effective is perhaps debatable, but that you should be involved definitely shouldn't be.
From following Mongo on JIRA, I have noticed that Elliott spends time coding, and could venture to say that he is led/allocated work by Dan Pasette (who is the SERVER team leader). A lot of recent Mongo releases have been delayed by over a month, with some features and fixes being delayed to 2.8.
If Elliott wasn't involved in the coding I doubt he would understand the pressure the team deals with, and how realistically would his explanations to say $150 million investors be (not disregarding that Dan and other team leaders would provide details status reports)? Of course this is a grand assumption, but when I read his article last week, I came to agree with it. In my field of work, I see it all the time, over time a lot of managers lose respect from us subordinates. They no longer make accurate project estimates, their staff planning is unrealistic, they lose some of the peronism solving skills that got them there, etc. I don't expect them to go down and do the dirty work, but I acknowledge that sometimes if such was possible in our line of work, they would benefit a lot in keeping in up with us subordinates
I'm lucky enough to have managers that care about the people under them and I think that's good enough so far.
They would listen to advises/opinions, they would try to diffuse stressful situation, they would try to communicate what's necessary, they do negotiation fairly (got to give something to get something back).
As a result, I would give more to them (within limits, of course). At the end of the day, it's a win-win situation: I make them look good, they make sure I'm happy and not burn-out.
Background: both managers code before, one has MSc in Quantum Computing, the other does a lot of infrastructure/big-enterprise system (batch processing) so their backgrounds varies with the only commonality between them is that they both come from *NIX background and understand DB/Infrastructure rather quite well.
It's very hard to be an engineering manager (lots of examples in this threads why they don't like their managers or their previous bad experiences) and if you found a "matching" one with you, priceless. Of course, nothing is forever...
This sounds more like what a Senior Developer/Engineer should do, not an Engineering Manager or a PM or a TPM.
I seem comments here that "used to code" managers were either the worst or the best manager they ever had. However, it's the job of the Senior Developer to represent the engineering concerns of the team. It's the job of the Manager type to sit between the Engineering Team and the Senior Management, deal with paperwork nightmares, prioritize major work units, set deadlines and manage both up and down.
The Senior Dev should sit at a high level of the actual business of the engineering, dip down from time to time to spot shoot thorny issues, but they should prioritize the specific engineering items and keep the team well fed with work. It is a management function, with expertise in very hard engineering problems.
Sometimes the Senior Developer might represent that some work item is problematic for whatever reason and try and keep the team off of it. The manager, knowing the strategic priorities of the upper management, can either chose to manage this up, or override the Senior Dev and manage this down depending on the situation.
This is something that Senior developers aren't in a position to understand. Representing only engineering up means that unpleasant shit work is often just not done. It sucks, but needing to press your team into doing work they don't want to do is how things get done.
It may sound like overspecialization, and on small teams it is. But with large engineering groups, you don't want to tie up the Senior Dev, who's basically the guy who beats the drum on a slave ship, with being the ship captain.
This is really hard to understand until you've been in a medium to large sized organization and had to manage there. Managing takes an incredible amount of time. Most managers don't stop working when they leave work. Hell putting together a decent proposal might take 2 or 3 months of 50-60 hour weeks.
At least from a big company perspective: This breaks down. Any set % for coding doesn't work because there are so many 'big company' problems to deal with already that take up enough of their time. Either you will end up fixing trivial stuff that a coder would have done in 10% of the time you took or you will spend too much energy on this and lose track of your actual job.
Ideally I want managers who can code / have coded for a long time in their history so that they understand the software development world. But I actually want them to do time management, people management, expectations management, customer co-ordination, issue prioritization etc.
IOW - Engineers can code. Engineers usually can't do those other things without flinching. Leave engineering to the Engineers and management to the Managers.
Yes, and developers should manage 30% of the time and do design work 30% of the time. You know, because good management and good design is essential to a good product, and just saying that you have "done some" design or management in the past isn't good enough.
Yes, but the point being made here is that managers should do more. They should spend all of a whole 30% of their time coding, which presumably includes real coding projects, not "some simple" coding.
After all, if all you're doing is checking in bug fixes occasionally, how are you really going to know the advantages and disadvantages of redis or puppet or any of the other tools used on a daily basis on engineering teams.
I suppose it depends on what you/your-organization views as the realm of "management". I like Joel Spolsky's suggestion that they should just be moving furniture out of the engineers' way. Of course, he cites Microsoft, and I know how many of us feel about that company.
"At Microsoft, management was extremely hands-off. In general, everybody was given some area to own, and they owned it. Managers made no attempt to tell people what to do, in fact, they saw their role as running around, moving the furniture out of the way, so their reports could get things done. "
You can average it out at 30% of the time, but in a given week, you can't commit to it, because a greater responsibility of your job is being available to manage the unexpected. That makes it difficult to integrate someone in that role into a team in terms of dependency management.
There is also a risk in being in a position of power and being seen to assign yourself the most interesting work. I have seen this happen in one team, our manager was a good guy, but somehow he always used to get the sexy work like playing with new kit, and the team got the gruntwork. It led to resentment and undermined his authority (tho' because he was a good guy, as soon as he became aware he was doing this, he stopped).
> You can average it out at 30% of the time, but in a given week, you can't commit to it, because a greater responsibility of your job is being available to manage the unexpected
I'd argue that your job is to teach others how they can best manage the unexpected. Then you should only be involved in the really exceptional circumstances, allowing you more time to tend to your (metaphorical) garden at work. If writing code is part of that, so be it. But the bulk of time, I'd argue, ought to be in mentoring others.
The best managers I've worked with don't run around like chickens with their heads cut off, constantly responding to fires.
Depends what you mean by "fires". If a customer comes along with a new requirement, how do you predict that? Then your job is figuring out if it can be done, the best way to do it, if you have people free to do it and test it, if doing this for customer A will have any impact on customers B-Z, if there are any currently in-progress features you could or should cut to work on this, whether to push back on the customer and say, not in this release and how to do that without disappointing them too much, etc etc etc.
Basically a manager's role includes being the interface between his team and the outside world, and the outside world is by its very nature chaotic.
I don't think the average professional programmer gets to code in much more than 30% of working time. Too much time gets spilled looking at documentation, sitting in requirements meetings, etc.
The problem is more that, to get something done while working 30% of the time, the CTO has to cherry-pick the fun projects where things can be accomplished quickly without the time-consuming slogs. That can cause morale problems if the rest of the team is spending a lot of time on slogs. One might argue that that's a sign of a deeper problem, but few companies have figured out how not to generate drudge work when at significant scale.
I've personally seen horrific technical judgement calls made by managers who used to code (usually not in an environment like anything they're actually managing). There's a huge, dangerous class of problem where you think you know what you're doing, but you don't.
"It's not what you don't know that hurts you. It's what you know that just ain't so." - Satchel Paige
When the fates of a whole team of individuals rest on your judgement, it's best if it is grounded empirically or at least humble enough to account for the possibility that you could be mistaken.
Ignoring the dubious points of this article (30%, MacBook Air) I think a vital question being overlooked is whether a newly promoted manager actually wants to continue coding. Some will, some won't.
The atelier system seems to be a good match for this field (given that what we do is effectively arts and crafts.)
Regrettably, the facile access to information by the current crop of practitioners of this craft has blinded the clearly novice to the necessity of donning the disciple's apron.
My best managers were the ones that could and did code occasionally. Not just a side project of their dreams, but the same product we were working on, to feel the same pain, to understand the reasons of our decisions.
I have had good politician-managers who were excellent in corporate politics, but that is not the same as having an eng-manager.
You're not really making a point, besides "a manager is not a coding position". This article is explaining why the author thinks it should be. It's not enough to say that managers shouldn't code, you need to demonstrate that either the authors points are wrong, or that there's a greater risk by spending 30% of your time coding.
FWIW, I spend probably 30% of my time coding, I manage 13 developers, and I'm capable of hiring more people. If you're not good at pushing autonomy down on your team, you'll make yourself a bottleneck and have no time left to code. If you hire great people, and trust them to make the right decisions, a lot of traditional management overhead vanishes.
If I am going to give myself wriggle room, its that the vast majority of problems I have seen in poor software management have not come from a ex-Developer who has lost touch with the codebase, but from the other issues you / OP make - delegation, focus on team growth, structure and process improvement etc.
If someone is self-diagnosing and saying "aha the reason this is all falling apart is because I am not coding more" its unlikely to be the correct answer.
When I was a manager in a big corp, 5% to 30% is spent code reading (basically understanding the machine). Many times together with the team / owner of the component.
My job was not to do code review - we had a good process in place for that. It was always important to understand what is the internal state of the machine we are building/maintaining. So that I can answer to VP or PM team when they asks "we need to so X".
This is very true, but to be a good engineering manager, it's hard to fit all the other things in: Representing the team in dreaded meetings, coaching, hiring, fire, career advice, direction, etc.
It is a very fine line to balance. 0-10% is too little. After 50%, you're no longer a manager.
I used to manage an engineering team, and probably did spend that much time coding. Often, it was protyping or proving concepts to then pass on the engineers on the team to complete.
Yes, engineering managers absolutely should understand how to code, and understanding concepts like technical debt, unreliability of estimation, etc. goes without saying. And it's awesome for a manager to be familiar enough with the tools and work to be able to implement a quick critical bugfix or similar when unexpectedly necessary.
But if they're a good manager, it's far better for the organization for them to be spending their full time managing. Let coders code and managers manage, as long as they're both good at their jobs. The author's argument makes as much sense as saying a professional baseball coach should be spending 30% of his game time actually playing with his team.
And honestly, this is just BS:
> Once a person stops coding for a significant portion of time, critical connections to the concerns of developers atrophy.
Citation needed. It sounds as fake as supposed facts like we only use 10 percent of our brains, or other hogwash.