[keyle]

They're a dying breed. We're forgetting how to look under the hood and understand "why something works".

Case in point, I'm slowly being replaced by Salesforce muppets for all my projects at work. They're little code monkeys with amazon ebook type knowledge, projects cost 20x more and I look like the mad scientist for speaking the truth. The products are worse in every possible metrics, I'm not crazy. The politics at play is the reason why I'm losing ground, not logic.

Cabinet designers are being replaced by Ikea flat pack artists in the software world. All we can do is stand by and watch.

And in regards to this blog, when Medium eventually go, that knowledge will go too. Blogs have died, personal websites as well, and their ability to be found in Google is almost non-existent.

Sorry I don't have anything more positive to add, except maybe that they're still there, slowly being alienated by the modern tech world!

[mcv]

> We're forgetting how to look under the hood and understand "why something works".

Partly because that's often not what we're supposed to do; the stuff under the hood "just works" and we're meant to use it to write features, not worry about optimising the stuff that happens under the hood.

And partly it's because the stuff under the hood is increasingly weird and bizarre. Branch prediction is weird, and I still don't understand why that extra print statement changes the branch prediction. Why does it predict `v > maxV` is true when the alternative is to print something, but it doesn't predict that when the alternative is to do nothing?

Is it because printing is expensive, and therefore the branch predictor is going to strongly prefer avoiding that? It's weird that we'd basically have to deceive our code into compiling into a more performant form.

I don't want to have to second guess the compiler.

[lordlimecat]

In my world "just works" means "we blew away all of the security controls and best practice to get this thing hobbling across the finish line."

I see COTS products using ldap memberof queries without LDAP_MATCHING_RULE_IN_CHAIN and stating definitively in their documentation that nested groups are bad (despite decades of best practice).

I see product documentation recommending authenticating against LDAP instead of kerberos, despite the underlying libraries having full kerberos support.

I see sslverify: no, and flags to ignore SSH TOFU warnings, and recommendations to avoid SSH gssapi-keyex (WHY?????), and security approached by buying ever more products creating ever more complexity.

Yes, things "just work" in a horrible, 'youre stuck with your vendors forever' sort of way that results in lengthy outages every 6 months due to mounting, intractable technical debt. But things don't have to be this way, you just need people who are willing to ask "why" or "is that necessary" or "can it be better".

[michaelmior]

> I don't want to have to second guess the compiler.

No one wants to have to second guess the compiler. And it's almost never the compiler, until it is. As a grad student, I remember someone else in our lab spending a long time on a particular issue until he tracked it down to a not yet reported bug in gcc.

99% of the time you can rely on the compiler (or the language runtime, or popular library X), but we also need to be able to identify the rare cases where the lower levels of the stack are broken and how to either fix or work around them.

[chii]

> not worry about optimising the stuff that happens under the hood.

no one is asking you to do this optimization all the time. But you need to know what and how, if you were to be tasked. Then as you get more senior, you will have to also be able to judge whether it is possible, or worth the effort to devote to the optimization, should a scenario arises.

> second guess the compiler.

you aint second guessing it, you're examining the output, and understanding it. Then potentially recognizing when or if the compiler is outputting bad stuff. That's not second guessing.

[pjc50]

> I still don't understand why that extra print statement changes the branch prediction.

The article is under-informing you: they should have shown the full disassembly for both loops, not just the bit in question. I suspect the explanation as given is slightly wrong, but there's no way to disprove it without replicating the setup myself.

[gv83]

> We're forgetting how to look under the hood and understand "why something works".

But under the hood there is a hood. And under that hood there is another hood. And under that hood there is a brand new car you don't know how to open the hood, and so on.

I cannot devote my life to know everything or I won't be able to provide for my family.

[keyle]

If you don't understand "why something works" then you will certainly not be able to answer "why it doesn't work".

Every high level library is an abstraction and abstractions are leaky.

I'm not saying you have to be able to write assembly by hand. I'm saying you should understand why your code runs 10x slower in docker.

[rajamaka]

I'm interested in what's under the hood but after working full time scrubbing the bonnet, my motivation is mostly gone.

[flohofwoe]

You don't need to know every little detail, but having at least a basic understanding how the machinery works (and keeping that knowledge somewhat uptodate), and also being able to verify that the machine actually does what you expect it to do is useful for all programmers, because it lets you write code that works in harmony with the hardware instead of fighting it.

(besides, learning to read a bit of assembly code never hurt anyone)

[_joel]

"It's hoods, all the way down..."

[MrYellowP]

No. Flat out wrong. There is only a small amount of fundamental understanding that needs to be acquired to actually know what your code is actually doing.

Knowing how things work fundamentally is what matters the most, as everything else can be inferred and deduced from that. This is universally true. When you know how something works, you can build up on that.

There's no value for a programmer below how processors work with registers, caches and bus accesses. The most fundamental interface between the programmer and the computer are the registers, caches and interrupts, which make everything else happen.

Understanding how these are being used practically and properly covers a LOT of ground to build up upon.

On the other side you have the people who are fully dependent on compilers to do their job for them. They don't write code for the machine, they write code for the tool.

They don't actually know what they're doing, they have no idea how it works and they believe that the compiler optimizes it all properly anyway, as if it's magic, with no fucking clue what the fuck they're actually doing, while patting themselves on the back for living in dependency.

Why do programmers need garbage collection? Because people have no idea how not to need it. Why are pointers considered bad? Because some assholes decided that telling everyone they're too complex to use was a smart idea instead of teaching them properly, which, of course, it fucking wasn't.

If people would actually know how to do proper memory management, we'd had far less security issues from the get go instead of requiring patches for software that was written in a stupid way, ignorant of memory mapping, pages, etc ... you know, fundamental knowledge and understanding of what's actually happening.

It is considered brilliant to use mmap for faster, more memory efficient file access ... which is absolutely ridiculous, because it exposes how little programmers actually know about the fundamentals!

Using mmap for sharing information between processes and reading and writing files has been my go-to since forever, simply because every other way is literally doing it wrong.

Anyone saying that not every programmer needs to know all of this is missing the point. Of course you don't need to, but the status quo is built upon exactly that line of thinking.

Are you better off being able to, at least moderately, repair your car yourself, or are you better off depending on someone else to do it? The answer is obvious, and the same applies to literally everything.

Less dependency should always be the top priority, because less dependency leads to better understanding and increased freedom ... but we're living in a world that's doing the exact opposite.

Gonna stop writing now, because there's no end to this.

[gv83]

I never had the chance to work at the lower levels you seem to have worked with; in any case I don't disagree in principle with your points (and understand some part of the fundamental understanding you mention), but less dependency leads to wheel reinventing which is completely unsustainable in the long run, specially if you need to maximize the value you bring to the table. It has been like this for every field; how can we call this, industrialization?

[Chris2048]

> Cabinet designers are being replaced by Ikea flat pack artists in the software world

That analogy doesn't really work if the new projects "cost 20x more" upfront, unless you mean long-term associated costs.

[Waterluvian]

It’s what evolution looks like.

My grouchy mother in law also laments that they teach typing in school and not handwriting.

Lamentable? I guess. But it’s not realistic to hope people just learn more every generation.

Despite the tradition of “kids these days with their frameworks and libraries!” complaining, you want to see this evolution.

[dikei]

> They're a dying breed. We're forgetting how to look under the hood and understand "why something works".

Well, layering abstraction is the most effective way to deal with complexity. Our brain is too limited to know everything.

The people, who understand "under the hood", probably won't know much about what's "above the hood", like writing a website or mobile app. Therefore, we need experts on every layers.