Live data from Hacker News

Developers spend most of their time figuring the system out

lepiter.io

151–160 of 418 posts

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

#151

Earlier quoted context omitted.

You waste your time managing visual presentation (more so than 1D text). Schematic entry used to be commonplace for FPGA and ASIC development in the 90s. The industry has mostly moved to HDLs for digital logic because it is more productive and you get side benefits like revision control, easier reusability, and tooling independence. Anyone promoting 2D visual development for programming is selling snake oil.

We're not talking about programming here but explaining a concept.

I'd have said those are very, very similar things, if not I fact the same.

Granted, code requires far more details than many conceptual explanations, but it is still one.

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

#152

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…

> There are other benefits, pair programming reduces a whole category of simple bugs/typos to basically 0 No it doesn't, bugs happens since there is much acceptance for bugs, programmers develops just enough awareness of them to get the bug count to maximum acceptable levels. If you take two programmers who both learned to get there on their own and have them oversee each others work, you reduce the bugs temporarily,…

(I know you run out of people in real world teams pretty quickly but) rotating pairs regularly helps with this, with a maximum of two-week pairings to avoid this and other issues.

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

#153

Earlier quoted context omitted.

And then you have the common argument that comments are bad practice. If I can read 2 lines of comments for every 20 lines of code while navigating a large codebase until I find the code I really need to dive into, the productivity gains from that are nothing to scoff at.

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

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

#154
post #116

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.

Does Zoom have a "Mutex" button for obtaining keyboard access?

I lol'd at this... was thinking the same thing. "Who's driving!"

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

#155
post #29

Earlier quoted context omitted.

There's a chasm between "developer who always pair-programs all the time" and "developer who isn't capable of pair-programming".

I need to quiet space to think (or at least thick headphones) to solve hard problems. I can’t understand how some people work without ever getting that. Do pairs agree to shut up until someone gets an idea?

> Do pairs agree to shut up until someone gets an idea?

Hard problems are quite rare, most development is mundane.

When facing hard problems, generally related to non-obvious bugs, there are many ways to solve them, and yes taking time off to think about it separately is absolutely one of them.

This isn

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

#156

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…

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?

Yes. Especially ice chewers. Which one PM thought was hilarious as he worked through a cup of just ice.

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

#157
post #112

Earlier quoted context omitted.

I'm at a mandatory-pairing-multiple-times a day place right now and I've made the same observations you are identifying here. Pairing may be good to some degree for knowledge sharing but it works against good architectural design, which requires the kind of holistic thinking you describe, as well as kind of micro-iterative whittling away at the problem that interactive pairing couldn't ever achieve. In addition, the…

Good design and getting everything right up works right up until the requirements change and the design no longer meets the ask. Unsurprisingly, teams might not even know all the requirements when building something new. Having everything orderly up front is a pipe dream. That said, there are definitely cases where sitting back and thinking through a design is a really good idea. In my experience, it's 1/10th of the…

Good design can handle changing requirements, otherwise it isn't good design. Good design requires a lot of domain expertise and not just being a good programmer since you have to be aware of what kinds of things the system should be able to handle, but it isn't impossible.

By domain expert I mean someone who has worked in a single domain for many years. Lets say you have written healthcare backend software for 10 years, then if they tell you to design a new healthcare software system then you will be able to predict most future requirements the system will have even if they don't spell those out explicitly to you. Sometimes laws changes and you have to redesign stuff, but having to adapt code due to new laws isn't a common occurrence.

Edit: And 10 years in a single domain really isn't a lot of time. In a sane world you would be called an apprentice until you reach that level, that is the only way to make robust products. This is how almost every other field works, but in programming people seem to think that such expertise is impossible, at least at scale.

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

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

See also Bill Thurston's commentary on the nature of mathematical knowledge: "mathematical understanding does not expand in a monotone direction. Our understanding frequently deteriorates as well. There are several obvious mechanisms of decay. The experts in a subject retire and die, or simply move on to other subjects and forget. Mathematics is commonly explained and recorded in symbolic and concrete forms that are…

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 mathematicians are the least interested in symbols and labels, they care about definitions.

As with any field if you get in highly specific topics then obviously you are going to lack enough literature and tradition on these topics and something may get lost, but 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.

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

#159
Regarding pair programming - I'm a self-taught freelancer based in a remote area (not many local devs). How might I bring about the benefits of pair-programming or even mentorship in a remote context? Mentor As A Service? Sounds a little lame to be honest.

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

#160

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? Yes. Especially ice chewers. Which one PM thought was hilarious as he worked through a cup of just ice.

I had a coworker at the same last job I mentioned, that sat next to me in our open office, and used to crack and eat eggs at his desk, among 4 other meals that he'd decide not to bring to the kitchen. I literally couldn't find a pair of earmuffs or headphones that could help me get back in the zone after hearing that.
Post reply on HN