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

351–360 of 418 posts

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

#351

Post by phil294 »

Stratoscope wrote: post #207
toomanydoubts wrote: post #100

Earlier quoted context omitted.

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

Wow. I recommend everyone read through that page. Some may love it. Obviously the bosses at SOCi do. For me it is a dystopian nightmare. To summarize: there are three roles, Typist, Navigator, and Support. The Typist is not allowed to think . They are explicitly described as a "smart input device". For the most part, only the Navigator is allowed to think. They tell the Typist exactly what to type, and the Typist mus…

Thank you for your insights! While the idea is interesting, the images on top of the SOCi article support your sceptism: Three programmers gathered around a tiny laptop screen is awful. You can always increase the font size though - I regularly work with a fairly large font as it is not as straining for long periods, but how do you persuade your coworkers to that? It takes quite some getting used to the diminished screen space.

That said, I would never want to join a company that has phrases like

> The mob disbands, either to sleep, or to their individual work

and

> [...] full 8 hours of programming [...] minimum expectations [...] additional time is expected to be put in

in what is basically their job description. Also, six to eight hours of non-stop webcam is horrible! https://news.ycombinator.com/item?id=24718640

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

#352

Post by truculent »

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's a trade-off between efficiency and robustness.

It may not be as efficient, but it can be more productive in the long-term if you're better insulated from staff turnover, for example. Making engineers more replacable could also contribute towards lower wages (more able to hire beginners and make them competent, reduce leverage of existing staff).

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

#353

Post by kayodelycaon »

pengaru wrote: post #253
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…

I don't think one requires ADHD and/or short-term memory issues to struggle with serializing their internal state verbally without disrupting said internal state when it's sufficiently broad and deep in complexity. This is literally the problem with interruptions and open-office floor plans for knowledge workers. There's no effing way we're all ADHD-addled goldfish. Decades ago my senior cube-mate liked to tell non-e…

You’re correct. People with ADHD have many of the same problems as non-ADHD people have. An open office is difficult for anyone to concentrate in.

The difference is the matter of degree.

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

#354

Post by t0suj4 »

sachin_m wrote: post #274

The idea that “developers spend most of their time in reading and understanding the code” resonated with me, but the tool (gtoolkit) that this article is suggesting is too complex for me to understand and make it work. The tutorials or demos are about an hour long. I would appreciate if any tool can get me started in just 2-3 minutes (max) of hand holding. I don’t want to spend hours in a tool just to get started and…

Unfortunately, gtoolkit has pretty steep learning curve. And it's not different from Pharo gtoolkit is built on.

I think there is a clash of concepts. It took me a lot of time getting used to the smalltalk workflow of experimenting in the playground and jumping into the editor to change things.

It is very different from recompiling and restarting or from running a repl.

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

#355

Post by ethanwillis »

imtringued wrote: post #335
doliveira wrote: post #137

Earlier quoted context omitted.

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?

Self documenting code means carefully choosing names and structuring the code in a way that there is reduced ambiguity and maximum clarity instead of compensating for low quality code with additional documentation. If your code is sufficiently clear there will be nothing left to say in the comments, the comments will have to repeat what the code is already telling you which significantly diminishes the value of comme…

Things are in fact taken away. Code as a language doesn't tell you why it exists. It only describes a process, not the purpose of that process.

And unless your programs are formally verified this process that you have codified most likely will not meet the requirements to satisfy the intended purpose.

A typical non-technical "assignment" that's given before someone is fluent is to describe in excruciating detail/list of steps how to make a peanut butter and jelly sandwich. The point of the exercise is to show students that you need to remove all ambiguity. Or at least as much as possibly. What the exercise doesn't show is.. why are we making a list of steps to tell someone how to make a sandwich.

“If you give me six lines written by the hand of the best debugging programmers, I will find something in them which will hang his operating system.”

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

#357

Post by ansible »

Stratoscope wrote: post #207
toomanydoubts wrote: post #100

Earlier quoted context omitted.

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

Wow. I recommend everyone read through that page. Some may love it. Obviously the bosses at SOCi do. For me it is a dystopian nightmare. To summarize: there are three roles, Typist, Navigator, and Support. The Typist is not allowed to think . They are explicitly described as a "smart input device". For the most part, only the Navigator is allowed to think. They tell the Typist exactly what to type, and the Typist mus…

> When working in person, one thing this selects for is people with perfect vision. Elderly programmers need not apply! ... prescription for 20" focus ...

I went the other way. 42in 4K TV placed further back. Big font. Zero eyestrain.

The main trick is that you have to set up the TV in "Game Mode" to turn off input processing, and also turn off stuff like overscan.

Obviously this setup may not work in a office cubicle or other space-constrained space.

Works fine for in-person reviews in the time of Covid, the other person isn't hovering over my shoulder either. They can stay way back and still see what's going on.

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

#358

Post by brailsafe »

smaudet wrote: post #346
brailsafe wrote: post #126

Earlier quoted context omitted.

This almost made me tear up. I've genuinely never thought before this thread that there were companies that did this, and that it's just not a big deal to people with decision making power. I don't do anything for 8 hrs a day, but if I had no choice but to be doing 8 hrs per day of pair programming, I'd really be having some dark thoughts. Not exaggerating, this scares the shit out of me. Thanks for sharing. I actual…

Makes me almost wonder what management is actually good for, besides a high level filtering system... I like continous pair programming, but not because I actually continuously pair - if someone wants to watch me work, or is too green to go it alone quite yet, its fine. But usually we only pair when it makes sense to, i.e. we are at the beginning of something and figuring out what to split up. If management tried to…

Ya, seems reasonable enough. You have control over the gate, either to teach or to work something out. People are allowed to have an opinion on this in general.

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

#359

Post by alanbernstein »

t0suj4 wrote: post #340
Izkata wrote: post #213

Earlier quoted context omitted.

Note that their bad example is comment-every-line style just like GP's example. No-comment self-documenting code is largely a backlash to this style, which is how introductory coding courses teach (taught?) was the right way to do comments. For a lot of programmers who first started in in one of these courses it tended to stick because they were never taught another way.

My algorithm for commenting is simple: If I don't understand what a line of code does, I delete it. If the behavior stays the same then it shouldn't have been there in the first place. If removing the line breaks something I put it back and add a comment explaining why it belongs there.

That seems... Dangerous

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

#360

Post by tluyben2 »

weq wrote: post #273
Stratoscope wrote: post #207

Earlier quoted context omitted.

Wow. I recommend everyone read through that page. Some may love it. Obviously the bosses at SOCi do. For me it is a dystopian nightmare. To summarize: there are three roles, Typist, Navigator, and Support. The Typist is not allowed to think . They are explicitly described as a "smart input device". For the most part, only the Navigator is allowed to think. They tell the Typist exactly what to type, and the Typist mus…

That is literly a description of programming hell for me (20+yrs also here). My fingers are so much better at streaming my thoughts them my mouth which often struggles to keep up.

Yep, same here. And people are also not very good at listening; even if you are focusing only to type, people miss stuff and I have to repeat or explain in another way while I could have typed things 100x myself in that time. I think I’ll give this weirdness a miss.
Post reply on HN