A sysadmin or someone in devops, for example, obviously there's minimal benefit for them to understand the ECDSA protocol, and to an extent you don't even need to know how SSH key exchange works. But being aware of them: the role of the private key and the public key, what purpose they serve and the generic high-level overview of their role in SSH - that is information someone in that position would benefit from.
For a systems/app developer, yeah, you probably don't need to understand the theory behind how GC works in Java/Python/Go or the intricacies of DNS records, but when you start seeing heap size errors, weird pause times, or network connectivity issues, simply being aware of all of those things means that you know where to start looking.
I'm 100% with you - there's a limit, and as with all things, you have to prioritize. But every time I see this discussion come up, there's always this push back: "street skills over book smarts!" And there's always this undercurrent that the book smarts matter but ugh why do people care so much and there's never any talk of a balance: knowing what book smarts you might one day need to supplement those street skills.
People that know what they don't know are far more valuable than those that think they know everything. The first class can educate themselves when necessary to fill a gap. The second class is lost. They'll often spin in ignorance for entirety, never finding a solution to the problem, probably without ever once asking for help to someone nearby that is more knowledgeable.
I enjoy having a pretty big network of people to postulate problems at and get new areas of research when I come against a stuck problem.
I think there are 2 fundamental indications of indication of success in software development/engineering: 1. an eagerness and desire for continued learning. 2. passion for the quality of the product. Sure, there may be other factors, but I think if you don't have these 2, they're probably not going to be a positive net contribution on a project.
UIs can be ugly and still get the job done. If your compiler or interpreter doesn't work, you're hosed. If TCP doesn't work, you're hosed. If your OS can't properly schedule processes... You get it.
The people who make things work are demonstrably more important than those who make things pretty and pleasing to us. I would give up either, but if I had to, the UI can shove off. Computers were changing the world long before we even had UIs.
If they don't work, we're hosed - but they do work. They have worked for decades. So what are you saying all these people are doing presently?
Without the mountain of abstractions they sit upon nothing works.
Because Linux Audio sure is better with a mountain of abstractions, so is Wayland, so are the several unstable competing high level filesystems, and cramming applications in the browser is such a delightful experience to develop and use compared to fast, local, platform-integrated, more simple native applications. Because pulling down 30 dependencies like 'pad string' from github to get a HTTP listener running for a Ruby based IRC chatbot is such an improvement. Because everyone needs Bash on Ubuntu running on translated syscalls on the NT kernel and Microsoft SQL Server running on an OS abstraction layer so SQL Server Operating System provides 'robust memory management, thread scheduling, and IO services' on Linux because what - Linux can't do that already? And Docker definitely isn't just 'installing your application and all dependencies in a folder where the libraries never get patched' and a security nightmare in progress. These things are important, necessary, and without them sending text and taking digital pictures wouldn't be possible.
And hundreds of thousands of password hashes were just leaked because MongoDB installs insecurely by default, and hundreds of thousands of web pages through Cloudflare had memory leak data in them because a compiler layer had a bounds checking error. Problems that were solved ages ago by compiler writers and type system theorists and still haven't made it everywhere in production because $reasons.
Is that what they're doing? Writing scheduling engines on scheduling engines, writing GCs for more and more niche languages? Half-finishing more and more filesystems that can't deliver? Writing more and more enterprise broken-XML parsers? If I had to, that lot can shove off. Leave the rudimentary UI and the CLI and the text based protocols (and TLS).
Do you really think no one is currently working on compilers, thread schedulers, standard libraries, etc? Do you think your javascript runs faster today than it did five years ago solely due to hardware improvements?
I'm not even sure how to interpret the rest of your argument. Your middle paragraph seems to agree with me in spirit (I'm not a fan of hugely abstracted 'magical' systems either, UI or no UI.) That said, if you really think we wrote all of the lower level, technically complex code we'll ever need 20 years ago... I don't even know what to say.
No. Do you really think all the work on compilers, thread schedulers, standard libraries, etc. is forward progress? Is reimplementing list sorting for a standard library for Python and for Lua and for Perl and for Java and for Clojure and for .Net and for Go and for Ruby and for JS and for Rust and for ... really the kind of progress you mean when you say "without this, nothing works"? Is this not sideways movement instead of forwards movement?
Are there really improvements in thread schedulers in the last 10 years, that justify "without this progress, nothing works"?
Do you think your javascript runs faster today than it did five years ago solely due to hardware improvements?
Pages are more bloated, load slower, call more dependencies, have more fluff, have worse UIs. Javascript engine improvements haven't brought me better quality of life, they've turned fast desktop apps into slow web apps. Fast desktop CRUD into slow web CRUD.
That said, if you really think we wrote all of the lower level, technically complex code we'll ever need 20 years ago... I don't even know what to say.
I didn't think that until it came out in my comment, and 20 years is a bit of a stretch, but 10 years ago - ok, why not? What exactly is so much better in low level worlds that nothing modern would work without it? ~10 years ago you could have Java and C# and Python and Perl and Lua runtimes, ZFS storage, Linux or BSD schedulers memory management, Varnish cache, memcached, LLVM/Clang, ACLs, SELinux, Virtualization, IPv6, TLS 1.1, MP3s, DVDs, 3D graphics, Mozilla, and on and on.
When you say "without the last ten years of low level code, nothing works" what exactly doesn't work? Drivers for new hardware. No CUDA? No JS frameworks? No Roslyn? Less capable compilers and JITs, no Go-Lang?
Right right, some things run a bit slower, and others would have to be written in different languages. But what ... can't you do? Actual things you can do now that would be impossible? Go back to a CLI only and there's a lot you can't do. Drop hardware video decoding and you can't usefully play video. Drop all the GC/RAD languages completely and there's a lot of apps you can't economically write at all. Go far enough back and there is no storage with checksumming or storage which can do software RAID or storage with multi-TB support, no independent processes - but this doesn't go that far back, not at all.
Sure there's newer, faster hardware, and there are benefits. Sure things are being worked on, but there's a huge amount of towering tech stacks now abandoned, duplication and triplication of the same effort, and general sideways churn and reinvention of wheels that isn't forward progress.
I guess I'm saying that C -> high level GC'd languages was a hell of a change. Two high level languages -> twenty high level languages isn't. It's more human-hours but less progress. Mainframe TUI programs to localizable high res desktop apps was a hell of a change. Desktop CRUD to Web CRUD isn't. No web server to a web server to PHP and maybe to RoR was a hell of a change. One dynamic web framework to a hundred wasn't.
I agree with this sentiment and what's even more frustrating as a old (and since I'm over 35, rapidly aging) developer I find it incredibly sorry state of affairs that even the Type 1 kind of engineers mentioned in the article have to put in the off work hours in learning the newest buzz word language /framework /rehash of the day, to be able to keep doing what they love doing.
The other thing also is the frustration that those of us who actually love to learn, love to learn more than just technology. One of my friends actually choose to not give into the hype and not trading his time improving as a jazz musician, graphic artist and whatever else takes his fancy for learning the latest tech-du-jour. My own imposter syndrome keeps me from being able to take that kind of a risk. This is sad.
> someone that appreciates aesthetic, design, and people
> [can] create a frontend
> someone who can write a compiler from scratch
I've also found it doesn't matter; no one cares. This combination isn't valued.
The only thing that's valued (per revealed, not stated, preference) is your skill at solving homework problems on a whiteboard with an interviewer breathing down your neck and hoping to prove you're an idiot.
There is no such thing in this day and age as a "best possible" developer for all situations. Going through this list will definitely let you understand the underlying principles and the implementations of the code you write, and the systems its running on - I'm not downplaying the value of learning here. It does frequently feel like its a high horse thing.