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

71–80 of 418 posts

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

#71

Post by darkwater »

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…

As others pointed out, for many of us pair programming is much more demanding on mental resources. The way I tend to work is by doing micro-breaks, checking out other things I would not be comfortable sharing with someone else; if I don't do that and keep hyperfocused, I get drained quicker. Also you can get a couple of programmers that will go down the wrong rabbit hole for much more time because they reinforce their wrong belief mutually. This obviously happens with individuals as well but if you get the wrong mix it can be much worse.

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

#72

Post by zarmin »

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…

As someone with ADHD and memory issues, your comment is what I hope my future looks like. Would you mind expanding on how you're able to work through ADHD symptoms, motivation issues and such?

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

#73

Post by jfk13 »

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…

I've done "pair programming" a few times, with (I think) great effectiveness, but (a) it's been in a very specific context, where we each brought substantial but not-fully-overlapping expertise to the task (not pairing a newcomer and an experienced developer); (b) it was an entirely voluntary thing that the two of us decided to do, not something imposed on us by management; and (c) it was for short "sprints" of no more than a few days, not for extended periods.

If it became a required part of daily work in my company, I don't think I'd be around for long.

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

#74

Post by lvl102 »

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…

I agree with this comment. Not all problems can be solved this way. Sometimes I need to sit down and think without constant interactions. Interactions are great but they have bandwidth limitations for the most part.

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

#75

Post by Tabular-Iceberg »

azemetre wrote: post #60
WindyCityBrew wrote: post #39

Earlier quoted context omitted.

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…

I don't mind pair programming but I don't have the physical/mental capacity to do it for a full work day. I can only imagine how exhausted I'd get after several weeks of it. When I do pair, I only work for 3 or 4 hours that day total.

Pair programming is one of the smartest inventions in this field, but I wouldn't dream of advocating it for this reason.

The best model would be four hours of pair programming and another four of paying those programmers to take a long lunch, a nap and a walk. Those 4 keyboard-hours would probably be as productive as 16 keyboard-hours of the same programmers working independently for a full day, if not more. And unlike full time pair programming it would be sustainable.

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

#76

Post by strken »

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 situational pair programming, but there's no point in forcing another senior developer watch me e.g. set up a toy repo to track down a bug, when we both know what error I'm currently getting and what I'll be doing. You have to be able to pair when you need it and stop pairing when you don't.

For me, pair programming carries the implication that you're always doing it, which seems almost as bad as never doing it.

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

#77

Post by redisman »

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 just don’t like pair programming. It feels like peer micromanagement to me. Thankfully I’ve only had to do it a few times.

If we need to collaborate then let’s hit the whiteboard but please afterwards let’s work in peace on our own computers like civilized humans.

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

#79

Post by ChrisMarshallNY »

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 is one answer.

So is retaining engineers, so that, once they learn the system, are available to maintain/teach it, and more importantly, are invested in doing a good enough job, because they will have to be around to deal with the fallout, if it was not a good enough job.

There's no one answer, but I'd suggest that having an environment that retains engineering talent, and incentivizes good, long-lasting work, could be helpful.

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

#80

Post by bckr »

samspenc wrote: post #20
mooreds wrote: post #5

Haha, so true! I've found that for most systems, there are three great ways to "figure it out". * Start from input. (Browser, API, whatever starts a process.) Map from there. * Start from data storage. (Database, flat files, whatever.) How does state get persisted? * How does the system move into production? If you can make a small change (even adding an innocuous comment) and see it all the way from your machine to…

A couple of things I found helpful along those lines: * Data storage: what does the schema look like? Even if it is not persisted to a relational DB, is it possible to draw out a schema of a data model and all the relationships ("JOINS") * Add logging to code you are trying to debug but are hard to understand and repro bugs for in production. Once you have logs about the full state that reproduces the error, the issu…

> Add logging to code you are trying to debug

This is a great idea and should absolutely be a standard. There's a whole logging level ("DEBUG") devoted to this that I think goes way underused.

Another, related idea is to use a debugger. Using PDB for Python codebases has sped me up A LOT.

Post reply on HN