A couple of weeks ago, I was helping a junior software engineer with a project. It required updating some legacy Ruby on Rails code that was making an API request. The code we needed to get to was buried under several layers of abstraction.
So while the ask was pretty straightforward… actually doing it was a different matter.
He got to a point where he was spinning his wheels. So I jumped in to help out. I looked at it for a little while and I was able to figure out what was going on.
He described me as a "wizard.” I had just done the impossible.
At least, in his view.
Of course, I didn’t feel like a wizard. I was just following instinct… following one piece of code to the next through the inheritance hierarchy. With that and a little help from Google for Ruby minutiae, I was able to trace through the program down to the relevant piece that needed updating.
This experience did get me thinking though… why was I able to go into an unfamiliar codebase, in a language and framework that I am by-no-means an expert on, and, in a relatively short amount of time, figure out what was going on?
I can trace back my thought process back to the Computer Science 2 course I took in the Spring of 2012. Object-Oriented Programming in Java.
In that class, I learned many of the fundamentals of OOP. Abstraction, encapsulation, inheritance, polymorphism. I learned how to apply those concepts with interfaces, abstract classes, generics, and more techniques.
All these years later, I’m still applying those lessons in completely different languages and environments.
When I was young, I had to learn the fundamentals of basketball. You can have all the physical ability in the world, but you still have to know the fundamentals.
- Michael Jordan
Over the years of my career, I’ve seen those concepts play out across several different languages. And I’ve seen them expressed in several different design patterns, frameworks, and software architectures. So with that experience, I have further refined my understanding of these fundamental principles.
I’ve seen good examples.
I’ve seen a lot of not-so-good examples.
I’ve learned from all.
My observation at this point in my career is that I have gotten far more mileage out of learning and practicing the fundamentals of my craft than I have ever gotten out of focusing on the new shiny thing. Or even deeply focusing on a particular language or technology.
Now don’t get me wrong, there are seasons when you do need to keep up with the latest and greatest. Things do change. You need to know what’s possible.
And if you’re career is in a specific area… AWS engineering, just as an example, It’s necessary to know all the ins and outs of that particular technology. To dive deep.
My point is that in any craft or field of endeavor, there are a common set of principles that everything else is built on. The fundamentals.
Not taking the time to learn these fundamentals will hold you back.
Taking the time to learn, practice, and master the fundamentals will unlock an ability to adapt to new and unfamiliar situations. You’ll start to see how they apply across a wide variety of contexts.
You’ll see patterns emerge where there was once chaos.
Then, all of a sudden, things will make sense.
What constitutes the fundamentals for your field or specialty may vary. Here’s my attempt at listing what I think are a few good topics to start with as a software engineer:
Data Structures and Algorithms
The basics are not as scary as you might think. Realize, an array is a data structure. Algorithms are often just the techniques by which we can Create, Read, Update and Delete (CRUD) the data within those structures. Almost everything else is built on top of this.
Can you describe the difference between an object and a class?
I’ve conducted dozens of interviews, and a good number of candidates struggle with this.
The Four Pillars of OOP: Abstraction, Encapsulation, Inheritance, Polymorphism.
The difference between Composition and Inheritance.
It’s helpful to understand some basics of how the internet actually works.
How is data exchanged between client and server?
Can you create a few tables, relate them, and use SQL to query from them or modify them?
If you need resources to help you get started, here are a few I recommend:
While this book is mainly about interviewing, I find a lot of value in its overview of so many topics from computer science and software engineering. If you don’t know where to start, start here.
Pay for a month and spend some time on the beginner learning track.
Just spending a couple of weeks on this free course will help you have better conversations with systems and network engineers.
You might disagree with some items I’ve listed. Or, you may think I failed to list some critical items. I’m fine with that! Please feel free to add items in the comments.
Mastering the fundamentals is far from wasted time.
So if you’re in a season where you’re wondering, how can I grow? What’s holding me back from reaching the next level? Consider going back to basics.
Revisit the fundamentals.
It will pay off BIG TIME.