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

101–110 of 418 posts

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

#101

Post by kache_ »

jollybean wrote: post #6

It's why good abstraction and documentation for it is so powerful - you only need to understand the API and not anything else. We start teaching about software like it's 'algorithms' when that is frankly, almost pedantic. That was never the hard part. Scaling the complexity was always the hard part. Simple, clear code, absent leaky abstractions, enough documentation etc..

The problem with abstractions is that it seems that not making leaky abstractions is difficult for most people (most people making these abstractions don't know about the concept of an abstraction leakage in the first place)

Software engineering is extremely difficult

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

#102

Post by giantg2 »

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 between business and technical processes.

But hey, that's just me. And it seems clear that most businesses do a poor job, or don't care at all, when it comes to documenting their processes. So I guess I'm the odd one.

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

#103

Post by toomanydoubts »

drc500free wrote: post #97
zarmin wrote: post #72

Earlier quoted context omitted.

As someone with ADHD and memory issues, your comment is what I hope my future looks like. Would you mind expanding on how you're able to work through ADHD symptoms, motivation issues and such?

In terms of overall mindset, I've found it helpful to think about my month as a portfolio of days. Some will be hyper productive. Some will be almost nothing. This has helped in two major ways. I've let go of the idea that the hyper productive days are my natural state, and that the 90% of the days that aren't there are some kind of failure. I've also built my career to avoid having daily accountability and prefer we…

Awesome. I haven't optimized my career this way yet but accepting that some days I will code 16 hours straight, and other days I won't even look at my laptop has done wonders for my anxiety caused by seeing everyone with a constant productivity and seeing myself in this daily rollercoaster.

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

#104

Post by pixl97 »

hallway_monitor wrote: post #40
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…

You are correct in that having two people both well-versed in both the system and the change they are making is a waste. However, that tends to be rare - the more common situation on a team with no newbies is that you will need to solve new problems with new methods, possible integrating with new systems. If you have a team of experts, and you want to keep them all experts, it's much more economical to have two peopl…

I'm not seeing anyone mentioning what you should do in the case where the one person that knows the code gets hit by a bus.

Would anyone ever say you only need one copy of the code, because backups are inefficient?

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

#105

Post by ineedasername »

BFLpL0QNek wrote: post #82
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…

You just put in to words that I couldn’t, exactly how I work and think :)

Echoed. I've done very limited task-specific paired programming and it's been okay, and I got enough out of it to see how it may be a good way of operating for some folks, but not as a matter of routine for me. It would be awful. I just don't approach problem solving in a way that lends itself to having to communicate what & why I'm doing something a certain way as I do it. It takes too long to explain. After the fact? Sure, I can explain and document quite clearly, but not while peeling the onion and sometimes boring through a few layers to come out of the current one at a different point. I don't think this makes me better or smarter, just a different method.

I think the GP post (GGP?) about the utility of sharing expertise is a good one, though I think that can be done w/o it being 100% all the time as well. It probably also depends on the nature of the tasks and complexity of the system. There may be jobs that really do optimize better w/ a lot of paired programming, and I'm just not a good candidate for those roles. We all have different niches in which we achieve our best performance.

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

#106

Post by azinman2 »

I almost took a different path for my PhD and made it about capturing the knowledge that went into the creation of software. Can we see what people worked on, what they touched, how it came to be… in conjunction with the things they were also learning/consuming/reading/talking about so that we could bake that into IDEs. Right now we just see text files; the most we have is a git blame but you have to keep pulling the thread. It’s also very hard to traverse across blames in time. I’d rather use past knowledge to both know what’s related to some part, as well as how it came to be to determine where it should go next. I’ve always felt there’s meat on this bone.

The early days of Lighthouse IDE seemed to veer a bit into this by they since diverged.

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

#107

Post by switchbak »

toomanydoubts wrote: post #100
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…

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

That kind of context switching sounds like it's horrible for just about everyone (including the business).

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

#108

Post by Keyframe »

raverbashing wrote: post #52
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…

I agree with the benefits But you also have 2 developers using 100% "of their cpu" during that time, which is really unsustainable for longer periods.

One of threads is reviewing code as well, which would be done later on anyways.. among other benefits. I'm invoking commodore64 days for the second time in a row now - back then, during the war, as kids we didn't have much comouter lying around so few of us gathered around a single one and learned and tinkered with it. It was awesome since everything bounced out loud from multiple brains. XP in general is alright but maybe not all of the time, as with anything.

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

#109

Post by brailsafe »

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…

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 whenever he felt that was cool. "Time for pair programming". Bleh, thankfully I burnt out and got fired.

I've been following a very similar path as you describe in your last paragraph, and I'd be very curious if there are other similarities that differ from how others write code.

By chance, do you struggle with eating sounds in offices to the point where you panic?

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

#110

Post by phendrenad2 »

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…

It's hard to be scientific about this because there's no control group. If we clone your team and forbid them from using pair programming, in 5 years, which team will allow new developers to hit the ground faster? Which will have greater velocity. Which will have better code quality?

Some downsides to pair programming I've noticed:

1) People can tend to jump to the first solution they find, in order to not look slow or stupid. This doesn't allow for time to refactor the solution.

2) It can promote a culture of "spoken-word documentation" where all information about the system is conveyed via word-of-mouth, and nothing is recorded. You can see how this isn't scalable...

3) Not everyone has perfect internet, desk setup, comfortable chair, microphone quality, monitor resolution, etc. and it can lead to one person mumbling and another just going "yup uh-huh yeah"

Post reply on HN