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

171–180 of 418 posts

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

#171

Post by Jensson »

fantod wrote: post #167
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…

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

But it is way less work than it took to build the knowledgebase we have today. Imagine if we could give all our math literature to the Romans 2000 years ago in a translated form, do you really think it would have no effect? Calculus was invented just a few hundred years ago, it took humanity millennia to get where we are today.

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

#172

Post by dvtrn »

catmanjan wrote: post #120
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…

Yes, and given its not documented there are bugs in the underling business process which end up getting encoded into the software...

Conway’s law, holding on line 2.

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

#173

Post by kayodelycaon »

Gravityloss wrote: post #119
kayodelycaon wrote: post #70

Earlier quoted context omitted.

Not really. But I’m glad you asked! Google “crazy conspiracy board meme” and you’ll have a good analogy for what’s happening. If I start writing it down, things randomly disappear from board. Which requires me to look at the gaps and fill in the blanks. You can imagine what this looks like from the outside. My dad has interrupted me so many times with “get to the point” and the only response I have is “working on it.…

Yeah, for mind map style note taking I use hierarchical bullet lists. It's the same topology (if there are no cycles) without having to worry about layouts, and you can have both hands on the keyboard. I go up and down a lot and move blocks around.

Yup. I'll break out my eink tablet, write bullet points, and make liberal use of the selection tool. (Text editing requires too many operations.)

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

#174

Post by boringg »

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

I resonate with your comment and the comment before. Every time I've had to pair program it has completely drained me. It's impossible to both do the deep logistic work component in my head and communicate clearly with someone else. It's like too many tasks working at the same time. I've never tried to itemize how my brain works in that regards though.

Thanks for both of your comments. The mob programming sounds like I would be depleted way to fast.

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

#175

Post by convolvatron »

strken wrote: post #76
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…

I like situational pair programming, but there's no point in forcing another senior developer watch me e.g. set up a toy repo to track down a bug, when we both know what error I'm currently getting and what I'll be doing. You have to be able to pair when you need it and stop pairing when you don't. For me, pair programming carries the implication that you're always doing it, which seems almost as bad as never doing i…

exactly. I find it vastly more productive to just be available at the drop of a hat to talk someone through an issue. once it gets to the point where we've decided on next steps, we can work on our own until one of us feels confused or something interesting comes up.

yes - lets talk frequently about the work and what makes sense

no - me watching you type and making off-the-cuff comments to keep myself busy

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

#176

Post by amatecha »

bcbrown wrote: post #4

Relevant to this article is Peter Naur's paper on Programming as Theory building: https://pages.cs.wisc.edu/~remzi/Naur.pdf He argues that the biggest determinant on whether maintainers on a system they did not build will succeed is whether they will have access to the original developers: "The conclusion seems inescapable that at least with certain kinds of large programs, the continued adaptation, modification, and…

Text version of that article: https://gist.github.com/onlurking/fc5c81d18cfce9ff81bc968a7f...

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

#177

Post by sebringj »

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…

That sounds effective but I wouldn't want to work there. I do pair programming but on an as-needed basis. I find it very effective in short focused bursts but I couldn't imagine doing it all day. I would go insane.

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

#178

Post by quickthrower2 »

SomeCallMeTim wrote: post #26
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…

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…

People forget what a creative profession coding is. The assumption that programming is a factory is what is being challenged. Most companies seem to have a factory approach and so you end up with technical debt weighing everything down to the point people just can’t get stuff done and the job becomes more about explaining why you can't do stuff.

To give a more concrete example a pair programming session might avoid putting in foundational code that ends up being a bad design choice and slowing down the team by 1% forever. Maybe at a cost of millions. That 1% will never show up in any OKR or KPI that just basically measures superficial stuff about the status quo (bugs raised per quarter, features delivered on time etc.)

I mean it is like we forget we live in an age where still someone smart coding at their laptop can launch a million dollar business.

If you can figure out a smart “hot take” way of working, like maybe pair programming it is a big competitive advantage.

To the point you probably wont find a job for a company that works that way because they can more than make do with a small team.

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

#179

Post by GnomeSaiyan »

CliffStoll wrote: post #138

Wow - is nobody else bothered by all the empty precision? 57.62% Comprehension, 23.96% Navigation... Even the piechart labeled "True effort required for many large-scale systems" says 7% of "effort" is Integration Test, and 8% in Module testing... Want to raise my hackles? Give me statements with lots of precision but lacking in documented (not to mention repeatable, reliable, or robust) accuracy. Convolved on this n…

Can you explain like I'm 5? I'll be honest I have no idea what you're even trying to say here.

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

#180

Post by sebringj »

I have found that knowing the system is the most important thing over anything else. You end up being less wrong and have fantastic suggestions to the group on the direction and purpose of things or catch those edge cases when something is suggested or comes up that others don't know the consequences of or how it all connects together. This is where true value lies.
Post reply on HN