31–40 of 319 posts
> Do code reviews. Don't just skim PRs (sorry, reader!), but really dig into them: run the branch locally, test it, think critically about the design and the implementation, and provide feedback. Record a video of your review to highlight things that could be better. Please no! Most managers want to increase output and engineers are aware of that. It is exceptionally frustrating when your manager tells you during you…
> Do code reviews. Don't just skim PRs (sorry, reader!), but really dig into them: run the branch locally, test it, think critically about the design and the implementation, and provide feedback. Record a video of your review to highlight things that could be better. Please no! Most managers want to increase output and engineers are aware of that. It is exceptionally frustrating when your manager tells you during you…
But I don't think a manager necessarily needs to be at this level of detail.
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.
> Do code reviews. Don't just skim PRs (sorry, reader!), but really dig into them: run the branch locally, test it, think critically about the design and the implementation, and provide feedback. Record a video of your review to highlight things that could be better. Please no! Most managers want to increase output and engineers are aware of that. It is exceptionally frustrating when your manager tells you during you…
Recording a video seems excessive to me. No one has the time or desire to watch me bloviate about something that I could say in a few PR comments that can be quickly skimmed.
Earlier quoted context omitted.
While that is possible, I think a good manager recognizes these pitfalls. My philosophy is "everyone has to scrub toilets once in awhile - that includes me". You'd have to ask my direct reports but, I'd like to say I lean more toward taking the "grunt tasks" that I don't think are super helpful for my folks' career growth. Then again, I've been called a bad manager on Hacker News so...
That’s how I see it myself. Obviously being a good manager is first and foremost, but I’ve always had more respect for managers that I know can (even if they never do) do my job as well as bring a manager. Early in my career at a startup I had a manager that was both and excellent manager and right there in the trenches with you when issues arose or business deadlines were approaching. The amount of respect I still h…
Generally, 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.
As an engineering manager, I actually pick up the stuff other people don’t like to do or stuff I notice that is hanging out there. My goal is to move the team forward. 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 effects they didn't consider.
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 better sense of IC’s contributions by writing code.
There are ICs who play politics very well and sell themselves but that set is not the same as the ICs who deliver. If you are writing code you start to notice which ICs have written key features, built critical APIs or worked on hard problems because of comments and Git blame.
3. Understanding your codebase.
I hope most managers have solid CS and engineering fundamentals but that is a necessary but not sufficient condition to grasping the full picture. There’s a reason it takes time to ramp up to full productivity on a new codebase. If you work in the codebase and have had to use that one annoying but critical library or dealt with that tech debt from 2 years ago then you know what is hard and what isn’t. I’ve found when a codebase has a quirk that makes developing certain features hard all of the non-technical people keep forgetting why we can’t do that thing and all the technical people have it burned into their brains.
i like the analogy of a sports team coach for being a manager. You can motivate, cheer, train, and drive the team to victory but you can't step on the field.
Summary: Managers who know how to manage, but don't know how to do anything are not the best managers. The best managers are the great individual contributors who never ever wanna be a manager but decide they have to be a manager because no one else is going to be able to do as good a job as them.
It was a terrible mistake for me. So much of my value as a manager was being understand what the engineers were doing. I am not a great programmer but I can do it, and I could usually understand what an engineer was trying to do from looking at their check ins rather than listening to them in stand ups. I was just not that useful. There were times when the team was doing things that I knew I had seen done before with much better before with different methods, but just talking about it was relatively ineffectual.