Technical Breadth
Technical Breadth is a term I first heard, in English, from the architect Mark Richards. The Russian rendering would be something like
“technical horizon.” The designers’ equivalent is having a “trained eye.”
What do you do with this idea and how do you broaden your own technical breadth?
First, it’s worth understanding that growing your technical breadth doesn’t mean becoming an expert in every area. It’s more about gaining a deeper understanding of tools and technologies than just a surface-level acquaintance.
Here’s an example. We’ve all seen informative grafana dashboards that
make it clear what’s happening with a service at a given moment. But the moment you’re asked to build your own dashboard, you most likely
freeze up. The first attempts at a clear dashboard rarely come out the way you expected. What you get instead is a set of unreadable, useless
charts that don’t really convey anything.
How do you get out of this?
Through practice, of course — through growing your technical breadth, which over time turns into depth of technical knowledge.
Back to the grafana example: you could find the official YouTube
playlist and at least get a theoretical sense of the tool’s capabilities.
Next, you’d learn about the grafana playground, where you can practice
building dashboards. At some point the playground will start to feel
cramped, and you’ll spin up your own local instance — even just in docker compose — set up auto-provisioning, and move on to using
grafonnet.
That’s how breadth gradually turns into depth. It takes consistent practice.
Second, not every technology deserves deep study. For the past few years, machine learning has been the focus of most people and companies. If your work isn’t directly tied to it, at least skim the surface with one goal: to understand what people are talking about. A general grasp will let you go deeper on demand and dig into it thoroughly when you need to.
So when do you actually rest?
This isn’t a motivational pitch telling you to forget about your free time. You’re perfectly capable of planning your own learning and how you broaden your horizons.
To wrap up, one more example. A lot of us moved to go from other
languages. And we found the time to learn the new syntax, the principles,
and the idiomatic patterns of a language new to us. We managed.
Roughly the same situation comes up with python. Long-time developers
who haven’t worked with it on large or mission-critical projects assume
they can pick it up easily. Simple, readable syntax; modern IDEs that
flag every error and suggest fixes — all of this creates an illusion of deep knowledge and complete command of the language. Try swapping a for loop in your python code for a list- or dict-comprehension,
and you’ll probably run into a few issues. Regular practice is what
helps you avoid them.
Grow your technical breadth, study the languages and technologies you use right now in more depth. Look for and explore alternatives. Don’t stop developing technically.