this post was submitted on 02 Mar 2026
126 points (94.4% liked)
Programming
25881 readers
604 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well, like with the Netflix question, you can keep going deeper until you hit the unknown. At some point, the person asking the question doesn't know the questions to ask to get to that next level, though.
Many of those questions aren't particularly useful either. They may be interesting from a philosophical perspective but that's the language of thinking, not the language of doing. I've written code in assembly language. I've looked at the output in binary. I can explain in basic terms what is happening there. Does that help anybody?
I would argue that it doesn't because almost everyone writes code in higher level languages. Even if I can tell you what I know it doesn't provide any practical information for you to use. Similarly, I could explain to you how long division works but the next time you need to divide two numbers you're still going to reach for a calculator instead of a pencil and paper. What then is the point of lamenting the loss of knowledge that no one uses directly? It could be reconstructed from what remains if necessary but since it isn't necessary it doesn't matter.
Really depends on where the bug lives.
Most people write mediocre code. A lot of people right shit code. One reason why a particular application or function runs faster than another is due to the compilation of the high level language into assembly. Understanding how higher level languages translate down into lower level logic helps to reveal points in the code that are inefficient.
Just from a Big-O notation level, knowing when you've moved yourself from an O(n log n) to a O(n^2^) complexity is critical to writing efficiently. Knowing when you're running into caching issues and butting up against processing limits informs how you delegate system resources. This doesn't even have to go all the way to programming, either. A classic problem in old Excel and Notepad was excess text impacting whether you could even open the files properly. Understanding the underlying limits of your system is fundamental to using it properly.
Knowing how to do long division is useful in validating the results of a calculator. People mistype values all the time. And whether they take the result at face value or double-check their work hinges on their ability to intuit whether the result matches their expectations. When I thought I typed 4/5 into a calculator and get back 1.2, I know I made a mistake without having to know the true correct answer.
One of the cruelest tricks in the math exam playbook is to include mistyped solutions into the multiple choice options.
It's not lamenting the loss of knowledge, but the inability to independently validate truth.
Without an underlying understanding of a system, what you have isn't a technology but a religion.