[HN Gopher] A dev's thoughts on developer productivity (2022)
___________________________________________________________________
A dev's thoughts on developer productivity (2022)
Author : hogu
Score : 53 points
Date : 2024-06-27 20:16 UTC (2 hours ago)
(HTM) web link (sourcegraph.com)
(TXT) w3m dump (sourcegraph.com)
| mym1990 wrote:
| 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 wrote:
| > 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 wrote:
| Over-extending yourself can lead to burnout. Pacing yourself
| and not becoming a problem is good for both the employer and
| employee.
| tobestobestobes wrote:
| 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.
| casper14 wrote:
| Ive had the luck of recently having effort rewarded with fair
| raises. But can see how most companies won't do that
| johanneskanybal wrote:
| 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.
| badgersnake wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| dijksterhuis wrote:
| 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 wrote:
| 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-approa...
|
| [Ed: s/yolk/yoke/, thanks for the fix folks!]
| elevatedastalt wrote:
| yoke*
| ozim wrote:
| 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.
| chrisweekly wrote:
| 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.
| dang wrote:
| Discussed at the time:
|
| _A dev 's thoughts on developer productivity_ -
| https://news.ycombinator.com/item?id=31414681 - May 2022 (88
| comments)
| m0llusk wrote:
| That is great, but can you make the BUY button bigger?
| golly_ned wrote:
| 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
| matt3210 wrote:
| Hand written stuff (written or made to look written) needs to be
| in a more readable font.
___________________________________________________________________
(page generated 2024-06-27 23:00 UTC)