How much time should I spend writing code?
One of the questions I asked of myself when I became a manager, and that I’m also asked a lot in my work coaching front-end and tech leads is:
How much time should I spend writing code?
Early on in my management career, when I took on more direct reports, I was jokingly advised that I just wouldn’t have time to code, so I shouldn’t try. This never sat that comfortably with me. Seriously, no code at all?
So it was with great joy that I read Charity Majors fantastic article Engineering Management: The Pendulum Or The Ladder this week. Please, go and read it right now. It has rabbits and unicorns.
It also includes this wonderful pull quote:
You will be advised to stop writing code or engineering.
✨ Fuck That. ✨
You still need to read the article, though. This doesn’t really reflect the rest of the content.
Keeping your hand in allows you to be a better coach and mentor, a better code reviewer, a better facilitator, a better remover-of-blockers and a better technical communicator. Don’t stop.
So the question remains: how much time should you spend doing it?
** BZZZTTT ** Wrong question.
Charity’s advice (and what I ended up working out for myself) is:
Stop writing code and engineering in the critical path
Here are some of her examples:
- Authoring a feature? ⛔️
- Covering on-call when someone needs a break? ✅
- Diving on the biggest project after a post mortem? ⛔️
- Code reviews? ✅
- Picking up a p2 bug that’s annoying but never seems to become top priority? ✅
- Insisting that all commits be gated on their approval? ⛔️
- Cleaning up the monitoring checks and writing a library to generate coverage? ✅
The list of things that don’t get done in the critical path is pretty big. This is not to say that the team shouldn’t be doing this stuff, but that as a lead you can help out without becoming a bottleneck to core value work.
The great thing is that doing some of this work allows you to understand much of what is happening in the critical path without getting directly involved in it.
So you’re not just keeping your coding skills sharp, but maintaining your situational awareness.
What non-critical engineering work could you address for your team?
All the best,
– Jim
