Comment by mirsadm
1 month ago
There's never been a case in my long programming career so far where knowing the low level details has not benefited me. The level of value varies but it is always positive.
When you use LLMs to write all your code you will lose (or never learn) the details. Your decision making will not be as good.
Or you already know all of the details, and you don’t want typing to be the bottleneck to getting things done.
This is true.
However, your ability to write specs and validate requirements before starting to build will increase.
It’s just trading deep hand-on expertise for deep product/spec expertise.
No different than how riding the bus all the time instead of driving results in different skill development (assuming productive time on the bus).
I think there is a big difference. You could and should have both knowledge. This applies to whether you're a lowly programmer or a CEO. Knowing the details will always help you make better decisions.
That’s the credo I’ve lived my life by, but I’ve come to believe it’s not entirely true: knowing the details can lead to ratholes and blurring requirements / solutions / etc. Some of the best execs I’ve met are good precisely because they focus on the business layer, and delegate / rely on others to abstract out the details.
I can’t do that. But I’m coming around to the value in it.
I've seen cases in my career where people knowing the low level things is actually a hindrance.
They start to fight the system, trying to optimise things by hand for an extra 2% of performance while adding 100% of extra maintenance cost because nobody understands their hand-crafted assembler or C code.
There will always be a place for people who do that, but in the modern world in most cases it's cheaper to just throw more money at hardware instead of spending time optimising - if you control the hardware.
If things run on customer's devices, then you need the low level gurus again.
So when you use a compiler to create your assembly you will lose (or never learn) the details.