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

251–260 of 418 posts

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

#251

Post by peterburkimsher »

mylons wrote: post #211
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,…

tangential question: I'm 37 and think I have ADHD. My partner thinks I do, and when I read posts like this I deeply identify with them. What should I do? Get a diagnosis? My ignorance thinks the only course after that is drugs which doesn't sound that appealing..

Why would you report yourself as a health & safety risk? You're all good :)

Your partner is worried. So shift the work/life balance to have more life with your partner. Trust the team at work to understand.

Diagnosis from other people does lead to prescription drugs being offered. If someone reading is using chemicals, please pay close attention. Some doctors attempt to prescribe drugs in increasing quantities. That is not the path to sustainable balance. Medications are useful in an ambulance or hospital, they do help in emergencies! But they're not intended to be used routinely for a healthy life.

Peer support is best. Finding humble, open-minded peers can be challenging. The CouchSurfing (now BeWelcome) community is very open-minded and humble. Many church friends are humble. Teaching from the Bible is a reminder of how none of us are perfect, yet God forgives, and shows grace, mercy, and peace.

Some companies try to force concepts like pair programming, mob programming, etc upon their "human resources". It works well for people who like talking & body language, but not for people who prefer reading, typing & listening to music. Personally I prefer reading & typing, and that's why I use Hacker News.

You're not alone, you're welcome here. Interruptions are OK despite the cost of context switching. Diagnosis is not needed, you've already found help. I pray that God will bless you with peace in your personal and professional life, and they'll all catch up to your high-frequency genius ideas soon :)

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

#252

Post by saulrh »

kimixa wrote: post #246
ajmurmann wrote: post #219

Earlier quoted context omitted.

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.

Kind of backfired for me, because only very rarely were professors able to assign projects that were big enough that I couldn't do them entirely by myself, and I was outright incentivized to do so because even working at that speed I could still produce the whole project at A-grade quality when my teammates would have been satisfied with a B or a C.

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

#253

Post by pengaru »

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 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-engineers who walked into our cube asking questions unannounced: "like I tell my wife, we're in here balancing a stack of plates in our heads, and you just walked in here and knocked them all down."

You're right about it being a house of cards, and the industry isn't doing us any favors selecting for people who can chat about it vs. arrange the metaphorical cards high and get the hard things done.

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

#254

Post by bothandeach »

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…

me too

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

#255

Post by sarchertech »

rhizome wrote: post #236
repiret wrote: post #220

Earlier quoted context omitted.

In what situations (and jurisdictions) would an employee be legally prevented from requiring a CS degree?

Most, as far as I'm aware, since it's not required to do the work in almost all cases.

That’s not how that works at all. There’s clear precedent that employers are allowed to require specific degrees.

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

#256

Post by racingmars »

rhizome wrote: post #236
repiret wrote: post #220

Earlier quoted context omitted.

In what situations (and jurisdictions) would an employee be legally prevented from requiring a CS degree?

Most, as far as I'm aware, since it's not required to do the work in almost all cases.

I can only speak for the U.S., but "required to actually do the work" has nothing to do with whether or not I'm legally allowed to set a requirement for a job.

There are protected classes/categories that can't be part of the employment decision, but outside of those, the employer is free to set whatever criteria they want for the position.

If I run a plumbing company, I could say "all of our plumbers must have a computer science degree," and I can't imagine there's any legal reason I couldn't do that. I'd certainly have a recruiting problem, but not a legal problem as far as I'm aware.

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

#258

Post by libraryatnight »

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…

Quick "QQ" Question, Pummeler of Productivity, Destroyer of Deep Thought, Harbinger of Headaches. In more crass circles, "Flow Fucker."

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

#259

Post by hinkley »

croo wrote: post #9

Isn't this the "hard part" of the job we are being paid for?

Parkour is a way to enter a building but if you expect other people to do it too, you’re off your gourd. If you insist on everyone else doing it, you’re a maniac.

Too many maniacs in this industry.

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

#260

Post by bcbrown »

epolanski wrote: post #169
fantod wrote: post #167

Earlier quoted context omitted.

> if everyone forgot all they knew about math today we would be easily able to get back to where we are in a just by reading If your definition of "easily" is the amount of work required to become a mathematician, then sure.

We started from the assertion that if a software project loses all of its devs it will not be maintainable anymore by new hires. Not only this is far from a general truth, we all maintained codebases we knew nothing about I guess, but it applies even less to mathematics, which is a language based on definitions built on few concepts rather than vague and buggy business requirements.

> We started from the assertion that if a software project loses all of its devs it will not be maintainable anymore by new hires.

I recognize that this is due to my imperfect summary/introduction of the paper, but it doesn't make that assertion. I highly recommend reading it; it's not that difficult or technical.

I've maintained systems where I could talk to the original developers, and I've maintained systems where I couldn't. I know there's a difference in outcomes between the two cases, but I wouldn't say the latter is "not maintainable". Certainly buggier and slower to develop against, though.

Post reply on HN