18 ms·

A dev's thoughts on developer productivity (2022)

95 points by hogu 2y ago

mym1990 2y ago
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 requirements, architect the solution, and then build it out(for one person). By the time I am assigned the feature ticket, it is a morsel of the overall thing. I feel like I have reached a happy point of productivity where I am doing the work expected of me, and at times even exceeding, but not breaking my metaphorical back. 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.
- necrotic_comp 2y ago
  > 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.
  - axus 2y ago
    Over-extending yourself can lead to burnout. Pacing yourself and not becoming a problem is good for both the employer and employee.
  - tobestobestobes 2y ago
    I think that things like Agile are not an accurate model of problem solving and that making good software requires 'extending yourself outside', especially w agile or other modern management systems like many of us are working within. That is my experience. The actual effort is much more to make decent software that works and 'ticketing' makes it easy for devs to disown their own bad or incomplete work when it's convenient and can be disguised as working within scope. This bad work is then passed onto other devs (and the users) and/or converted to technical debt (oh look at all these bug tickets!)... When arguably the real and complete problem at hand was ignored because it was 'out of scope'. There is a 'shadow world' of work that exists outside of ticketing but is required to actually build the software. If you're not involved in that shadow work, then you may be a part of the problem. Problem solving is fluid and technical requirements and matters of approach aren't always readily available at 'groom time'. Work as a group, get uncomfortable if required, and don't go disappear with your ticket for two weeks and half solve a problem and bake the e2e tests. Most development work truly comes to a conclusion in a war room after the ticket is closed and with none of the original devs -- too much of the time these days. Reward devs for taking on more and owning parts of the codebase. AI threatens dev jobs because devs and scrum masters water down work and the system encourages shoddy, transactional work. Not really a criticism of the above comment ... But something I see a lot in enterprise software development. And I also do realize going outside of scope is risky and doesn't pay in the current management zeitgeist.
  - hsavit1 2y ago
    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
  - mym1990 2y ago
    Another thing to mention is that if you find a way to do 8 hours of work in 4, almost no company will just let you take the other 4 for yourself, unless you do so quietly, so you have just created more work for yourself by becoming more productive.
    - hollerith 2y ago
      Sure, but if you really did find a way to double your productivity, you can probably find a way to translate that into significantly higher income although probably not right away.
      - nsvd 2y ago
        Realistically, whoever manages you will take credit for the additional productivity and leverage it to get more money for themselves.
      - mym1990 2y ago
        This is probably true, but if we are talking about climbing the corporate ladder here...that is primarily done through peacocking to management and networking well enough to get to the next rung, not through being very productive. If you are a 10x employee, why would a company want to elevate you out of that and into management? But if you're going a different, more self-starter focused path, income opportunities should be increased, yes.
- casper14 2y ago
  Ive had the luck of recently having effort rewarded with fair raises. But can see how most companies won't do that
- johanneskanybal 2y ago
  I haven't had the pleasure in 20 years to work with an architect that added much of value, corporate structure and putting people in boxes is such a strange thing to me in software, if you work with senior people they should be able to drive and decide most anything with maybe a thin layer of general direction on top.
- BurningFrog 2y ago
  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 :)
  - arresin 2y ago
    Isn’t after too late though?
    - BurningFrog 2y ago
      It's really hard to design code before it exists! Once it's working, you know enormously more than when you started, and all you have to do is refactor the mediocre design you happened to build into something better, without breaking the functionality. With good test suites and solid refactoring skills, that is actually both very doable and often a lot of fun!
      - reverius42 2y ago
        Wish I could upvote more. Similarly, I always like to say you should plan to write (at least) two versions/iterations of everything. The first one bottom up, to discover what problem you're solving, and the second top down, once you know the problem.
        qohen 2y ago
        Or, as Fred Brooks wrote in "The Mythical Man Month" (1976): "plan to throw one away; you will, anyhow."[0] [0] https://en.wikiquote.org/wiki/Fred_Brooks https://en.wikiquote.org/wiki/Fred_Brooks [1] https://wiki.c2.com/?PlanToThrowOneAway https://wiki.c2.com/?PlanToThrowOneAway
        arresin 2y ago
        That’s great if you have the time for it but a bit impractical to write, architect, then refactor.
