Learn the Fundamentals, Exploit the Differences

When it comes to engineering tools, learn the fundamentals, exploit the differences.

So often I see early instruction on software development lean way too far into a certain way of doing things with specific tools, languages, and so on. While I sympathize that it does remove a lot of potential for choice paralysis and help to avoid overwhelming early learners, I think it also hampers them heavily later on if they are not exposed to more generalized learning methods. Showing someone one way of accomplishing something with a specific feature or characteristic of a tool is fine to get the general point across, but it's always worth teaching the fundamental that are behind the curtain as well.

I try to heavily impress this on early career engineers that I talk to. If you focus your early learning on the baseline fundamental concepts of software development and design, those skills and knowledge trasnfer to nearly everything you'll touch. But if instead you learn a certain framework in a certain language and (the key part here...) continue to make that your long term learning path, it will give you severe tunnel vision and make it harder as your career matures to learn to think in different ways about software problems. If all you've ever learned to use is a JavaScript mallet and a React hammer, you're going to try to make everything into a nail even if it's really, really not.

What's the best way to do this in practice? Work on boring stuff with boring tools. Don't be tempted by the new and shiny or the exciting right off the bat. Be forced to think through problems and ferret out the "why" behind the solution. Understand the how and why of what you're doing or what a tool or library is doing for you. Embrace the constraint and use it to inform how you think about things going forward.

As you start building this foundational knowledge, you'll know when to exploit the differences in tools to maximize your effectiveness. Let's say you know that Rails is unreasonably good for CRUD web apps, but you're a C++ programmer. If you need to build a CRUD web app and have tried to generalize your learning path as much as possible, you'll be able to reach for Rails when that's the task at hand. How? You understand the philosophy and semantics of writing code, and Ruby is just another programming language. You might not be an expert in 20 minutes, but you can level up quickly and be even more effective at writing a CRUD web app than if you'd tried in C++. If you're building concurrent software maybe you'll grab Go, or if it's something that requires incredible speed and memory safety, you might jump to Rust. If you've spent the time understanding general software engineering concepts and didn't lock yourself into a single language and toolkit, it's easier to apply what you know to start tackling the task at hand equipped with the absolute best tool on hand.

To continue the likely poor construction metaphor, let's you're trying to make a hole in something. If you've approached learning this way, you can do use the best tool because you invested in learning about the materials and the fundamental tasks. It will be easier to jump from a drill to a drill press to a saw depending on what you're trying to accomplish because you know how to do the fundamental task but can use the different strengths of the tools to accomplish it most effectively.

My point is, prioritize learning things that transcend tech stack and trend lines. You'll be a better engineer, your career will be more robust, and you'll definitely make yourself more valuable to employers (or, be better equipped to do your own thing!).