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

41–50 of 55 posts

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

#41

Post by qohen »

reverius42 wrote: post #39
BurningFrog wrote: post #32

Earlier quoted context omitted.

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!

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.

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

[1] https://wiki.c2.com/?PlanToThrowOneAway

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

#42

Post by willtemperley »

BurningFrog wrote: post #30
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 :)

I suspect software architects are useful when building user-hostile experiences like Amazon prime cancellation, aka Iliad flow [1]. Portioning out the work would keep as few people in the know as possible whilst reducing the risk of offending individual developer's morals.

$productivity = amount scammed out of customers - developer cost

I wish I could find the leaked document.

[1] https://www.vox.com/technology/2023/6/21/23768370/cancel-ama...

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

#43

Post by badgersnake »

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…

Where I work some but not all. I chose it because I’m undecided whether my next move will be management or technical.

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

#44

Post by knighthack »

itsdrewmiller wrote: post #34
golly_ned wrote: post #16

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

... is an intern not a former engineer? I assume it was software engineering internship?

I am not sure how you would conflate an engineer with an intern.

That's like conflating a practising doctor with a medical student.

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

#45

Post by katze77 »

BurningFrog wrote: post #32
arresin wrote: post #31

Earlier quoted context omitted.

Isn’t after too late though?

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!

That is actually how Donald Knuth describes it in The Art of Computer Programming. The first program is merely written to understand the problem domain.

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

#46

Post by willtemperley »

willtemperley wrote: post #42
BurningFrog wrote: post #30

Earlier quoted context omitted.

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 :)

I suspect software architects are useful when building user-hostile experiences like Amazon prime cancellation, aka Iliad flow [1]. Portioning out the work would keep as few people in the know as possible whilst reducing the risk of offending individual developer's morals. $productivity = amount scammed out of customers - developer cost I wish I could find the leaked document. [1] https://www.vox.com/technology/2023/…

Downvotes without comment, how brave you are

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

#47

Post by BurningFrog »

katze77 wrote: post #45
BurningFrog wrote: post #32

Earlier quoted context omitted.

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!

That is actually how Donald Knuth describes it in The Art of Computer Programming. The first program is merely written to understand the problem domain.

How have I never heard that?

Knuth continues to retroactively impress me!

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

#48

Post by mym1990 »

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.

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.

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

#49

Post by hollerith »

mym1990 wrote: post #48
necrotic_comp wrote: post #5

Earlier quoted context omitted.

> 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.

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.

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.

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

#50

Post by mym1990 »

BurningFrog wrote: post #30
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 :)

There have been no CTOs at the companies you have been working at? I would think that in small companies the architect duties fall to the CTO. Obviously things vary though...if you have never had an architect, I think you are the architect hehe. No one builds a house by feeling it out one step at a time.
Post reply on HN