[jetako]

> 1. Keep Coding

Hardest pill to swallow, but it's mostly true. The old adage, "If you want something done right, do it yourself" is a subversive kind of fallacy, because it's half correct. Yes, you could probably get it done better and sooner, but every minute you spend doing it yourself could have been invested in empowering your team.

[Waterluvian]

I knew a manager who committed personal hours to some really neat coding projects but always avoided coding in his job. I think it's valuable for managers to at least understand what the engineers are talking about, even if they couldn't do the work themselves.

I also remember the headaches caused when the company went into a sort of panic mode and he ended up doing actual coding on critical path projects in some attempt to dig up out of the hole. I saw that sign as, "the General has his sidearm drawn" and promptly got out of there.

[rb808]

Yes it is mostly true if you are going up the career ladder all the way to executive level.

However I've seen a bunch of people hit middle-management then stop and its a really vulnerable place if you're looking for a new job. I think its really important to be able to keep some coding in new technologies as they become popular.

Perhaps the best is to work with your developers code - write integration tests, evaluate checkins, research new tools.

[bonniemuffin]

+1, I think it's critical to stay technically sharp, but that doesn't have to mean pushing user-facing code to production. I can only recall one time I've actually checked in production code since I transitioned to manager (and I definitely felt like I was shirking my manager duties by sinking a day into it), but I stay close to the code in 2 ways:

(1) I review the majority of the code that the team writes, and I also read other people's reviews to evaluate our code review practices.

(2) I hack around with new tools & technologies to evaluate them. This has resulted in some code bits in wikis documenting "here's how to get started with this thing", but not touching any prod systems. I usually save this kind of thing for our "personal projects"/hackday days at work.

[klenwell]

> Perhaps the best is to work with your developers code - write integration tests, evaluate checkins, research new tools.

Without really planning it, that's where I ended up. Also: establishing best practices and ceaselessly promoting them.

[Jedd]

> Yes, you could probably get it done better and sooner ...

It's a fine example of the potentially counter-intuitive 'Law of Comparative Advantage' [1]

[1] https://en.wikipedia.org/wiki/Comparative_advantage

[zmmmmm]

> Yes, you could probably get it done better and sooner

This is a really hard one for me when under pressure: knowing that I can do it myself correctly in about an hour, but giving to to someone else who will probably take several iterations before it's right, resulting in a week or so turnaround and probably 8 hours of work. Or worse, half a week and it never being "right" because we just don't have time.

[bonniemuffin]

I've struggled with this a bit as a new manager, and eventually came to the realization that I was so afraid of micromanaging that I was letting people struggle and fail more than I needed to, by not giving them detailed enough instructions.

If you could do the task yourself in an hour, then you could also probably give very detailed instructions in 45 minutes (which ends up with a written plan in a google doc or similar spelling out every detail of how it's going to be done), or even pair on it to get them started.

Maybe you haven't saved any time over doing it yourself (maybe it's even taken MORE of your time!), but you've ensured the thing got done right, and you've also helped level up the skills of the person who did it, so that next time they'll be more capable of taking on a similar task alone.