Favor Deep Knowledge Over Broad Knowledge

Technology is advancing at an amazing rate. The number of projects on GitHub alone is increasing at an exponential rate. There’s Docker, Amazon Lambda, React (no Angular!), and Spring and all its related projects. There’s Kafka and Elasticsearch and Zookeeper, oh my! Just keeping up with all the Netflix open source libraries is a full time job. With all this new technology and more showing up all the time, how do you keep up with it all?

Answer: You don’t.

It’s good to know that these technologies are out there, but effective developers focus in on a few specific technologies and go deep, learning them inside and out. They favor deep knowledge over broad knowledge.

Over my career, I’ve used a variety of technologies. Some of them seemed promising at first, but turned out to have big problems once you got beyond the simple cases. Others, I’ve come to know and love and still use to this day. While I’m not afraid to learn something new, I tend to do so when it has application to the problem I’m trying to solve. I may not know about a lot of things, but I know a lot about the technologies I have learned.

Go Deep, Not Broad

It’s fun to learn about new things, especially new technology. There are a lot of creative people out there! We are hard-wired to learn. Our brains love the dopamine drip of novelty.

Unless you’re in an academic setting, you are paid, as a software developer, to solve problems.  You write software that will serve your customers by helping them solve their problems and, in return, create revenue for your company. Knowing about all of these technologies won’t do you any good if you haven’t delved deeply enough to put them into practical use.

Do you know how the software reacts in various failure scenarios? What happens when the load increases? As the size of the data managed by that system increases, how does it scale? If it’s a library or framework, do you know how to use it without referring to the documentation (much)?

Fear of Missing Out

It’s easy to get distracted by the latest, shiny thing. We’re afraid of missing out on the next big thing. What if this is the magic tool that will solve all my problems? (It isn’t) What if this is the tool that will help me get that next job? (It won’t)

As I mentioned earlier, there are way too many things to keep up with. New things are introduced every day. Some of them might even be a better solution to your problem than what you’re currently using. But if you haven’t learned the first technology inside and out, how can you properly evaluate whether the new one is any better? You have a solution that works and you know where the pitfalls are and how to avoid them. Is the new solution better, or just different? What is the cost of switching and do the benefits outweigh the cost, in the long run?

Remember, “Better the devil you know than the devil you don’t.”

Specialization is Good

If the foundation of your house is cracking and the floors are sagging, do  you call a general contractor or a structural engineer? The general contractor probably knows something about how to build a sturdy house, but the structural engineer knows exactly how to calculate loads and recommend how to support your house properly. Who would you rather hire in this scenario? The specialist, of course.

Does the structural engineer need to know the latest electrical or plumbing codes and practices? No, nor would you expect him to. But you would expect him to know the latest research on soil movement, concrete mixtures, beam design, and the like.

The same is true in the software industry. Sure, there are people that bill themselves as full-stack developers. However, they typically have a strength in one area and know a bit about the rest. That is, they might be a UI wizard, but only have cursory knowledge about how to build a backend system or write efficient SQL.

There have been many times when I’ve learned just enough to get the job done. For example, I can usually get a working UI up in a browser, using a framework such as jQuery or Angular, but it takes me orders of magnitude longer than someone who knows the various technologies at a deeper level.

Many of the places I’ve worked over the years have broken out development roles by specialty. They’ve realized that there’s just too much for one person to know, so they split up the responsibilities. Database developers know how to build good data models and efficient queries, UI developers know how to wrangle all the various browsers and make them behave in any scenario, network engineers keep all the servers talking to each other and the users, system administrators keep the servers up and running smoothly so the software developers have a place to run their code.

Specialization is not only a good idea, it tends to be how most software shops work.

Conclusion

Don’t get me wrong, learning new things is an essential skill for any software developer. After all, you will need to get up to speed when you join a new project. There are new technologies that are worth spending the time to understand. Otherwise, we might as well go back to programming in COBOL.

But as a rule, go deep and master the skill, don’t just gain a superficial knowledge. You may have heard the phrase, “Jack of all trades, master of none.” Be the master of a few.

When you have a problem to solve, believe in your ability to find the technology, learn it, and master it. Go for deep knowledge over broad knowledge. In the long run, you’ll be a much more efficient and effective developer.

Discussion Question: What is your opinion? Is deep knowledge in a few technologies better than a broad knowledge of many?