This is a good message that generalizes to everything. My big peeve over the last few years is how often in software people want to talk answers before understanding the problem. Both in a "just give me the answer" sense, and in the "this will fix your problems" sense.

And said on the cleanest blog design I've seen in ages.

It's a fine balance.

Software Engineering is a profession that deeply revolves around saving people time.

The tiniest fraction of software engineering involves goals other than "saving humans minutes."

The foundational knowledge of software engineering, mathematics, linking real world problems to discrete mathematical foundations. Projection of subsets, grouping abstractions, logarithmic graphs.

It's valuable, because it saves time.

Almost the entirety of mathematics was discarded to identify that foundational knowledge.

Keep in mind, human life will always involve juggling multiple different worries at once, & compromising.

It's never a "do this, or do that" situation.

Perhaps too clean - there is no hyperlink to the home page!

The fixed width irks me on mobile. Way too much whitespace in some lines.

I actually thought some of that whitespace encouraged a smooth reading flow. In other words, it helped my compensation by _not_ putting to much information in one line.

> My big peeve over the last few years is how often in software people want to talk answers before understanding the problem.

My pet peve is people complaining about that. That you seem to think that's an issue shows how long it's been since the last time you really ventured out of your current comfort zone/domain knowledge.

Trying to "understand" first means that you're just reading things for weeks or months if you barely know anything about a technology, domain and everything around it. That's a time period in which this less experienced person can gradually learn how the system, technology and domain works and they'll eventually graduate to prefer understanding over answers. Do keep in mind that these beginners can't distinguish between irrelevant and meaningful information, so they'd have to go through decades of documentation before they're able to "understand".

Just give them a break and tell them the answer. After a while, (which you'll likely feel to be much too long) they'll grow a bigger knowledge base and will be able to meaningfully understand problems.

Well, I started as an electronic technician, then progressed to EE, then firmware, then software, etc.

At one time, I could tell you what every FET junction on a microprocessor was doing.

Those days are long past, but the basic knowledge helps me to write really robust, harwdware- and server-connected software.

I feel there is critical insight when difficult to understand and the difficult becomes intuitive and from others perspective looks easy.

It's amazing what people were capable of building with web technologies that handled the hard parts for us. Most people don't need to worry about the scalability of their PHP applications since Nginx handled that problem for them.

People don't need to worry about multitasking since the operating system preempts your code.

Or JavaScript event loops for efficient IO. Can write a simple nodejs application and use a JIT compiler.

Ironically, in a Hacker News article clickbait title.

The clickbait title is more precious than its contents.

Foundational knowledge allows you to tie different facts together in your field. This rope vastly, vastly, aids comprehension.

Pushing and pulling on the rope shows cause and effect, brilliantly. Cause and effect, understanding allows you to do make effective things.

"Just read George Pólya's How To Solve It and William Zissiner's On Writing Well."

It all fits together after that.

Zissner wrote great books about the importance of writing.

He might well have.

I don't know the titles of any of them, so I can't comment.

> how the HTTP protocol and Session management work

Anyone have tips on the best source material for learning these?

https://hpbn.co/ is a good resource on protocols.

Problem is which foundation to learn, for software is learning cpu pipelining foundational? machine or assembly, or compiler, or C or C++? and also depending on what you are trying to too.

The rule of thumb I often hear and that makes sense to me is to learn or familiarize "one level lower" than what you currently know. For example, advanced C/C++ programmers would occasionally explain stuff based on assembly. Even just learning general computer architecture without diving into the lower level details can help in understanding code.

I seem to have come of age in that magical moment when it was possible to know everything about the computer is working on - transistors to digital logic to CPUs to all of the software that ran on it. It kinda feels like a superpower.

I agree, learning the foundations is imperative eventually. I don't think there's anything wrong with starting your journey at the ultra abstract level we currently operate at, because, let's be honest, that's where the action is. It's a lot easier to stay engaged when you can implement interesting applications quickly, even when you don't really know what's going on. It's a lot more exciting to launch a binary that produces cool output, even if you rely on several dependencies, than it is to slog through tons of low-level stuff that is difficult to connect up with modern abstractions unless you've already had the experience of using them.

That all said, eventually you need to go deep. I think everyone in software engineering, at some point their career, has that sort of ahah moment where they realize just how high up the tower goes and start to get curious about those lower floors. Even though you still don't really need to dip into the bowels of the machine that often, just grokking what goes on down there does wonders for fleshing out your overall comprehension of the discipline.

This all sort of assumes you learn the craft outside of academia, which is typically very much a bottom-up approach (in all disciplines) and seems to work out fine (though students do complain about having a hard time seeing the relevance of what they're learning!)

You can also work with different people specializing in different levels: low level barebone people caring about the performance, correctness etc, mid level people trying to release feature quickly to lock value, and high level people trying to innovate on how the software should solve problems.

We dont all need, at all time, to care about all levels.

A great point! Teamwork is important. This is also the reason having strong "soft skills" is more important than having strong "hard skills" about 85% of the time.

It is interesting that what the author considers "foundational knowledge" in the context of running a sucessful advertising campaign to be "the HTTP protocol and Session management". I would argue that while this is not completely irrelevant, surely foundational knowledge in this sphere consists of an understanding of human psychology, sales, how to identify your target audience etc. If I were asked to choose between someone with an in depth understanding of the http protocol and someone with an in depth understanding of human behaviour to run an ad campaign I would definitely choose the latter. I would go so far as to argue that if I had to choose between training engineers to understand user psychology, sales and UI/UX, or training advertising people to better understand the technology behind their campaigns that I would get a much greater return from investing in the former.