deleted 2y ago
[deleted]
badgersnake 2y ago
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’m hardly ever in the inner loop.
- dijksterhuis 2y ago
  > As a staff engineer with team lead responsibilities In my experience, lead ==> doing stuff to keep everyone else in "flow" or "not going off-piste". Sounds like you're doing a decent job of it :+1:
- OJFord 2y ago
  > 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 that is the case where you work, are you aware of any sort of name for that or keyword? Hard sort of thing to search for otherwise.
  - ipsi 2y ago
    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.
  - 2y ago
dijksterhuis 2y ago
This really resonates and tracks with my experience. Really like the vector sum concept, as most metrics for productivity tend to be pretty naff (not good). Some of the issue, in my own admittedly limited experience, is that some "important" folks often want the flashy ideas; they want someone to tell them there's a quick fix or a framework to solve the problem in 3x workshops over two weeks. It's unfortunately human nature to want the easiest solution. edit -- plus i think a lot comes down to fear (no control), which is also a thing. Managers also like metrics. It makes their end of month presentations look good. Which is important otherwise the team gets looked down on compared to all the other managers with amazing metrics. But, I could totally see something like this working well at smaller companies where stuff like that isn't a thing.
jauntywundrkind 2y ago
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 discovering and improving the system as you go. DIYers have such amazing enrichment loops, making systems work better for themselves all the time. Not just the much vaunted fast delivery now, but the ability to keep iterating & expanding & delivering without your constructs starting to clash & thrash. I love love Fogus's 100:10:1, on having many tangible places outlined where one might do something. Still dedicating yourself to something, but also giving yourself permission to hop around. Follow what feels good. https://blog.fogus.me/2015/11/04/the-100101-method-my-approach-to-open-source/ https://blog.fogus.me/2015/11/04/the-100101-method-my-approa... [Ed: s/yolk/yoke/, thanks for the fix folks!]
- elevatedastalt 2y ago
  yoke*
