[zusammen]

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.

[evidencetamper]

> 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.

Most mediocre managers I had were very focused on relationship building. The kind of manager that would need a hobby project to keep current, instead of being the most knowledgeable person in the room.

[SOLAR_FIELDS]

The author starts off with this statement:

> 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.

[mandelbrotwurst]

People might compete for the work they view as relatively more attractive for a variety of reasons even when they are quite busy.

[pc86]

IMO if an EM is taking the fun stuff, or the high-profile promo packet stuff, that's a symptom of a lot of very bad things. My boss is an upper-level EM and has at least a few PRs in a couple projects every sprint, and it's almost entirely boring-but-blocking stuff, or stuff that nobody wants to figure out, or stuff that is important but not sexy and not likely to get anyone noticed. He's not writing new features or writing UIs that are getting put in pitch decks or anything.

If I were an IC and my boss was picking the sexy work I would leave. If I was a director and one of my EMs was picking the sexy work I would fire them.

[LeafItAlone]

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.

[bryanlarsen]

> 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.

[scarface_74]

A POC should just be a happy path to prove a concept. I had a CTO who would routinely throw together code just to prove out an integration or another concept with hard coded values everywhere and drop the code in Dropbox for me to lead the effort of making it production ready as the architect. He would go back and forth with the vendor until things worked.

This helped me out by leaps and bounds. I was usually swamped with other research. I would then make it ready for production or lead the team to and take care of the edge cases, integration with our config system, logging and alerting, etc.

There is a huge difference between a POC and an MVP. An MVP should be properly designed and scaffolding that you can build on, a POC doesn’t take those things into account.

[LeafItAlone]

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 resistant to ideas that don’t follow a pattern until they see it. And sometimes my communication around the initial idea is poor and the best way I can communicate is an implementation.

[james_marks]

As with virtually everything in this thread, it matters how you do it. Sounds like you did it well.

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.

[nobleach]

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...

[LeafItAlone]

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 have for that individual is immeasurable and I’d go work for them again in a heartbeat if they asked.

[otherme123]

And OTOH, nothing worse than a manager that don't know what he wants nor how to do it, but he "will know when it is right", and keep you redoing stuff.