Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A dev's thoughts on developer productivity (2022)

sourcegraph.com

Post reply on HN
Print view View original

21–30 of 55 posts

Re: A dev's thoughts on developer productivity (2022)

#21

Post by ipsi »

OJFord wrote: post #8
badgersnake wrote: post #4

As a staff engineer with team lead responsibilities I would love to be able to attain that kind of flow. Unfortunately, a lot of my job is liaising with product managers and making sure the team is focused on the right things or writing and reviewing documents. This work needs to be done but it doesn’t leave me much time to get into coding things and thus I would score very low on that productivity measure because I’…

> staff engineer with team lead responsibilities Bit of a tangent, but I'm just curious if that's that some staffs (but not all) and above are leads, or if it's that engineering & management tracks are orthogonal but not mutually exclusive? I was attempted to idly discuss/suggest the latter was a possibility recently (not in a position to effect it), and I'm not sure I made my point very effectively or coherently. If…

From my limited experience, Staff+ seems to have a lot of the same responsibilities as a manager, but without the direct reports—they're both “leadership” positions and focus on long(er)-term planning, business needs, cross-team communication, and enabling others rather than doing the work themselves. Though in lieu of people management, Staff+ engineers do get to spend some time coding, but it's pretty rarely the majority of their job.

So to that extent, I think there's quite a lot in common between engineering and management tracks after a certain point, both because there's a genuine need for that, and because direct code contributions just don't scale in the same way that helping others does.

Re: A dev's thoughts on developer productivity (2022)

#22

Post by hsavit1 »

necrotic_comp wrote: post #5
mym1990 wrote: post #2

My couple of thoughts, just based on my own experiences, are that: there is typically at least one architect above me(currently two, don't ask me why) that is responsible in doing the higher level solutioning. While I am free to give feedback on things, and that feedback is taken seriously, it is a far cry from developing my own architecture. On a big enough project, there simply isn't enough time to gather requireme…

> The truth is that most companies won't pay for the extra productivity that you create for yourself, but they will happily take it for free. Fantastic way of putting it. Know this is a low-effort comment, but that's a great way to describe why over-extending yourself outside of the context of the overall mission isn't a good thing to do.

yep, companies thrive when they can steal as much surplus labor value as possible. you don't have to give them anything more that what you agreed to give them

Re: A dev's thoughts on developer productivity (2022)

#23

Post by rokob »

OJFord wrote: post #8
badgersnake wrote: post #4

As a staff engineer with team lead responsibilities I would love to be able to attain that kind of flow. Unfortunately, a lot of my job is liaising with product managers and making sure the team is focused on the right things or writing and reviewing documents. This work needs to be done but it doesn’t leave me much time to get into coding things and thus I would score very low on that productivity measure because I’…

> staff engineer with team lead responsibilities Bit of a tangent, but I'm just curious if that's that some staffs (but not all) and above are leads, or if it's that engineering & management tracks are orthogonal but not mutually exclusive? I was attempted to idly discuss/suggest the latter was a possibility recently (not in a position to effect it), and I'm not sure I made my point very effectively or coherently. If…

I would read these two pieces as they lay things out pretty well:

https://staffeng.com/guides/what-do-staff-engineers-actually...

https://staffeng.com/guides/staff-archetypes/

I think it all depends on who you are and what your team needs.

Re: A dev's thoughts on developer productivity (2022)

#24

Post by OJFord »

rokob wrote: post #23
OJFord wrote: post #8

Earlier quoted context omitted.

> staff engineer with team lead responsibilities Bit of a tangent, but I'm just curious if that's that some staffs (but not all) and above are leads, or if it's that engineering & management tracks are orthogonal but not mutually exclusive? I was attempted to idly discuss/suggest the latter was a possibility recently (not in a position to effect it), and I'm not sure I made my point very effectively or coherently. If…

I would read these two pieces as they lay things out pretty well: https://staffeng.com/guides/what-do-staff-engineers-actually... https://staffeng.com/guides/staff-archetypes/ I think it all depends on who you are and what your team needs.

I think this from your second link is closest to what I'm getting at:

> Somewhat confusingly, some companies use Tech Lead as a title, and others use it as a role. In this list of archetypes, the Tech Lead is one approach to operating as a Staff engineer, but it's quite common to perform the Tech Lead role without having the impact expected of a Staff-level engineer.

My point is a bit 'bigger' than how do you operate in your position as staff engineer and what does the org need from you, what I'm getting at is about the structure of roles themselves - like it can be that your technical track/ladder (junior/mid/senior/staff/distinguished/principal/fellow/whatever) is IC that managers are completely separate, not the same people (junior/mid/senior/whatever managers). It can also be that people managers are separate, but technical management of projects is intertwined with the more senior roles.

What I was thinking about specifically, not knowing really whether anyone does this or not, was the possibility of people being on at least one of those tracks, i.e. maybe both, but that they're distinct roles. So you might be a staff engineer but a more junior manager. (And you might manage a different team than you work in, I suppose, but that would probably be inconvenient and anyway isn't really important one way or the other here.) But I suppose it also depends how or if you divide technical and people management anyway. I just don't really have the keywords to find much discussing it; your links are good though, thanks, I'll read some more on the site.

