[nodefortytwo]

For me I have always found the best projects to work on are Developer Experience projects.

In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i'm delayed it doesn't really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.

[ojn]

As others, I 100% agree with this and it's what I've also been focusing on as a manager.

Someone told me: Once you have 10 people on your team, if you spend 100% time coding, you increase amount of coding by 10%.

Instead, either spend time finding that next hire (increase by 10%), or work on other things that improves the team's productivity even more.

For me, the hard part is when the team size is ~5-8 people. Too big for me to be 80% technical, but usually not quite such that managing is 80% either. This is when it's easy to sign up for critical tasks and get interrupted due to manager stuff, and as a result work 160% total. Once the team grows it usually gets easier.

[khalilravanna]

Ditto on this. I've been doing this by doing things like updating our libraries to be more secure, implementing lazy-loading, speeding up our build times, etc. Things that all increase engineering productivity and happiness and simultaneously aren't necessarily things that would be prioritized to be worked on normally. And of course as you point out, they're all things that can be worked on without blocking anyone while I get pulled away from code for sometimes days at a time.

[hinkley]

In a lot of organizations a Lead Dev is still a coder, but keeping an eye on the long game.

Personally, I think that the sort of code you're talking about here is a big part of the mix of things that a Lead should be working on, or at least championing. You don't actually want these people to have too much code with their name on it for the same reason you don't want Managers to do it: It gets treated as a sacred cow whether you want it to or not.

For myself, I'd estimate it's about a 40-40-20 split between DevEx code, the most safety-critical functions in libraries, and example code respectively. But, I'd aspire to flip the last two numbers (on a high functioning team I should be able to trust other people to do bits I barely trust myself to get right).

And unless you enjoy bottlenecks (some people do because it makes them feel special), you should be trying to get most of the code written by people of average skill (the peak of your employee bell curve). So if I'm writing even half as much code as they are, things aren't going well at all. You want a light touch.

[ArcticCelt]

>DevEx code

I am trying to understand the meaning of this word through context and/or through Google but I only get some social media platform. What is DevEx.

[hinkley]

Honestly GP is the first time I’ve heard that name but it’s an area I care about. Way too many of us work harder instead of smarter, and I used to joke with a UX friend that we were going to steal all their people to work on dev ergonomics.

[JimDabell]

Developer experience. In other words, improving the tools your developers rely upon to do their job. It's like UX, but for the development process.

[walshemj]

IBM called this role the toolsmith in a chief programmer team, a 1970's development paradime.

I have worked in an early web dev team that sort of worked like that at BT I was the backup/toolsmith.

[hinkley]

Ive been called a toolsmith before, but I fear that label misses the mark. I do what I consider to be the barest minimum of user studies (approximately what I don’t think my boss will notice) and I don’t observe others putting half as much effort or empathy into it as I do.

I don’t know if I’m crazy or living in the future, but it’s definitely frustrating and a little alienating.

[jon-wood]

This is exactly what I do, currently my main coding project at work is a library to improve our tracking of system level metrics across applications. If I get some time I can add a few more things that suddenly get tracked across multiple projects, making debugging easier in the future, and if I don't nobody really notices.

[WrtCdEvrydy]

If you can hook into one of your upstream, this becomes even easier.

We call this the '@companynamespace' layer, includes wrappers for internal APIs, and additional sugar we use everywhere (AWS, status, metrics)

[jon-wood]

That's much what I'm doing, a standard set of utilities that any service can depend on and use without thinking too much about it.

[basilgohar]

I apologize for not having a lot to add, but I had to upvote and reply for this phrase alone:

> make their lives easier (the (almost) entire point of being a manager)

I am glad I am not alone in this, and sadly, I feel that way most of the time.