Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

Post reply on HN
Print view View original

141–150 of 418 posts

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

#141

Post by Jensson »

WindyCityBrew wrote: post #39
SomeCallMeTim wrote: post #26

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…

> There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0

No it doesn't, bugs happens since there is much acceptance for bugs, programmers develops just enough awareness of them to get the bug count to maximum acceptable levels. If you take two programmers who both learned to get there on their own and have them oversee each others work, you reduce the bugs temporarily, until they adjust their attentiveness and conscientiousness downwards to account for it and the bugs rise again until they are at barely acceptable levels.

You see temporary improvements like this happen everywhere. Researchers love it because it makes it trivial to publish papers, but these results usually doesn't scale, and even when they do scale the effect is significantly smaller than originally advertised.

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

#142

Post by doliveira »

ggregoire wrote: post #136
FractalHQ wrote: post #14

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.

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?

I find it inconsistent to have it for some public methods and not for others. I guess you could add a (!) depending on the context:

    // function to get the recipes (!)
    function getRecipes()
Or just document what recipes actually mean within the application context.

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

#143

Post by _carbyau_ »

erik_seaberg wrote: post #81
Veuxdo wrote: post #29

Earlier quoted context omitted.

There's a chasm between "developer who always pair-programs all the time" and "developer who isn't capable of pair-programming".

I need to quiet space to think (or at least thick headphones) to solve hard problems. I can’t understand how some people work without ever getting that. Do pairs agree to shut up until someone gets an idea?

I am not sure everyone has the same idea of pair programming. I have never done it but it simply seems like: 2 people solve a single need.

How? "Deploy personal + company resources as appropriate to get the job done together" - however they damn well want to in that framework. It is between them. The pair could:

Use a whiteboard for 5 minutes every 3 hours and go their separate ways otherwise.

Sit together hunched over a single laptop.

Work from two entirely separate locations with collaboration software so they can see each others cursor and typing as they voicechat.

I mean, isn't it all about simply getting along and getting a job done?

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

#144

Post by DenisM »

kayodelycaon wrote: post #55
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…

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…

You don’t really have to fit things into logical registers before you can speak of them. If you stop trying to do that you will find that you can speak your mind directly, which requires a lot less effort. The recipient of your message is also a human mind and while you will lose the handrails of logical clarity you will gain the safety net in abundance of bandwidth and feedback loops.

It’s a trained skill tho.

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

#145

Post by devoutsalsa »

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…

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

I’m sorry, no. That’s not how that works.

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

#146

Post by epolanski »

> I see the flow of constructing custom tools during development, and, ideally, for every single development problem, as the next major leap in software development.

I wish I could transmit this concept in my organization.

1) E2E tests as business requirements living documentation are the best first step any organization/project can make besides their tremendous technical value. At least remove the need from contributors to figure out business from code.

2) Confluence-like services cannot work as technical documentation. There's plenty of tools that allow you to generate docs from code, use them!

We should lessen the friction from abstract to development,and that starts with providing good tools that bridge tge two.

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

#147

Post by creakingstairs »

toomanydoubts wrote: post #100
kayodelycaon wrote: post #55

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…

Thanks for posting this. Yesterday I came across a job position on a company that does 100% mob(!) programming everyday¹. This means every programmer works 6 hours per day on a zoom call with 2 other programmers, rotating roles between typist, navigator and support every ten minutes. I couldn't help but feel my soul being slowly crushed as I read further on their description of the daily activities. Needless to say,…

> 100% mob(!) programming everyday

I've been in a team that does this. I did appreciate the knowledge share from the expert the first month despite the fact it completely drained me. After awhile, I hated the whole thing and dreaded going to work. I get it works for some people, but I know it is not for me.

> on a zoom call

This would make this about 10 times worse. I wouldn't last a week.

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

#148

Post by violiner »

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…

> a new developer could hit the ground flying.

Sounds like a plane crash. :)

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

#149

Post by Havoc »

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…

I like that description of pair programming - articulates the benefit clearly. Makes intuitive sense & haven't seen anyone explain it that clearly before.

> accountants will never understand this

Oh...I take it back then.

I'm an accountant. Apparently I didn't understand this, so I must have been mistaken in my above assessment.

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

#150

Post by Gigachad »

ggregoire wrote: post #136
FractalHQ wrote: post #14

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.

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?

I have found that I almost always benefit from a comment for each database table / model. The name can be somewhat descriptive but often its generic enough that its hard to tell if it specifically works the way I assume it does.
Post reply on HN