Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…
Just curious have you managed people? At what capacity (tl? Em? Pm?)? How big was your team? What was the company env like in which your team(s) functioned?
Should managers still code?
81–90 of 319 posts
Re: Should managers still code?
#82Strong yes for 3 reasons 1. Reducing dev friction. When I had managers who coded they were ruthless about removing friction in the dev and deployment pipeline because they had to deal with it too. If build times went up, deployment infrastructure broke or someone’s PR broke dev they would roll it back immediately. If someone consistently blocks PRs the manager noticed the trend and would address it. 2. You get a much…
Just curious have you managed people? At what capacity (tl? Em? Pm?)? How big was your team? What was the company env like in which your team(s) functioned?
But that a manager should always code is not something i found helping the team or the manager - all the time. One size does not fit all. In startups yes frankly there is hardly a need for a manager and it is TL, TPM, EM role combined into one.
In larger cos though a most managers are innundated with all kinds of non technical work (meetings, alignment, perf management, product discussions etc). While having coded before is a great thing keeping uptodate is actually robbing the manager of time for all other things on the plate (and those actually benefit the team beyond what meets the eye).
Besides at large orgs there is also so much technical (think large scale design and integrations) knowledge that a manager needs to keep track of which also needs time investment.
Then there are various level/career related things that necessitate one or more TLs a manager needs to work with or manage and coding often gets seen as a manager "not doing their job" or worse stealing a junior engineers opportunities.
There's a lot more that is very environmental but hope sets some context.
Re: Should managers still code?
#83Background: I used to be a developer and have managed developers. Now I work in info sec and manage info sec.
Longer answer: this question has been discussed throughout my career.
(1) Does it help for a manager to understand what a team does and needs to do? Absolutely yes. Some managers can do this without domain experience but it's a lot harder for them and the team.
(2) Should a manager keep doing what their team does? Probably not. I can actually do most of what my team does faster and better, but they need to learn to do it. I don't scale. I can mentor them, and if there's a need for more resource I can get it for them.
Edit: I do actually still write code - but just in my own time because I enjoy it.
Re: Should managers still code?
#84Don’t allow your skills to atrophy. If you get to a high position, it’s much harder to find a job at that level. If you can code, you can always find something. If you can’t code, and you can’t get a manager role, you’re in trouble.
Are you proposing that they do coding on the side after they get off of work? I have a strict policy of “no side work” and I have since graduating from college in 1996. When I get off work, I don’t think about computers again until I go back to work the next day.
I’m not a manager. But I am now a “staff software architect” working full time at a third party cloud consulting company after pivoting from software development and doing a previous stint working at AWS in the consulting department (full time direct hire - AWS Professional Services).
My specialty is supposedly developing applications using AWS services. But as I moved up I find myself doing no coding.
My job is half working with sales and being the first technical contact for a customer and writing long and detailed requirement documentation and getting the customer to sign the contract for us to do the work. The other half is as a tech lead coordinating between the customer, project manager, sales, and the subject matter experts on our side who lead/implement the various “work streams” (development, data, cloud architecture, etc).
First issue, when I was looking for a remote job last year and the year before as a developer as a plan B job, every opening had hundreds of applications and I heard crickets. This has never happened to me and I looked for software development jobs in 1999, 2008, 2012, 2014, 2016 and 2018. The job at AWS fell into my lap in 2020.
It’s a shit show out there right now for software development jobs especially remotely. Did I mention I was looking for regular old enterprise Dev jobs?
On the other hand for differentiated strategic cloud consulting jobs, I had no problem getting offers quickly.
Re: Should managers still code?
#85> If you mean being the primary implementer of features, then probably not. It's my belief that any engineering manager worth their salt should push back on this and argue for a seat at this table, every single time. I don't want to work for someone who is disinterested in new functionality in codebases under their purview.
I need them to then trust me to accomplish the objectives myself on smaller implementations or to lead the team on larger implementations.
Re: Should managers still code?
#86I think managers are often out of touch with what the team puts up with.
Re: Should managers still code?
#87When I've worked as an engineering manager I've found the advice to "stay out of the critical path of getting features into production" to be very helpful. It's difficult to commit to coding timelines as a manager, and it harms your team if you are the bottleneck to shipping something. But... keeping your hands in the mix elsewhere helps you stay informed and make better decisions. I found writing things like interna…
Re: Should managers still code?
#88Earlier quoted context omitted.
> I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun. I've had managers do this to me. What an awful experience. Because they're the manager you can't push back against the awful design decisions they made. They feel it's almost done so don't understand that it takes a lot of time to deal with all the side eff…
That’s very valid feedback. I hope I don’t come across that was and do have some evidence (not to be laid out here) supporting that I don’t. I think I’ve created a team and structure where the developers I manage are comfortable telling me I’m wrong or what I didn’t consider. It happens weekly. We value honest feedback highly. We do it with respect, but we do it. We just have some developers on the team that are resi…
I’ll add one other great edge in building a quick POC yourself. Sometimes your idea actually _is_ bad, and trying to articulate it in code helps you see it.
Re: Should managers still code?
#89Generally, no. There’s a risk of unfair competition for work (they can delegate the stuff they don’t want because they have political power) and their code often becomes “untouchable” because few will call it out if the code is bad. A hobby project to keep current isn’t a bad idea, though.
> unfair competition for work That's a very good indicator of a bloated institution. People have to compete for work instead of pushing it away or avoiding it because they already have their hands full. But I don't believe there is a general rule that applies here. Most great managers I had were deeply technical and involved in the nitty gritty of the projects, including coding the very spiky aspects of a project. Mo…
> I think that there is a big difference between being in the code and writing code. All managers should be in the code, but not all managers should be writing code.
I think it's not possible to be in the code without writing code. People can pay lip service to being in the code as the author indicates, but as we all know there is no substitute for actually sitting down and writing the code yourself in terms of understanding the actual pains and struggles.
And my anecdotal experience says that if you aren't writing at least some of the code, more often than not the disconnect between the manager and what the team is doing grows and grows.