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.
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.
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.
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.
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.
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.
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. At the "higher levels", instead of treating functions and libraries as black boxes, try understanding the algorithms behind them. Even just learning general computer architecture without diving into the lower level details can help in understanding code.
