This article was originally posted on Breadth a weekly newsletter aimed at helping you increasing your technical (and non-technical) knowledge to help you become a more effective engineer
One of the worst qualities a software engineer can possess is complacency.
Software engineering is a complex minefield, with ever changing goal posts.
You can literally take a nap and miss 5 new waves of front end frameworks.
Being complacent as a software engineer is the same as being ignorant. One of the biggest mistakes you can make is telling yourself that “You know what, I know every thing I need to know to do my job”.
Why is this such a problem?
Because once you start being complacent, you stop learning. When you stop learning you slowly keep out of touch with the industry. You accept that the knowledge and tools you have today are all you are going to ever need to do your job.
Never will you find a better way to perform X task, use new abstractions, solve problems in different ways, increase productivity, improve communication and most importantly progress as an engineer.
So what is breadth? Breadth is the opposite to depth.
Breadth is the extent of how broad or wide your knowledge base spans in a particular area.
Whereas depth on the other hand is the extent or expertise you know about a particular topic in that area.
For example, breadth might be about how much you know about the automotive industry.
You might know a little bit about cars, the sales process, the manufacturing process, who the big players are - you get the picture.
That’s the breadth of your knowledge - you might not know a lot about all those things, but you know enough about them to hold a conversation or understand their basics.
Depth on the other hand, would be how much you knew about anyone of those individual topics. For example, you might have a great deal of depth on the manufacturing process of cars. You might be an industry expert.
But on the other hand you might have a small amount of depth of knowledge on the sales process.
Now obviously as an engineer depth is important, but I’d argue that breadth is equally, if not more important.
Depth is probably what got you the job in the first place write. Your ability to write code in a particular environment.
It might be backend node.js web applications, it might be a react engineer or a C++ embedded device engineer. Most of that is going to be depth.
But what really helps you shine as an engineer is breadth.
To put it simply - your ability to solve a problem is limited by the amount of solutions you know. If you only know one tool, one language or one solution exists, then you are going to most likely use that.
As the famous quote goes - ‘Everything is going to look like a nail if all you have is a hammer’.
Knowing a lot about one small subset of an area is great. But that is the only time you will be useful. Outside of your comfort zone you’ll be lost.
Let’s there’s a guy named Bob. Now bob is quite the node.js + postgres aficionado. He’s been using them for years and knows them inside out.
Now Bob has gotten a task, implement a full text search for their entire catalogue of medical records. Just a measley 840gb of data.
Now as someone with a single hammer at his disposal (postgres) he’s most likely going to jump at using it’s full text search capabilities to solve the problem. Whilst he know’s it doesn’t really scale that well at those volumes - it’s all he knows so it’s all he goes for.
Had he had greater breadth of knowledge - he’d probably realise that hey - there is a better tool for solving this problem. In fact, he might have been aware of 5 seperate tools, and the tradeoffs associated with each.
Now he can evaluate each of these tools and come to the conclusion of the best tool for the job.
Suddenly he’s not trying to put humpty dumpty back together with a hammer, but instead tape and glue.
Because it gives you more options.
The more you step outside of your comfort zone, the more you learn and expand your technological breadth the more effective of an engineer you’ll be.