Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

131–140 of 418 posts

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

#131
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…

When I worked at a place that did 100% pair programming with rotation every day, a new developer could hit the ground flying.

Right -- because they're not the ones actually doing the work of course. Aside form the typing "work".

A team with one expert and pairing is now a team full of experts.

Minus the ones who quit (or never joined) because they just can't get behind the insanity and teeth pulling that is (involuntary) PP.

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

#132

Earlier quoted context omitted.

If you worked at a place that did 100% pair programming, anyone who couldn’t succeed at pair programming would be filtered out. Personally, whether or not I can do pair programming has a lot to do who I’m working with, what I’m doing, and what kind of day I’m having. The same thing goes for test-driven development. I have ADHD and short-term memory issues. This causes me to work by feel on some tasks because I don’t…

I'm at a mandatory-pairing-multiple-times a day place right now and I've made the same observations you are identifying here. Pairing may be good to some degree for knowledge sharing but it works against good architectural design, which requires the kind of holistic thinking you describe, as well as kind of micro-iterative whittling away at the problem that interactive pairing couldn't ever achieve. In addition, the…

I'm also a programmer with ADHD.

IMO, pair programming is most useful for short design discussions and mentoring, like explaining a better way to architect a feature to a junior engineer. I look back on these experiences fondly, and this type of collaboration helped me grow a lot as a developer.

I don't feel like I get the concentration and focus required to "put the whole code implementation in my head" when I'm pairing, so I don't really see how it can be used 100% of the time to build systems efficiently.

And regardless of whether it's a good way to work or not, many engineers just won't want to have someone looking over their shoulder 24/7. That kind of environment would drive me mad. I need to be able to drown out the world and bury my head in the code, and most of us don't work on code the entire day. I like having the freedom to read an article or browse the web for a bit whenever I want to fuck off.

Pair programming and mob programming are definitely not for me, and there's no way I would take a job that requires doing either most of the time.

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

#133
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 work in a team that leans heavily on pair programming and it's a night and day difference for productivity.

Besides the domain and system knowledge sharing, besides exchanging productivity tricks or new ways to solve problems, it is much less distracting. I strongly believe that on any non-trivial task pair programming accomplishes much more business value (more tasks done) and growth than having the two developers working solo.

I don't think it should be the only way to work, definitely not most of the time and it should be encouraged rather than mandated.

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

#134
post #58

Earlier quoted context omitted.

And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.

Writing self documenting code alongside comments makes things so easy on people who have to understand your code later on. I have gotten quite a few comments from former co-workers who have taken over some of the projects I was lead on about how easy it was to read. That brings me a lot of joy, knowing that I made their lives easier and that the output of the trade I invest so much time and energy into is appreciated…

[deleted]

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

#135
post #59

Earlier quoted context omitted.

Can you provide this evidence?

https://tuple.app/pair-programming-guide/scientific-research...

Yeah, we can't expect that company to also post articles that show either less splendid (or negative) tradoffs of PP, now can we?

Meanwhile, some of that research is pretty easy to deflate. From the first article, for example:

Students prefer the 15% overhead

That's right -- they used a survey of student experiences to draw conclusions about what works best for senior developers well into their careers. As the authors themselves put it: "We feel that this is a strong indicator of the satisfaction of pair programming."

I don't see how they can call this "strong" evidence of anything.

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

#136
post #7

I get the impression that there are many professional developers who have never actually seen good documentation at any point in their lives. So many organizations think that having all of the functions listed in on a Javadoc page is somehow the same thing as documentation. And they wonder why it takes a new developer months to become productive..

And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.

I think the argument is about comments like this

    // function to get the recipes
    function getRecipes() { ... }
which are redundant and pollute the codebase.

Where have you heard that writing useful comments (e.g. explaining an edge case, explaining a technical workaround, etc) is a bad practice?

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

#137
post #7

I get the impression that there are many professional developers who have never actually seen good documentation at any point in their lives. So many organizations think that having all of the functions listed in on a Javadoc page is somehow the same thing as documentation. And they wonder why it takes a new developer months to become productive..

And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.

Yeah, I don't even know what "self-documenting code" actually means. You don't write README.md, ARCHITECTURE.md, JavaDocs, etc, at all? A new developer is supposed to go through all the codebases and figure out for himself?

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

#138
Wow - is nobody else bothered by all the empty precision? 57.62% Comprehension, 23.96% Navigation...

Even the piechart labeled "True effort required for many large-scale systems" says 7% of "effort" is Integration Test, and 8% in Module testing...

Want to raise my hackles? Give me statements with lots of precision but lacking in documented (not to mention repeatable, reliable, or robust) accuracy.

Convolved on this numeric silliness are several cartoons of smiling faces with vapid captions like "The figuring out time is a decision making time" or "Assessment is the process of understanding a situation around a system enough to make a decision".

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

#139

Earlier quoted context omitted.

And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.

The downside is those two lines of comments might be outdated and no longer match the code they purport to document, which can mislead you into believing something incorrect about how the code functions. I've seen that happen a lot.

I'm more than half convinced that the comments shouldn't be in the code itself but attached as metadata to the commit that introduced the code in question, with the further implication that every commit should be focused around a single idea that lends itself to a single coherent narrative.

The big drawback (right now?) is that diffs are computed on a line basis rather than a semantic token basis, so a bug fix for a comparison operator obfuscates the raison d'être of a whole conditional.

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

#140

You mean it's not like TV, where the code flows out of my fingertips for many lines and then magic happens?

No, it's exactly like that for me. Personally, I code everything in vertical lines of green hex on a black background.

You can't imagine how difficult that is to read when you check your code into github like that.
Post reply on HN