That might be taking it a bit too far?
That might be taking it a bit too far?
What does that mean?
So sometimes a headcount can be an engineer, a manager, or both, and still be an embarrassment to git commits everywhere.
We have the abstraction of job titles or categories to help us reason about what a job is. We do this for a variety of reasons, but in this case the reason to do it is to help people understand whether this advice might apply to them. Ultimately, a job is whatever it’s primary goal is, and you said yours is to empower junior staff who report to you. That makes you very different from many (most?) senior/staff engineers I have met, who are primarily metric’d on their engineering work. Since your primary job is a management function and you write a lot of code, that makes you a manager with some (or many, pick whatever modifier seems appropriate to you) engineering responsibilities.
Bringing it home, if a reader is an engineer (or IC if you prefer to avoid the fraught term) and not a manager, this advice doesn’t apply to them very strongly. Yes they should care about junior colleagues, and they should absolutely make time for deliberate peering and mentoring, but they should focus on doing engineering (which can include docs writing etc) primarily.
Unlike almost anything else you could be working on, turning someone from nonproductive to productive, or more productive, has compounding effects that can quickly help or hinder the longer term objectives