Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

321–330 of 418 posts

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

#321
post #237

Earlier quoted context omitted.

> By chance, do you struggle with eating sounds in offices to the point where you panic? Not to be rude, but the stereotype of the software developer is fast becoming one of fragility. A low wage worker spending their day working a fryer or a guy at a construction site would be thrilled to have such working conditions to where their biggest problem is someone eating too closely while making $100k+ per year in the air…

I’m going to assume good intent and resist posting a snarky response. Why is it so terrible for anyone to want to work in a specific environment that they find comfortable? Why do you think that the ability to work as a fryer or construction worker is somehow “better”? Why are people who have the capacity to either ignore or tolerate bad working conditions and continue working considered morally superior? As human be…

interesting that you equate “fragility” with the opposite of “morally superior” - “Fragile” seems like a fairly accurate description of the described phenomenon, you are the one who seems to be ascribing moral value on the basis of that description. Why is that? Why should we care if someone else describes us as “fragile”?

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

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

This is probably more a problem of expectations in pair programming than pair programming. It comes the easiest to extroverted people with "standard" thinking patterns that are mappet to language 1:1, I also have to translate thoughts into words which is more of an effort than actual coding. But you don't have to express everything with words, if I can see what you are doing I can just follow that. I can't imagine doing it always, but for onboarding and from time to time its great. Not just for knowledge of the system, but learning how other people flows are completely different, what tools they are using and how their workflow looks like, etc.

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

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

Yeah this is impossible because code that isn't written cannot document itself and then the only option is to have a comment. And sometimes the meaningful thing is exactly what doesn't exist. For example here we're not doing X because of Y.

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

#324

Earlier quoted context omitted.

As someone also with ADHD, I can relate in a lot of these respects. The idea of doing pair programming every fucking day would ruin me. I really don't mind collaborating or discussing with people, because I think that's what our brains are great for, but not in the pair programming sense, and not every day. In my last job, I was very open about this, but my manager seemed to basically brush it off and pull up a chair…

> By chance, do you struggle with eating sounds in offices to the point where you panic? Not to be rude, but the stereotype of the software developer is fast becoming one of fragility. A low wage worker spending their day working a fryer or a guy at a construction site would be thrilled to have such working conditions to where their biggest problem is someone eating too closely while making $100k+ per year in the air…

Software work is fragile, just like all kind of deep work, because you're holding everything in your head. I've worked in fast food and in software. In fast food I was constantly thinking about lots of things all the time, because it's mostly physical work. I can't do that in software, I need my mind to be here to work. That also means that in fast food interruptions weren't a big deal. Everything you work with is physical, it's right here, it won't disappear. Thoughts are not like that, they are fragile, you have to protect them.

Of course I'm happy to work in software rather than in fast food. And I think many people would prefer working a desk job rather than a physical job. But humans get used to things. I remember my time working in fast food, but it's hard to remember exactly how I felt and say "Wow, working in an office is way better" every time I encounter something that I don't like in an office. I also think that just because I have better working conditions now doesn't mean I should stop trying to improve them.

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

#325

Earlier quoted context omitted.

> 100% mob(!) programming everyday I've been in a team that does this. I did appreciate the knowledge share from the expert the first month despite the fact it completely drained me. After awhile, I hated the whole thing and dreaded going to work. I get it works for some people, but I know it is not for me. > on a zoom call This would make this about 10 times worse. I wouldn't last a week.

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?

The worst group project I did in course of my studies didn't have the same level of forced interaction as pair/mob programming. In fact, I'd say it tended to have less than normal work from the office.

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

#326

Earlier quoted context omitted.

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.

In fact, depending on regulations, it can happen that you end up with somewhat junior team member having to sign off on all materials because they are the only one with necessary accredited title...

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

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

No, you won't "get to speed million times faster" by getting answers immediately. You have to learn system before you can ask sufficiently important questions.

I recently learned that some database system, internally, always performs two operations in the specific consecutive order. It was quite critical for my task at hand and no-one on the team was able to answer this precise question about the order, including team leader with deep historic knowledge. I had to read code, I had to prove that this sequence will be exactly as I need in cases that are important for me. And I read and reread the code before that "proof process" even to get the understanding that I can implement my solution if I can guarantee that order somehow.

"All easy problems are already solved", if I may quote fortune program.

The hard problems take time for research. By doing that research yourself, you learn how to do research, you learn code better and, finally, you are not doing research with someone who, well, may not know solution for your problem and may not even have a clue on what may help you with the solution.

The last point means that you are not wasting someone's time and you are not wasting your time too.

You say "A team with one expert and pairing is now a team full of experts" and I cannot agree with that for any problem domain that requires any kind of research.

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

#328

Earlier quoted context omitted.

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

There's a big difference between "free flow of information" between engineers and enforced mob programming. The former often works quite well with just regular unstructured meetings, whether face to face or online.

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

#329

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…

Provigil solves the sleep issue. But I’m a bit younger and I also cannot read dark themes. It’s especially infuriating that half the default font colors appear to be dark shades as well, so it’s dark on dark.

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

#330

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

Seems a bit draconian to force mob programming onto every programmer everyday, but I also find the idea appealing if I was selecting the team & when to do it -- there are definitely teams & topics where I would find this flow productive & helpful! For example, we had a similar arrangement back when we were doing ACM programming competitions.

In similar conditions, like Capture the Flag competitions, we regularly used short-term arrangements that might seem like mob programming, often by just deciding to go to whiteboard and try to figure out the problem and thus implicitly inviting others to join if they have spare cycles.

Wildly different experience compared to mob/pair programming all the time.

Post reply on HN