Are fundamentals important for software engineers?
First of all, just asking this question is equivalent to spitting in the wind.
How can any decent engineer question FUNDAMENTALS? It’s sacred. Oh… well. Apparently, I can and I will.
Fundamentals
First of all, what the heck is fundamentals?
Since I didn’t have a good definition in the back of my pocket, I asked my good friend ChatGPT to enlighten me. Here is what I got
Fundamentals are the basic principles or building blocks that provide a foundation for understanding and solving more complex problems in a given field. In the context of software engineering, fundamentals can refer to a range of concepts and skills, including programming languages and paradigms, data structures and algorithms, software design and architecture, testing and debugging, communication and collaboration, and more.
Got it. I think something like that, with a heavy emphasis on algorithms, data structures, and languages, will be the answer of many high-end software engineers.
And now, let me zero in on two words I put in bold — “Solving problems.”
You know, if you study boxing, the fundamentals will be footwork, stances, punching, defense, etc. The thing that they will need literally for each and every fight.
You can take any other discipline and you will find that fundamentals are directly applicable to the main activity. And when I say directly, I mean that most practitioners need it for most of their activities (not just here or there).
So, my naive expectation is that fundamentals for software engineering should apply to the majority of software engineers and should be directly involved in a lot of their activities. It should help solve problems.
Sort-sort-sort
Raise your hand, who was taught sorting algorithms? Bubble sort, insertion sort, heap sort, and famous quick sort?
Yeap. I think the absolute majority of people who got a CS degree will be familiar with it.
Also, say Hello to Mr. Knuth and his book “The Art of Computer Programming,” Volume 3 (Sorting and Searching).
And now, raise your hand, how many of you had to implement a sorting algorithm from scratch and put it in production? I can bet you that maybe 1% of engineers ever needed to do anything in this area beyond what the standard library gives them.
How about Dijkstra’s algorithm, depth-first vs. breadth-first search? Man…It brings memories. It was bread and butter for me back in university. I could implement it faster than you would say, Shazam.
Let me check how often I needed any of this in my 25 years of software engineering career… Hmmm… Let me think…Oh, I needed it once. I was writing a game almost 25 years ago and I used the Flooding algorithm.
Don’t get me wrong. There will be a small percentage of people who will be implementing game engines and will need a hell lot of mathematics, geometry, and algorithms. There will be people who will build a new database, and they damn better know how to optimize search and sorting. However, for the absolute majority of us, we learned it, put it on some top shelf of our memory and it’s been collecting dust there for the last 20 years.
Other algorithms and structures
Ok. Maybe I am exaggerating? I just chose the weakest link (algorithms). How about data structures?
Hey you, Mr. staff engineer in silicon valley unicorn, tell me, when did you need last time to invert B-tree? Actually, when was the last time when you needed to use B-tree? The hell with B-tree. When was the last time when you needed to use a stack structure? Sure, there will be way more people who used stack structure recently than people who implemented quicksort from scratch. However, I have a feeling that tons and tons of code are written which don’t use it (in the best case) or uses a prepackaged version of it (in the worst case). (read: people need only very cursory knowledge of it).
Languages
I learned Lisp programming language as an introduction to Functional languages back in university. On the one hand, functional language found its niche and even bled into procedural languages. However, languages like Elixir, Haskell, and Closure, I believe, never even broke a rank of the top 20 programming languages.
It helps you be a better software engineer.
So, I laid out this argument about the fundamentals to ChatGPT and it replied to me the argument below, which is incredibly common (BTW. I love that ChatGPT can easily spit out the common denominator of what people think.)
However, understanding these concepts is still important as they provide a foundation for understanding more complex systems and solving more challenging problems.
I hate this argument. It’s a classical Russell’s teapot argument when you put some damn big claim and push it on your opponent a burden to disprove it. And actually, it’s on you to prove the claim and not on the opponent to disprove it.
This argument (that it helps to become a better engineer) is quite far-fetched. You have some bits of knowledge (algorithms, data structures, etc.) that could be used rarely and lie dormant for decades, and somehow, magically, they help to “understanding more complex systems and solving more challenging problems”
You know… Eating chocolate and having long walks helps me to understand complex systems and come up with solutions to challenging problems. Oh… And it helps me in a predictable and almost measurable way. So, from now on, I postulate that eating chocolate and having walks are fundamentals of software engineering. I am happy to become a tenured professor in these disciplines, either at MIT or Stanford. (If you are part of these fine institutions, please give me a call, I can start teaching these disciplines on short notice).
I rest my case
The truth is that if you examine a lot of these fundamentals closely you notice they are neither used by most software engineers nor used in most situations. They could be extremely important but within niche situations.
The argument that they magically help you be a better software engineer doesn’t hold water either.
What is going on here?
Do you know what the problem is with all these fundamentals? Actually, it’s not that they are bad. They are all good. However, they are fundamentals for the wrong field. These are fundamentals for computer science, not software engineering.
Computer science goes heavy on these theoretical aspects because it concentrates on problems like new language design, performance, OS design, and new algorithms to solve some critical problems. I think the golden era of computer science ended around 1980–1990. Gradually, amount of software engineers that need to do _engineering_ significantly overtook the number of people who work on computer science problems.
And by now, we live in a world where the ratio could easily be 100:1. There will be hundreds of people gluing together Javascript and Python libraries to get something working to one person who will be working on advancing Rust language or optimizing database engine.
So, what are the fundamentals of software engineering again?
This is a great question. The fundamentals of software engineering are concentrated on engineering (vs. science).
As I was searching. I stumbled on this Carnegie Mellon University course named Fundamental of Software Engineering.
And I think it has an excellent curriculum covering the true fundamentals of software engineering:
- Introduction to Software Engineering
- Code Management and Software Archaeology
- Open-Source Software (OSS)
- Requirements
- Software Architecture
- Quality Assurance (QA) and Testing
- Software Process
- DevOps and QA Process
There are several items that I would say are missing, and a couple of extras (I didn’t include those). However, overall it is lightyears closer to what each engineer will do on a daily basis and what will help software engineers solve complex problems.
And, yeah, fundamentals are incredibly important. Did you really think that I would bash them? :)) You will constantly stumble in the dark without understanding requirements, processes, testing, and code management.
However, it’s bizarre that we have been putting emphasis on the wrong fundamentals for the last… thirty years.
