Fundamental knowledge
I’ve been calling myself a professional software developer for just over 20 years at this point. In the past few years, I have gotten into teaching university courses in the Computer Science curriculum. I have recently had the experience of supporting a non-techie as they went through a(n intense) coding bootcamp (aiming at full stack / front end roles). I’m also building a distributed database engine and all the associated software.
I list all of those details because I want to make an observation about the distinction between fundamental and transient knowledge.
My first thought is that there is so much to learn. Comparing the structure of C# today to what it was when I learned it (pre-beta days, IIRC), it is a very different language. I had literally decades to adjust to some of those changes, but someone that is just getting started needs to grasp everything all at once. When I learned JavaScript you still had browsers in the market that didn’t recognize it, so you had to do the “//<!—” trick to get things to work (don’t ask!).
This goes far beyond mere syntax and familiarity with language constructs. The overall environment is also critically important. One of the basic tasks that I give in class is something similar to: “Write a network service that would serve as a remote dictionary for key/value operations”. Most students have a hard time grasping details such as IP vs. host, TCP ports, how to read from the network, error handling, etc. Adding a relatively simple requirement (make it secure from eavesdroppers) will take it entirely out of their capabilities.
Even taking a “simple” problem, such as building a CRUD website is fraught with many important details that aren’t really visible. Responsive design, mobile friendly, state management and user experience, to name a few. Add requirements such as accessibility and you are setting the bar too high to reach.
I intentionally choose the examples of accessibility and security, because those are “invisible” requirements. It is easy to miss them if you don’t know that they should be there.
My first website was a PHP page that I pushed to the server using FTP and updated live in “production”. I was exposed to all the details about DNS and IPs, understood exactly that the server side was just a machine in a closet, and had very low levels of abstractions. (Naturally, the solution had no security or any other –ities). However, that knowledge from those early experiments has served me very well for decades. Same for details such as how TCP works or the basics of operating system design.
Good familiarity with the basic data structures (heap, stack, tree, list, set, map, queue) paid itself many times over. The amount of time that I spent learning WinForms… still usable and widely applicable even in other platforms and environments. WPF or jQuery? Not so much.
Learning patterns paid many dividends and was applicable on a wide range of applications and topics.
I looked into the topics that are being taught (both for bootcamps and universities) and I understand why in many cases, those are being skipped. You can actually be a front end developer without understanding much (if at all) about networks. And the breadth of details you need to know is immense.
My own tendency is to look at the low level stuff, and given that I work on a database engine, that is obviously quite useful. What I have found, however, is that whenever I dug deep into a topic, I found ways to utilize that knowledge at a later point in time. Sometimes I was able to solve a problem in a way that would be utterly inconceivable to me previously. I’m not just talking about being able to immediately apply new knowledge to a problem. If that were the case, I would attribute that to wanting to use the new thing I just learned.
However, I’m talking about scenarios where months or years later I ran into a problem, and was then able to find the right solution given what was then totally useless knowledge.
In short, I understand that chasing the 0.23-alpha-stage-2.3.1-dev updates on the left-pad package is important, but I found that spending time deep in the stack has a great cumulative effect.
Joel Spolsky wrote about leaky abstractions, that was 20 years ago. I remember reading that blog post and grokking that. And it is true, being able to dig one or two layers down from where you usually live has a huge amount of leverage on your capabilities.
Comments
How true. You also gain insight from your failures. There is much to be gained from acquiring translational knowledge, even if by accident or expirimentation.
Some of my favorite memories were taking things one level deeper than I knew. The sheer number of poorly implemented STL containers to try and understand their template witchcraft. Adding FAT8 support to a toy OS. Writing a very basic SQL query planner. Creating a tiny processor (virtually) and writing machine code and an assembler for it. Emulating (poorly) RISC machines in PHP complete with a debugger. Adding matrix math support to the SpiderMonkey JS engine (something like FireFox 1.X or 2.X era). Building an application protocol over TCP (and/or UDP). Taking an RFC and implementing it (largely an exercise in filling in the blanks called "implementation details"). Taking some simple code and porting it to random languages (OCaml, Scheme, Go, Ruby, whatever).
I can easily tell what was fundamental knowledge by looking back at things i learned 20 or 15 years ago, but what about today? I'm sure there are huge areas of fundamental knowledge i don't have, but what is it? Artificial intelligence, signal processing, maybe motion control for robots or the blockchain? Or ARM instruction set? I'm too old to try to soak up everything so conveniently i'll consider everything i don't know as non-fundamental :)
Rafal,
In general, whatever you do that would be deep would be fundamental in 20 years.If you learn signal processing, and then apply that down the line (because you know that ,so you have the opportunities for this). I would disregard blockchain :-), and in general, looking at the past is a good indication. Going deep into a UI technology is unlikely to pay much dividends, they change too often.Learning assembly, esoteric, but kind of useful in many scenarios.
Comment preview