Re: A dev's thoughts on developer productivity (2022)

#25

Post by rokob »

OJFord wrote: post #24
rokob wrote: post #23

Earlier quoted context omitted.

I would read these two pieces as they lay things out pretty well: https://staffeng.com/guides/what-do-staff-engineers-actually... https://staffeng.com/guides/staff-archetypes/ I think it all depends on who you are and what your team needs.

I think this from your second link is closest to what I'm getting at: > Somewhat confusingly, some companies use Tech Lead as a title, and others use it as a role. In this list of archetypes, the Tech Lead is one approach to operating as a Staff engineer, but it's quite common to perform the Tech Lead role without having the impact expected of a Staff-level engineer. My point is a bit 'bigger' than how do you operate…

Google has a title called TLM which is tech lead + manager which is meant to straddle the divide. In practice you have twice the expectations which are themselves conflicting with only the one salary. It is often used for ICs to try out management before making the decision which ladder to stay on. Most TLMs are at the staff level so kind of fits that staff engineer who is a junior manager that you describe.

Re: A dev's thoughts on developer productivity (2022)

#26

Post by from-nibly »

chrisweekly wrote: post #19
jauntywundrkind wrote: post #9

Devs I think are somewhat withdrawn, as a result of being under the yoke of ticket delivery. Being given the trust respect & capacity to roam & improve as we wander about systems is rare; we're judged on how quickly the task at hand is done. This is such Luddite, chained-to-the-machine endpoint that we are at. And it skips past so much of the raw joy & auto-enrichment loops that happens when there's time allotted to…

yolk (yellow part of egg) -> yoke (harness for beasts of burden) EDIT: but also and more importantly, your point is Excellent! 100% agreed - the ongoing process of discovery and continuous improvement of a codebase are signs of the best kinds of ownership / attachment, and sadly represents a huge blind spot and missed opportunity for the majority of "dayjob" projects.

I think you mean Eggcelent.

Re: A dev's thoughts on developer productivity (2022)

#28

Post by agentultra »

The only thing that works well for me is: thinking hard (ie: writing some definitions, asking questions, editing, repeat) and then writing some code. Then repeat.

When working on a team, splitting up work across modules/contexts/domains works well. I’ll give you an API you tell me what works well, what you still need from it, what errors there are; I’ll address them.

Nothing works better than trust and autonomy. I don’t tell you how to do your job, you don’t tell me how to do mine. You want me on the team because of my expertise and some of my values overlap with everyone else’s.

When working alongside non-technical folks, communication and trust is key.

Trying to quantify developer productivity and sell a system is what the snake-oil hucksters have been selling since the 90s. Management consultants, process engineers, whatever you want to call them. They’re selling something.

We’re knowledge workers. We’re not manufacturing cars or widgets. We learn. We design. We think. Our output is knowledge, not widgets.

Re: A dev's thoughts on developer productivity (2022)

#29

Post by AYBABTME »

OJFord wrote: post #8
badgersnake wrote: post #4

As a staff engineer with team lead responsibilities I would love to be able to attain that kind of flow. Unfortunately, a lot of my job is liaising with product managers and making sure the team is focused on the right things or writing and reviewing documents. This work needs to be done but it doesn’t leave me much time to get into coding things and thus I would score very low on that productivity measure because I’…

> staff engineer with team lead responsibilities Bit of a tangent, but I'm just curious if that's that some staffs (but not all) and above are leads, or if it's that engineering & management tracks are orthogonal but not mutually exclusive? I was attempted to idly discuss/suggest the latter was a possibility recently (not in a position to effect it), and I'm not sure I made my point very effectively or coherently. If…

It depends on the team, the projects, the phase of the projects and the weather forecast. To me this "staff" stuff just means doing more of whatever it takes while making sure the other engineers learn and grow, not doing everything yourself just because you're able to.

Sometimes it means plowing into code and implementing stuff, because that's the main thrust at the time and where the most effort needs to be focused. Sometimes it means backing away and researching problems at a high level to save others from having to get out of focus.

Whether that's team leading or engineering or managering is a moot point to me.

Re: A dev's thoughts on developer productivity (2022)

#30

Post by BurningFrog »

mym1990 wrote: post #2

My couple of thoughts, just based on my own experiences, are that: there is typically at least one architect above me(currently two, don't ask me why) that is responsible in doing the higher level solutioning. While I am free to give feedback on things, and that feedback is taken seriously, it is a far cry from developing my own architecture. On a big enough project, there simply isn't enough time to gather requireme…

Funny. I've programmed professionally since 1984, and have never really had an "architect" in the organization.

I almost only work in small companies, and in and near the agile world.

What I've learned is that while architecture is very important, it's best done after the code is written. It's hard to convince anyone of this who hasn't experienced it :)

Post reply on HN