There was that interview with Peter Norvig - https://www.youtube.com/watch?v=_VPxEcT_Adc - I believe there he said something roughly like "before programming was about composing algorithms, structures etc. - and engineers used ideas from SICP - now it's about composing 3rd-party libraries and solutions - and engineers don't read manuals, don't worry about how systems work internally etc." Pardon if I stretched the meaning too much.
I think this more modern approach has some important pitfalls which we're uncovering now and getting hurt by them.
ah, yes and no. You really can't know the internal workings of everything, it's not practical anymore.
in other words: you can stand up a web site in less than an hour that will handle enormous loads across the globe, but not if you pause to read all the library code that goes into it.
fortunately, humans are pretty good a having faith in things
As a self taught person who likes to dive deep, I’m starting to realize why I fall behind some dude that watched some YouTube videos, did leetcode and got a job somewhere.
I follow a tutorial and if I’m not understanding how the guy got to knowing that the property we should use in that scenario was X, I think I’m not understanding anything and that I won’t be able to build anything, so
I halt trying to figure out, but I’m so inexperienced that I can’t understand the docs anyway.
What I should be doing is putting that code in my notes and moving on having faith in that code.
I was thinking of opening an Ask HN about “how much of your code do you actually fully understand vs how much is just copied from somewhere “
> how much of your code do you actually fully understand vs how much is just copied from somewhere?
100% is fully understood. Every single line. A very small percentage is copied from somewhere (usually adapted in some way), but even then: I understand every single line. And I expect the same of everyone on my team. If I'm doing a code review and someone says "I don't know; I found this code online" it does not go over well. I might have them delete all the pasted code and re-write it with me. If they keep pasting in code they don't understand, I may remove them from my projects.
I'm obviously a lot less strict about understanding libraries we import (although it's still important to develop a strong understanding of what they do, and their limitations, over time). The main difference is that someone else is supporting that code, while we have to support code that we pasted from "somewhere online".
Well as I said I don’t have enterprise experience but from what I see, all the stuff that is not 100% creativity of a new process seems to be tying libraries together.
I’m learning spring because my company is Java heavy and I’m hoping to do a lateral move there. The whole thing is an arbitrary rule set that the library writers agreed upon. Yes there are many concepts of OOP involved but I watch tutorials and the guy says “you need to write auth.userDetailsService and I can only think “yeah, great but how did you get to that conclusion? Where is the hidden recipe book I’m not seeing? How was I supposed to figure that out if I wasn’t following this tutorial?”
So "your code" only means the stuff you typed in personally? None of the libraries you use, the operating system facilities, the runtimes or compilers, none of that is "yours"? So when it breaks or does something you don't understand, then what? File a bug report, call your work "blocked", and go home for the day?
Yes, "my code" means the code I am responsible for, which includes the rare instances where I copy and paste from the internet. What does "your code" mean to you, if not that?
Correct, the libraries and compilers I use are not "my code". If there is a bug in some library method, I simply don't call that method and do something else instead. This may sometimes mean throwing the library away. Sometimes I will submit a bug report, if the process isn't awful (but it usually is).
I guess I don't understand why any of this is surprising to you?
To be honest, you’re doing the right thing: you should stop and try to figure out where things come from, why they’re there, and what they’re doing. Usually, if you’ve got “magic coupling” from a framework, that’s the part that’s going to bite you or it’ll be where you need to dig in for some critical piece of functionality. It’s not unusual for reflection-, plugin-, or attribute-heavy code (and I’ve abused all those systems heavily in the past, often at the same time) to break in weird and unexpected ways, especially in tandem with other frameworks. Sure, cut-and-paste devs look like they get there faster, but they won’t be able to diagnose and debug regressions, because their knowledge is just another cargo cult.
All the answers I’m getting are actually confirming my theory.
For vanilla code I get it. Vanilla Java I can totally understand where things came from and why. It’s the libraries that get me. How am I supposed to know that the library expects X? Is a very common question I have.
I understand it at the end but that’s because someone’s given me the answer. But I couldn’t derive that by deduction if I wanted to because I didn’t even know that was a thing.
And all the guys giving the tutorials seem to be running off their memory but they don’t tell you how they figured it out
There is "From NAND to Tetris". There are not-too-few people with knowledge "from quantum mechanics to UI". At some point you get accustomed to actually know everything :) and you're annoyed with details which are excessive. The non-essential ("incidental") complexity.
You can probably make website faster if you learn 3rd party tools for that... but then you won't be in the position of Paul Graham in Viaweb, where a small team run circles around competition, being that much more productive. I suspect Apple's success is largely because Woz knew ins and outs of the system.
Your important here word is "anymore". Maybe we're at the wave of complexity which will wane. I don't actually think it will last.
I think this more modern approach has some important pitfalls which we're uncovering now and getting hurt by them.