Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

371–380 of 418 posts

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

#371

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,…

As someone in his forties I wouldn´t be able to pull this off either. It will drain me. With age it takes longer to focus.

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

#372
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've done pair programming as the senior developer often at a previous job. It sucked.

I paired with a young woman fresh out of a boot camp, and at first I was excited to do it because it was nice to have another woman developer. Yet she was just so threatened by me or insecure about her experience, she started gossip about me. Just awful

Another time it was with a mid level middle aged man, he just had a huge ego and felt the need to question single thing I did.

Honestly the best pair programming experience I had was with a "sports bro" type. I always wonder if it was due to fact coaches are a big deal in sports.

I refuse to do pair programming these days if I can avoid it.

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

#373

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 n…

Can you explain like I'm 5? I'll be honest I have no idea what you're even trying to say here.

Precision != Accuracy.

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

#374
post #278

Earlier quoted context omitted.

Have an upvote from me and thank you so much for this comment. This describes perfectly my own state of mind. I've noticed having problems communicating my thoughts about my code in meetings, but simply could not point a finger at the exact reasons. But this describes it perfectly. If I may bother you, could you answer two questions? - Were you officially diagnosed with ADHD. I never went to a doctor, but in the last…

> Were you officially diagnosed with ADHD. I never went to a doctor, but in the last years I had growing assumptions I might have ADHD or Asperger (or both). Diagnosed bipolar 1 recently. But I was diagnosed as ADD as a child thirty years ago. ADHD is a popular addition to the standard Bipolar feature set. > Do you follow certain strategies which made communicating your thoughts and ideas easier and/or better? Not in…

Thank you very much for answering, although it is a very personal thing to ask about.

I guess I should get an official opinion. Nevertheless, diagnosed or not, virtualizing people seems like it could work for me, although it seems to take a significant amount of time for each person to work.

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

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

> That just can't be more productive over the long term, though.

While you can type a lot more by having two people type in parallel, some programming is much heavier on the problem solving aspect of things and those types of problems are sometimes completed more rapidly with two people working together than with two people working separately.

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

#376

Earlier quoted context omitted.

That kind of context switching sounds like it's horrible for just about everyone (including the business).

Honestly, it's sounds kinda insane. Mob programming certainly is a tool with its good use cases, like maybe tracking a bug, onboarding a new team member or making critical changes to core stuff. However, I just can't imagine having three engineers making 100k+ sitted together everyday on a single laptop to write yet another REST api or whatever.

We use "mob programming" once a week for 30 minutes, in a way that you described - a "Sentry Smackdown". In zoom, we find 3 of the most "interesting" sentry errors, split up into 3 break out rooms, each group sees what they can find, then 5 minutes at the end to give our update and next steps.

I love it and it's helped get momentum on things which would typically just sit there. BUT, 30 minutes is definitely my maximum for something like this.... even if we did something minor like make this meeting 1 hour long - I would dread it.

Context: we do have an engineer on-call (on a weekly basis) and they will respond to urgent sentry errors, but the above helps sentry errors with less urgency get moving without being a total buzkill for the on-call engineer to look at ALL of them.

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

#377

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…

> Communicating with neuro-typical people is frustrating, mostly because I try really hard to communicate clearly. > If this comment is a bit rambling, you know why. :) Everyone has struggles with communicating clearly don't they? Do you think it is possible that we put too much emphasis on apparently typical and non-typical way of thinking, with one pathologised? Would ADHD really be noticeable if we were living in…

The whole ADHD as an adaptation theory has been throughly debunked.

Your confusion is very understandable because most people don't know what ADHD is. Some of the symptoms overlap with immaturity, so people who are not qualified to tell the difference will frequently misdiagnose the problem.

If you want to understand ADHD, this video for parents of ADHD children will explain. https://www.youtube.com/watch?v=YSfCdBBqNXY

You don't need to watch the entire 3 hours. The first 10 minutes should be fairly enlightening.

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

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

Aside from one's subjective take on pair programming -- and there are obviously many valid reasons why it doesn't work for some folks -- I'd have to guess that doing it 100% of the time is quite inefficient. Software development presents a wide variety of tasks of varying cognitive difficulty. I tend to believe that pair programming's sweet spot is for tasks of medium to medium-high levels of difficulty.

For the most challenging tasks, say, coming up with an original solution to an unsolved problem, I think it's better to alternate deep focused thinking alone with group brainstorming. But you really need that meditative alone time to gnaw at difficult problems -- for me it tends to be in the shower, or during a walk. That's where you have those awesome "Aha!" moments.

On the other end of the scale, certain mundane/repetitive/trivial tasks really don't warrant pair programming IMHO. You're spending two brains on something that really takes 1/4 of a brain.

The ideal case for pair programming, IMHO, are those tasks where you can visualize the general path forward, but where there are significant challenges wrt implementation such that another pair of eyes can really provide insight. For example, say you have to implement a module, and you have a general idea of what it needs to do, but the overall decomposition and abstractions involved may be inchoate. While I think a fair amount of "implement this new feature" type of stories fall into that category, in my experience that comprises only ~40-60% of the total workload.

The above mostly applies to pair programming with two fairly equivalent/experienced developers. I agree with others who have noted that it's a fantastic training mechanism for new/junior devs. And then, there are various special case scenarios that justify it, as in, you have a problem with X and need to pair with an expert in X to resolve it. IMHO, these are best done ad hoc rather than via a formal process.

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

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

What you describe is just showing someone the ropes, not pair programming at all

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

#380
post #153

Earlier quoted context omitted.

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?

There is a minority of developers who believe that code can and should be mostly self-documenting, and that comments should be avoided because they become outdated and nobody reads them anyway. For example: http://web.archive.org/web/20100415205750/http://blog.weapon...

To clarify: I’m not one of those developers, just wanted to note that they are out there and surface regularly, since the OP was asking.
Post reply on HN