Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

41–50 of 418 posts

Re: Developers spend most of their time figuring the system out

#42
post #9

Isn't this the "hard part" of the job we are being paid for?

We're being paid to do the work necessary to meet the goals set by management, and to provide useful feedback and guidance about what is/isn't possible, and how long it will take.

If they (management) choose to ignore our guidance, or straddle us with bad tools, it sucks for us, and them, and the company.

Re: Developers spend most of their time figuring the system out

#43
post #19

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying . Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of time…

I naturally prefer to do things on my own but I also find interaction with others satisfying. And I'm glad when it's over :-)

In my current job, everybody is remote and you can't even play foosball with people on your team.

Re: Developers spend most of their time figuring the system out

#44
post #19

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying . Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of time…

In my experience a team with one expert and pairing quickly becomes a team with many so-so members and an expert facing burnout.

Re: Developers spend most of their time figuring the system out

#45

Earlier quoted context omitted.

That just can't be more productive over the long term, though. Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert. Unless you have such incredibl…

There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0, keeps people on task, offers (literally) immediate feedback. Unlike most programming "best practices" or paradigms, there's actual empirical evidence that pair programming is "better". Fewer bugs, easier to read code, shorter review cycles. My guess as to why we don't see more adoption is 1) most developers aren't…

Therein lies the problem. How much is an avoided bug really worth? A > where really a >= is needed is theoretically going to get caught with pair programming, but how do you make that a metric you can track when we still don't have any way of measuring developer productivity. We never got past the fact that measuring lines of code output is dumb, to any other sort of metric. Even if we had such a metric (using magic, perhaps), would programmers actually welcome it?

Re: Developers spend most of their time figuring the system out

#46
post #4

Relevant to this article is Peter Naur's paper on Programming as Theory building: https://pages.cs.wisc.edu/~remzi/Naur.pdf He argues that the biggest determinant on whether maintainers on a system they did not build will succeed is whether they will have access to the original developers: "The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and…

That paper is amazing. Completely changed my view on programming. For those who find it a bit inaccessible (as I did on my first read), I wrote an article about it a while back, explaining it further and giving real-life examples: https://hiringengineersbook.com/post/autonomy/

Nice article, I enjoyed reading it.

Re: Developers spend most of their time figuring the system out

#47
post #19

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying . Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of time…

That just can't be more productive over the long term, though. Lets say, hypothetically, that you can use it to ramp any programmer up to being an expert on the system. Maybe that takes two months? Or even six months? Once you have a team full of experts, you're now spending two programmer hours to do every bit of work that could have been done in one programmer hour by a single expert. Unless you have such incredibl…

Having worked at both a mid-size EdTech company and now in a smallish part of Microsoft, every codebase for public-facing software that I've seen would take at least 1 year to achieve actual expertise in (while guided by an expert!) and would probably take much longer.

Re: Developers spend most of their time figuring the system out

#49
post #19

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying . Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of time…

Pairing is actually great in limited scenarios where one person is an expert and the other needs to ramp up quickly from their knowledge.

But at steady-state, it becomes a drain on efficiency.

In my experience, forced pairing is something that a small percentage of people love but it burns most others out. Every company I've seen try to force full-time or even most-time pairing on people has quickly lost a lot of their good developers. Although on the plus side, they at least have a system in place for quickly ramping up new developers as they join to fill all of the openings.

Re: Developers spend most of their time figuring the system out

#50
post #19

People always struggle or avoid doing pair programming, and people always think it means that the developers' time now costs twice as much, but this is a total lie. When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying . Sitting next to someone who knows the system and can answer your question immediately means you get up to speed millions of time…

It's developers who don't want pair programming, because they're introverted and don't like it.
Post reply on HN