> “Kids are not stupid. They are among the sharpest,
> cleverest, most eagle-eyed creatures on God’s Earth, and
> very little escapes their notice.”
i wonder if this is because their lizard brain hasn't yet been trained to filter what's important vs what isn't.
i find myself constantly questioning little details in my codebase like, "why do we thread a request all the way through the business logic" and i think the reason i catch these things, is because my brain hasn't become complacent with this style through 15 years of solving low level problems in C. all sorts of things jump out at me as accidental complexity that the most senior guys don't even notice. i think it's because it didn't used to be important, or maybe its not important to them because they wrote it over years and are already familiar, but it sure is important when you're trying to scale your team and they're facing a brick wall of code needing to be understood for every single little defect.
this complacency is why big codebases get so noisy that you can't see the nuances of requirements in a code review. it's not possible to ask high level questions like < http://www.dustingetz.com/how-to-read-code > without aggressively abstracting away all non-essential complexity. breaking experienced people out of this complacent tolerance for accidental complexity, as we tackle higher and higher complexity, is a really hard problem.
I've also seen youngsters thrash around making a hash of a problem simply because they don't understand the tools available, or they don't have a sense of which problems are worth solving and which aren't, or they don't have a proper sense yet of their own limitations in the face of complexity, or they prematurely abstraculate all over a code base.
Convincing them that this shit is harder than it looks is a really hard problem.
As someone who was (fairly recently) once there, this is definitely true. I think I'm pretty smart but if I knew then what I know now about potential resources and methods, I would have done much better and wasted much less time and energy.
There's the matter of the veteran having more problems to solve than the novice, so they tend to dismiss different things as "unimportant", for better or for worse.
In front of the exact same code, the veteran will bring forward issues such as deliverability on schedule, integration, letting the end-user start the program at 4pm and still be on time to grab the kids at school, the amount of paperwork and convincing that needs to be done so that the people at marketing can understand the new tech well enough to actually sell it to a customer or so that the people at IT can properly install and maintain it on a production environment without calling him every other night.
The novice will say: "why is there a break in the pattern here?", "this code fails when x is negative", "this monster piece of java code looks like what I saw someone solve with a one-liner in python last week".
Putting them both in front of a screen from time to time might either get you the best of both worlds, or hours of painful & pointless arguments.
On a similar note, I remember reading somewhere that performing magic in front of children is harder than it is for adults.
Our adult brains have built up a large repertoire of pattern recognition algos that help us skip steps, lead ourselves to conclusions, ultimately interpret our world better and faster. Children see the world on a more visceral level because they don't have that pattern recognition in place yet, so they have to rely more on direct sensory feedback.
Man, I've lost count of how many arrows I've fat fingered (in both directions) on my Android phone. I really wish HN would add the ability to change your vote afterwards.
i find myself constantly questioning little details in my codebase like, "why do we thread a request all the way through the business logic" and i think the reason i catch these things, is because my brain hasn't become complacent with this style through 15 years of solving low level problems in C. all sorts of things jump out at me as accidental complexity that the most senior guys don't even notice. i think it's because it didn't used to be important, or maybe its not important to them because they wrote it over years and are already familiar, but it sure is important when you're trying to scale your team and they're facing a brick wall of code needing to be understood for every single little defect.
this complacency is why big codebases get so noisy that you can't see the nuances of requirements in a code review. it's not possible to ask high level questions like < http://www.dustingetz.com/how-to-read-code > without aggressively abstracting away all non-essential complexity. breaking experienced people out of this complacent tolerance for accidental complexity, as we tackle higher and higher complexity, is a really hard problem.