Hacker News Reader

Comment by hellohntoday | Hacker News Reader

When writing code you have a mental model of the machine, and the language and libraries. Back in the day those mental models could be close enough to reality that writing bug free code could be a choice. It would take time but you can essentially run the program in your head.

This is an old timer, back when machines and abstractions were simpler.

The post makes sense in that context, but today you can't have a complete mental model of the thing you're coding. It's impossible. So bugs.

Maybe we need to simplify.

View on HN

But we HAVE simplified. I can now type 'fetch this data matching these conditions sorted by this' and be confident about not having any bugs in my code, while underneath there's millions of lines and decades of other people's work and solved bugs being run.

"Back in the day" they would spend weeks devising that system from scratch, hand-writing sorting algorithms, etc.

The mental model of software development is about the problem and domain nowadays, not the low level implementation details. Your job is to solve a business problem, instead of figuring out how to manipulate a CPU and its memory banks to do your bidding.

That's not simplifying, it's the opposite. We've made it easier by adding more complexity.

We have libraries that solve many problems for us.

But those libraries often have parameters, switches, hints, and secret knowledge of the type "do not solve problem X by doing Y because although it seems okay on the surface, the implementational details will increase the complexity from O(N) to O(N^2); use this trick instead".

So we use libraries to solve the problems, but we also need years of experience using those libraries, or we easily create problems we didn't expect. Often there are many alternative libraries for the same task, and the library-specific knowledge becomes obsolete in later version.

You can get that same effect today, just work in the same stack with the same libraries for years and you will learn exactly how everything works. Just need a stack that doesn't do breaking changes that often.

If programming worked like the more manual jobs like plumbing then you'd work 5 years on a stack before they'd call you proficient at it. But nowadays you work 2 years before changing jobs to another stack, and after 5 you are expected to manage people and no longer write code. So the problem is mostly organizational and not technical.

It's not just your tech stack in the narrow sense, your software also can't talk to anything that changes: no browser, no third party service. Systems are rarely that isolated anymore.

Ah, right, I haven't had a regular webdev job. But then that is because your job is to glue together different services rather than implement a complex chunk of code. Most of the jobs I've had were me implementing a lot of low level complex chunks or doing the architecture to make those chunks easy to write, for example when writing the runtime of a ML framework.

So it isn't that the time changed, the old jobs where you code still exists. But we added millions of glue code jobs on top of that, and that changed how people view software development. But it is field specific, even if webdev is the most common you can still work in any of the many other areas where the rules are different.

Edit: And yes, gluing together components is ridiculously hard. It is just hard in a different way, your job then becomes to learn about new things as quickly as possible so you can properly glue them together rather than trying to think about what code to write. That isn't easy at all.

The kind of bugs I write these days are quite different from the ones I made decades ago. My mistakes these days are from high level misunderstandings, rather than low level ones.

You absolutely can have a complete mental model of the thing you're coding. Especially if you properly break it down into pieces (modules, libraries, functions, whatever you want to call them) which can be understood as a unit.

The biggest problem is that many people use libraries as a crutch, without any knowledge of how they work or what they actually do.

define "complete".

Because I bet you fucking money you aren't modeling the actual behavior of any modern x86_64 cpu in your head.

You're not coding any modern x86_64 cpu. Your program might need to work around hardware bugs but those bugs are not things you wrote.

Of course, I also never said x86_64 was a good structure. A bit of reading comprehension might even reveal the implication that simple is better.

Reply on news.ycombinator.com