- ozim 2y ago
  That is why I promote FaF - fix anything Friday and try to fight off sprint load inflation, where it would be expected from team to do more and more. Then also promote “dev alignment” where devs come together to discuss architecture improvements or pick approaches.
  - cwalv 2y ago
    IMO it should be 'fix anything when you feel like it.' "Sprints" have given agile a bad name (to the extent it has a bad name, as in gp's complaint). The point is to optimize for changes, as they're inevitable, by: 1. Keep the code in a 'clean' (testable, free from cruft, etc) state continuously 2. Release continuously 3. Embrace YAGNI If short, regular sprints help with those things, use them. But sometimes they don't
    - 2y ago
dang 2y ago
Discussed at the time: A dev's thoughts on developer productivity - https://news.ycombinator.com/item?id=31414681 https://news.ycombinator.com/item?id=31414681 - May 2022 (88 comments)
m0llusk 2y ago
That is great, but can you make the BUY button bigger?
golly_ned 2y ago
This from Beyang Liu, Sourcegraph CTO, who plays up his stint as a Google intern to represent himself as a "former google engineer", and wrote this blog referencing Google 55x in a short article to associate sourcegraph with Google-quality tooling: https://sourcegraph.com/blog/ex-googler-guide-dev-tools https://sourcegraph.com/blog/ex-googler-guide-dev-tools
- itsdrewmiller 2y ago
  ... is an intern not a former engineer? I assume it was software engineering internship?
  - mydogcanpurr 2y ago
    No
  - reverius42 2y ago
    Definitely gives a different impression if you say "former Google engineer" vs. "former Google intern".
  - knighthack 2y ago
    I am not sure how you would conflate an engineer with an intern. That's like conflating a practising doctor with a medical student.
matt3210 2y ago
Hand written stuff (written or made to look written) needs to be in a more readable font.
from-nibly 2y ago
Developer productivity is about leveraging developer context into more stuff while making the developer do fewer things. Automate and shift left.
agentultra 2y ago
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.
- dualogy 2y ago
  > Nothing works better than trust and autonomy. > Communication and trust is key. > We learn. We design. We think. Our output is knowledge, not widgets. That's a manifesto I would sign! But let's not make it into one, because back then the originally-similarly-spirited Agile Manifesto couldn't immunize itself against "adoption" by — management consultants, process engineers, whatever you want to call them =)
itsdrewmiller 2y ago
Did McKinsey just lift the inner/outer loop concept here with no attribution? Does it also predate this article? https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity https://www.mckinsey.com/industries/technology-media-and-tel...

95 points by hogu 2y ago

mym1990 2y ago

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 requirements, architect the solution, and then build it out(for one person). By the time I am assigned the feature ticket, it is a morsel of the overall thing. I feel like I have reached a happy point of productivity where I am doing the work expected of me, and at times even exceeding, but not breaking my metaphorical back. 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.

necrotic_comp 2y ago
> 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.
- axus 2y ago
  Over-extending yourself can lead to burnout. Pacing yourself and not becoming a problem is good for both the employer and employee.
- tobestobestobes 2y ago
  I think that things like Agile are not an accurate model of problem solving and that making good software requires 'extending yourself outside', especially w agile or other modern management systems like many of us are working within. That is my experience. The actual effort is much more to make decent software that works and 'ticketing' makes it easy for devs to disown their own bad or incomplete work when it's convenient and can be disguised as working within scope. This bad work is then passed onto other devs (and the users) and/or converted to technical debt (oh look at all these bug tickets!)... When arguably the real and complete problem at hand was ignored because it was 'out of scope'. There is a 'shadow world' of work that exists outside of ticketing but is required to actually build the software. If you're not involved in that shadow work, then you may be a part of the problem. Problem solving is fluid and technical requirements and matters of approach aren't always readily available at 'groom time'. Work as a group, get uncomfortable if required, and don't go disappear with your ticket for two weeks and half solve a problem and bake the e2e tests. Most development work truly comes to a conclusion in a war room after the ticket is closed and with none of the original devs -- too much of the time these days. Reward devs for taking on more and owning parts of the codebase. AI threatens dev jobs because devs and scrum masters water down work and the system encourages shoddy, transactional work. Not really a criticism of the above comment ... But something I see a lot in enterprise software development. And I also do realize going outside of scope is risky and doesn't pay in the current management zeitgeist.
- hsavit1 2y ago
  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
- mym1990 2y ago
  Another thing to mention is that if you find a way to do 8 hours of work in 4, almost no company will just let you take the other 4 for yourself, unless you do so quietly, so you have just created more work for yourself by becoming more productive.
  - hollerith 2y ago
    Sure, but if you really did find a way to double your productivity, you can probably find a way to translate that into significantly higher income although probably not right away.
    - nsvd 2y ago
      Realistically, whoever manages you will take credit for the additional productivity and leverage it to get more money for themselves.
    - mym1990 2y ago
      This is probably true, but if we are talking about climbing the corporate ladder here...that is primarily done through peacocking to management and networking well enough to get to the next rung, not through being very productive. If you are a 10x employee, why would a company want to elevate you out of that and into management? But if you're going a different, more self-starter focused path, income opportunities should be increased, yes.
casper14 2y ago
Ive had the luck of recently having effort rewarded with fair raises. But can see how most companies won't do that
johanneskanybal 2y ago
I haven't had the pleasure in 20 years to work with an architect that added much of value, corporate structure and putting people in boxes is such a strange thing to me in software, if you work with senior people they should be able to drive and decide most anything with maybe a thin layer of general direction on top.
BurningFrog 2y ago
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 :)
- arresin 2y ago
  Isn’t after too late though?
  - BurningFrog 2y ago
    It's really hard to design code before it exists! Once it's working, you know enormously more than when you started, and all you have to do is refactor the mediocre design you happened to build into something better, without breaking the functionality. With good test suites and solid refactoring skills, that is actually both very doable and often a lot of fun!
    - reverius42 2y ago
      Wish I could upvote more. Similarly, I always like to say you should plan to write (at least) two versions/iterations of everything. The first one bottom up, to discover what problem you're solving, and the second top down, once you know the problem.
      - qohen 2y ago
        Or, as Fred Brooks wrote in "The Mythical Man Month" (1976): "plan to throw one away; you will, anyhow."[0] [0] https://en.wikiquote.org/wiki/Fred_Brooks https://en.wikiquote.org/wiki/Fred_Brooks [1] https://wiki.c2.com/?PlanToThrowOneAway https://wiki.c2.com/?PlanToThrowOneAway
      - arresin 2y ago
        That’s great if you have the time for it but a bit impractical to write, architect, then refactor.

deleted 2y ago

[deleted]

badgersnake 2y ago

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’m hardly ever in the inner loop.

