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

31–40 of 55 posts

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

#31

Post by arresin »

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

Isn’t after too late though?

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

#32

Post by BurningFrog »

arresin wrote: post #31
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 :)

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!

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

#33

Post by cwalv »

ozim wrote: post #17
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…

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.

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

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

#34

Post by itsdrewmiller »

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?

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

#36

Post by dualogy »

agentultra wrote: post #28

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 do…

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

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

#37

Post by mydogcanpurr »

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?

No

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

#38

Post by ozim »

cwalv wrote: post #33
ozim wrote: post #17

Earlier quoted context omitted.

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.

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…

Problem is you want to have changes going through process. It has to go through other devs, it has to go through QA, if its user affecting it has to go through business. Yeah like we have linters and auto formatting so no one is arguing on that in my team. We don’t have superficial fix anything, people fix stuff that can affect users but as they work with system they notice improvements.

Having that arbitrary deadline of a sprint helps to synchronize people. Because there will always be that one change that is released but not touched by QA or we need some business analyst to review feature on test server to make sure we did right thing.

Keeping code in testable state and somewhat clean state is easy like I mentioned linters, code formatting automatically. Keeping system changes as in frontend/ backend / third party services aligned is not because it is not something you can just write in one place in code.

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

#39

Post by reverius42 »

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!

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.

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

#40

Post by reverius42 »

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?

Definitely gives a different impression if you say "former Google engineer" vs. "former Google intern".
Post reply on HN