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

241–250 of 418 posts

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

#241

Post by replyifuagree »

toomanydoubts wrote: post #111
switchbak wrote: post #107

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.

Compare that to 3 engineers struggling through solving problems in isolation because they lack information that is in each other's head.

Culturally traditional management is biased to create the 3 struggling engineers scenario because most management strongly believes that people working on many tasks in parallel is peak efficiency. You see this manifest in places that run the Jira + PR feature mill. Staff that complete lots of jiras and have lots of green dots PRs in their GitHub profile are considered "peak performers"

The fortune 500 is littered with companies full of this anti-pattern. Less so each year though, because if amazing execution on digital transformation matters to the business, to the extent those 3 struggling engineers execute poorly, the competition slowly eats the incumbent's market share.

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

#242

Post by dboreham »

zozbot234 wrote: post #36
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…

True expertise on a large, complex code base does not just take a few months; competence is best modeled as growing over long timespans, not as something that quickly reaches an "expert"-level ceiling. This is all the more true when-- as is often the case-- the codebase is a complicated legacy thing, full of accumulated "technical debt" and unneeded complexity of all sorts. This is not to say that 100% pair programmi…

Someone with much more experience than me once told me it always takes a year. He turned out to be right, at least over the past 25 years.

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

#245

Post by Clubber »

fragmede wrote: post #45
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…

Therein lies the problem. How much is an avoided bug really worth? A > where really a >= is needed is theoretically going to get caught with pair programming, but how do you make that a metric you can track when we still don't have any way of measuring developer productivity. We never got past the fact that measuring lines of code output is dumb, to any other sort of metric. Even if we had such a metric (using magic,…

Not only that, but that same bug can probably be caught cheaper with a good human QA department.

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

#246

Post by kimixa »

ajmurmann wrote: post #219
rhizome wrote: post #199

Earlier quoted context omitted.

what better way to ensure you get CS degreed ppl for positions that legally can't require one than to reproduce the "group project" model as an organizational principle?

CS group projects are biting like pair programming. Most CS group projects I've been on were a game of chicken where everyone would wait for others to do the work. If you don't pull your weight on pair programming it's quickly obvious and you'll get feedback.

At this point I suspect that the "group projects" often done in CS degrees are actually intended to give the student experience in a failed project and learning from their mistakes, and understanding that not every project is a success or failure due to their actions alone.

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

#247

Post by wwweston »

spartanatreyu wrote: post #232
epolanski wrote: post #158

Earlier quoted context omitted.

I don't really buy that. Mathematics is by far the biggest and longest running open source project on this planet and we are absolutely able to traverse it by centuries or millenia. This works across languages and cultures. Mathematics is built on a small set of axioms and everything else is defined on top of it and proved. Your comment makes it sound like there is some magic knowledge linked to arcane symbols, when…

> Mathematics is by far the biggest and longest running open source project on this planet and we are absolutely able to traverse it by centuries or millenia. This works across languages and cultures. This goes against what I understand about mathematics. I've tried to break it into a few sections. Open source: Things in mathematics once defined, tend not to change, even when changing would be beneficial. Open source…

> We ended up going with vector algebra, then learned that quarternions were actually better

Wait, what?

I'm still mostly familiar with assessments like "Quaternions... have been an unmixed evil to those who have touched them in any way" and "quaternions appear to exude an air of nineteenth century decay" (but not actually familiar with quaternions beyond a vague understanding of them as kind of 4d version of complex numbers).

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

#248

Post by Agentlien »

ggregoire wrote: post #203
layer8 wrote: post #153

Earlier quoted context omitted.

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...

I 100% agree that code should be self-documenting. I sometimes create intermediary variables or extract 1-2 lines of code into functions just so that the code can be understood just by reading the names of the variables and functions. But there is also information that you can't just describe into the code. There are the examples I already gave above. Another one could be what I did this afternoon: I had 2 options to…

I've had to do exactly this. I sometimes write some code then realise that anyone less familiar with the details would look at it and see an "obvious improvement" which introduces a subtle bug.

At least once I forgot to add a comment in such a case and luckily I got the question of "why not just..." in the code review.

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

#249

Post by rendall »

Mizza wrote: 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..

I think the tendency for devs not to document what they're doing betrays a lack of empathy for their colleagues. When you write a system, you are now the world expert in that system. Why not write a few words to explain the system? Save an hour or two, each, for everyone who needs to maintain your work? Why not link to the docs of the dependency you choose to use, or the forum posts or white papers that helped form the idea?

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

#250

Post by myvoiceismypass »

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…

20+ year developer here. Worked at a FAANG. This seems fucking awful.
Post reply on HN