dijksterhuis 2y ago
> As a staff engineer with team lead responsibilities In my experience, lead ==> doing stuff to keep everyone else in "flow" or "not going off-piste". Sounds like you're doing a decent job of it :+1:
OJFord 2y ago
> 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 that is the case where you work, are you aware of any sort of name for that or keyword? Hard sort of thing to search for otherwise.
- ipsi 2y ago
  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.
- 2y ago

dijksterhuis 2y ago

This really resonates and tracks with my experience. Really like the vector sum concept, as most metrics for productivity tend to be pretty naff (not good). Some of the issue, in my own admittedly limited experience, is that some "important" folks often want the flashy ideas; they want someone to tell them there's a quick fix or a framework to solve the problem in 3x workshops over two weeks. It's unfortunately human nature to want the easiest solution. edit -- plus i think a lot comes down to fear (no control), which is also a thing. Managers also like metrics. It makes their end of month presentations look good. Which is important otherwise the team gets looked down on compared to all the other managers with amazing metrics. But, I could totally see something like this working well at smaller companies where stuff like that isn't a thing.

jauntywundrkind 2y ago

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 discovering and improving the system as you go. DIYers have such amazing enrichment loops, making systems work better for themselves all the time. Not just the much vaunted fast delivery now, but the ability to keep iterating & expanding & delivering without your constructs starting to clash & thrash. I love love Fogus's 100:10:1, on having many tangible places outlined where one might do something. Still dedicating yourself to something, but also giving yourself permission to hop around. Follow what feels good. https://blog.fogus.me/2015/11/04/the-100101-method-my-approach-to-open-source/ https://blog.fogus.me/2015/11/04/the-100101-method-my-approa... [Ed: s/yolk/yoke/, thanks for the fix folks!]

elevatedastalt 2y ago
yoke*
ozim 2y ago
That is why I promote FaF - fix anything Friday and try to fight off sprint load inflation, where it would be expected from team to do more and more. Then also promote “dev alignment” where devs come together to discuss architecture improvements or pick approaches.
- cwalv 2y ago
  IMO it should be 'fix anything when you feel like it.' "Sprints" have given agile a bad name (to the extent it has a bad name, as in gp's complaint). The point is to optimize for changes, as they're inevitable, by: 1. Keep the code in a 'clean' (testable, free from cruft, etc) state continuously 2. Release continuously 3. Embrace YAGNI If short, regular sprints help with those things, use them. But sometimes they don't
  - 2y ago

dang 2y ago

Discussed at the time: A dev's thoughts on developer productivity - https://news.ycombinator.com/item?id=31414681 https://news.ycombinator.com/item?id=31414681 - May 2022 (88 comments)

m0llusk 2y ago

That is great, but can you make the BUY button bigger?

golly_ned 2y ago

This from Beyang Liu, Sourcegraph CTO, who plays up his stint as a Google intern to represent himself as a "former google engineer", and wrote this blog referencing Google 55x in a short article to associate sourcegraph with Google-quality tooling: https://sourcegraph.com/blog/ex-googler-guide-dev-tools https://sourcegraph.com/blog/ex-googler-guide-dev-tools

itsdrewmiller 2y ago
... is an intern not a former engineer? I assume it was software engineering internship?
- mydogcanpurr 2y ago
  No
- reverius42 2y ago
  Definitely gives a different impression if you say "former Google engineer" vs. "former Google intern".
- knighthack 2y ago
  I am not sure how you would conflate an engineer with an intern. That's like conflating a practising doctor with a medical student.

matt3210 2y ago

Hand written stuff (written or made to look written) needs to be in a more readable font.

from-nibly 2y ago

Developer productivity is about leveraging developer context into more stuff while making the developer do fewer things. Automate and shift left.

agentultra 2y ago

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.

dualogy 2y ago
> Nothing works better than trust and autonomy. > Communication and trust is key. > We learn. We design. We think. Our output is knowledge, not widgets. That's a manifesto I would sign! But let's not make it into one, because back then the originally-similarly-spirited Agile Manifesto couldn't immunize itself against "adoption" by — management consultants, process engineers, whatever you want to call them =)

itsdrewmiller 2y ago

Did McKinsey just lift the inner/outer loop concept here with no attribution? Does it also predate this article? https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity https://www.mckinsey.com/industries/technology-media-and-tel...