Developers spend most of their time figuring the system out • Hacker News Board

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

#281

Post by weq » Thu, Mar 31, 2022, 6:08 AM UTC

coryrc wrote: post #262

briandear wrote: post #198

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 find it far easier to program in an automotive shop (banging, yelling, loud revving, etc) than in an open office next to someone slurping food every twenty seconds. Well, that's unfair, as in the former I had almost no problems getting into flow. I expect it's similar for people who like working in coffee shops.

In the zone, that slurp becomes worse then fingers across a chalkboard. Great way to put subtle bugs in your code.

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

#282

Post by remoquete » Thu, Mar 31, 2022, 6:14 AM UTC

hn_throwaway_99 wrote: post #210

giantg2 wrote: post #102

In my experience, the biggest obstacle in understanding the system is that the underlying business process is not properly documented. A technical system is only as good as the business system it's implementing. Knowing the business process makes it much easier to understand the technical implementation, especially if you're trying to find bugs in the technical system since you can more easily see the mismatch betwee…

I disagree with this (sort of) for a couple of reasons: 1. For one, I think it's hard enough just to keep technical documentation up to date. Keeping separate business process docs up to date with code feels like it would be a collosal task. 2. That said, most software at least starts with some amount of requirements (whether that be a formal spec or a bunch of Jira epics). I have rarely seen any engineer start first…

It’s not a colossal task if you hire technical writers.

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

#283

Post by Kerrick » Thu, Mar 31, 2022, 6:15 AM UTC

sam0x17 wrote: post #56

This seems like a really, really good justification for the Rails Way of having a sane and predictable app file structure and layout where developers who have never seen your code before can jump in on day one and figure things out very quickly. Would love to see more web frameworks adopt this opinionated methodology to save us all some time.

That's one of the things I continue to love about the Ember.js framework.

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

#284

Post by Annatar » Thu, Mar 31, 2022, 6:18 AM UTC

I have empirically determined that the main reason for this problem is the unwillingness to put in the effort to completely automate the work. The most often used argument I get is:

it's not worth the effort to completely automate something that one has to perform maybe only once in six months or once per year.

This argument is patently flawed and wrong, because it assumes that it's only worth automating something if it is done often enough. Scientifically, "often enough" isn't quantifiable, and that argument completely neglects the repeatability aspect: by fully automating, the steps to perform something are codified and quantified.

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

#285

Post by weq » Thu, Mar 31, 2022, 6:23 AM UTC

zarmin wrote: post #113

yonaguska wrote: post #85

Earlier quoted context omitted.

Medication and note taking helped a lot with me. Even better, a good note taking app since my handwriting is garbage, right now I'm using OneNote and I keep it pinned to every desktop separate from my code. Motivation- you need to actually align your tasks with an actual concrete personal goal or sense of accomplishment. And be invested in the work. Lacking that, you'll be dependent on external stressors to get anyth…

Thank you. I do rely on medication and note taking apps (though mine are a bit scattered). One of my issues with motivation is what you mentioned: I really really struggle to get invested. Things that are "work" seem to live in an anti-motivation bucket, regardless of how organically interesting they may be to me outside of a work contest. I'm in my 30s now, and I've been doing this my whole life and it is killing me…

Sounds like you are still searching for meaning in your life. follow your dreams, dont follow others.

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

#286

Post by heurisko » Thu, Mar 31, 2022, 6:25 AM UTC

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…

> 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 a medieval agricultural society?

I'm speaking as part of a generation where boys grew up being medicated for what I saw over-diagnosis of ADHD.

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

#287

Post by weq » Thu, Mar 31, 2022, 6:28 AM UTC

a9h74j wrote: post #130

jfk13 wrote: post #73

Earlier quoted context omitted.

I've done "pair programming" a few times, with (I think) great effectiveness, but (a) it's been in a very specific context, where we each brought substantial but not-fully-overlapping expertise to the task ( not pairing a newcomer and an experienced developer); (b) it was an entirely voluntary thing that the two of us decided to do, not something imposed on us by management; and (c) it was for short "sprints" of no m…

Interesting question then: For what characteristics of problem is pair programming more useful, when such problems arise? Is there a pattern to plan for?

Pair programming for me works best on complex issues I, or others, have already failed at. Usually its a short term endevour (minutes), ive only done (hours) of pairing in extreme circumstances either during PoCs or prod issues.

My opnion is that people need time and practice to aborb. Everyone has there own way. If you are pairing everyday for no other reason then company policy, it sounds like the worse place in the world to work.

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

#288

Post by KronisLV » Thu, Mar 31, 2022, 6:37 AM UTC

drawkbox wrote: post #212

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…

Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way. There is a reason why nearly all good programming languages, standards, platforms and even ga…

> Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way.

This feels pretty relatable and sometimes also extends to code review, when another developer essentially goes: "Hmm, i don't like this for subjective reasons, you should rewrite it to be different." even in situations where doing so would have no tangible benefits and the only thing that ends up happening is the development velocity being ruined.

I think that sort of problem would manifest itself both in pair/mob programming, architecture discussions, sprint planning as well as code review, it's not like you can easily avoid it altogether, unless you avoid the people in question entirely or provide pushback against nitpicking and bikeshedding, which may or may not be viable.

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

#289

Post by pjmlp » Thu, Mar 31, 2022, 6:40 AM UTC

saulrh wrote: post #252

kimixa wrote: post #246

Earlier quoted context omitted.

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.

Same here, I knew I was being exploited, but didn't care.

Those grades and work experience were quite valuable to myself.

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

#290

Post by misja111 » Thu, Mar 31, 2022, 6:42 AM UTC

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 have ADHD but I couldn't work 100% pair programming either. It's true, pair programming does an amazing job when it's about knowledge sharing, but I find it exhausting. For me the optimum would be a few hours pair programming per day on tasks where it's the most beneficial.