Developers spend most of their time figuring the system out • Hacker News Board

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

#31

Post by watwut » Wed, Mar 30, 2022, 8:49 PM UTC

gleenn wrote: 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 developer was not hitting the ground running. That developer was being carried by someone else in speed lower then that someone else normal speed.

And also, pointy haired bosses and accountant don't mind pair programming all that much. Normal average developers with normal average psychology do mind it, object it, hate it.

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

#32

Post by all2 » Wed, Mar 30, 2022, 8:50 PM UTC

lizardactivist wrote: post #11

Using 3rd party software and libraries: spend hours flicking through documentation pages to find lots and lots of information, but no clarity.

For me, this activity is very often driven by "I need to do X, how do I do that?" It can be as general as "I want to make a web app with X language using Y framework". Often (for Golang and python, for example) there are lots of video tutorials talking about the necessary boilerplate -- so much boilerplate.

It can also be extremely specific "I want to split a ReadOnlySpan on some delimiter (which you can't do, you need to cast to a string and use the Split method there). Fortunately, that was an easy thing to find an answer for.

Sometimes I want something specific that I have no clue how I would even start looking for the answer. I want to build a web app with a modular payment end-point so I can plug/play a large number of providers (ideally, I'd be able to arbitrarily hook in Stripe or the Bitcoin Lightning network or something else entirely). There are a host of problems for me here; I don't understand the problem space, so I have no clue what a "good" solution would look like, I don't even know if generic payment APIs even exist (zero research on my part), let alone in languages I understand (go, python, C#).

I guess my issue is formulating questions appropriately, so that the sum of answers is an answer to my driving question "how do I do X?"

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

#33

Post by zozbot234 » Wed, Mar 30, 2022, 8:51 PM UTC

This sounds intuitively correct. It also leads to the unintuitive implication that paying down technical debt as soon as it arises and keeping systems simple and elegant as much as feasible, and well-documented wrt. inherent complexity, is not just key to software assurance and quality in general, but also to optimizing the use of developer time. Accidental complexity is not really manageable "debt"; it imposes large and growing costs over time.

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

#34

Post by dgb23 » Wed, Mar 30, 2022, 8:53 PM UTC

SomeCallMeTim wrote: post #30

Veuxdo wrote: post #23

Earlier quoted context omitted.

You don't think this depends at all on the particulars of the developer(s)? E.g. their personalities, experience, skill level?

The studies I've seen about pairing show that it's OK for beginners or lower-skill developers, but absolutely less productive for expert/senior developers. So yes, you're correct.

I would say that there is still a benefit of pairing an expert with a novice now and then. Not for productivity but for long term effects. They cannot be _too_ far apart though.

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

#35

Post by pjmlp » Wed, Mar 30, 2022, 8:53 PM UTC

gleenn wrote: 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…

We avoid doing pair programming, because personalities matter, and this circus about driver and co-pilot is yet another "agile" marketing gimmick.

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

#36

Post by zozbot234 » Wed, Mar 30, 2022, 8:55 PM UTC

SomeCallMeTim wrote: post #26

gleenn wrote: 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…

True expertise on a large, complex code base does not just take a few months; competence is best modeled as growing over long timespans, not as something that quickly reaches an "expert"-level ceiling. This is all the more true when-- as is often the case-- the codebase is a complicated legacy thing, full of accumulated "technical debt" and unneeded complexity of all sorts. This is not to say that 100% pair programming is always the answer, but doing it to some extent is likely warranted.

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

#37

Post by irrational » Wed, Mar 30, 2022, 8:57 PM UTC

gleenn wrote: 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…

Pair programming only works when both people have similar mental aptitudes/personalities/types/processing-speeds.

The times I’ve been involved in pair programming it has been a disaster. I need time to sit there and think and process while the other person is getting bored and wants to keep going or they start to talk which ruins my thinking so I have to start over again.

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

#38

Post by atum47 » Wed, Mar 30, 2022, 8:59 PM UTC

Yep, once I spent the whole day reading code to write one single line of code at the end of the day. Since my boss is also a developer he understands. Try to explain that to a manager who doesn't write code thou...

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

#39

Post by WindyCityBrew » Wed, Mar 30, 2022, 8:59 PM UTC

SomeCallMeTim wrote: post #26

gleenn wrote: 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…

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 that fond of it, and 2) most managers do some quick gut check mental math and assume 2 programmers + 1 computer can't be equal to or greater than 2 programmers + 2 computers, that's nonsense, actual evidence be damned.

edit to add: I agree with commenters that pairing is more demanding/draining than solo work. I shudder at the thought of anyone trying to pair for 8hrs straight, or "all day every day 40hrs/wk". Nobody solo programs like that either though.

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

#40

Post by hallway_monitor » Wed, Mar 30, 2022, 8:59 PM UTC

SomeCallMeTim wrote: post #26

gleenn wrote: 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…

You are correct in that having two people both well-versed in both the system and the change they are making is a waste. However, that tends to be rare - the more common situation on a team with no newbies is that you will need to solve new problems with new methods, possible integrating with new systems.

If you have a team of experts, and you want to keep them all experts, it's much more economical to have two people learning the new code as it's being written. Theories about what might or might not be helpful have very little value until tried in the field.