Being a software engineer in 2022 is demanding. On one side, you have to know more and more technology to be a so-called full-stack developer and be knowledgeable both on front-end and backend. You also need to have some knowledge of the DevOps practice and tools to know how your application goes from your local environment to production in an automated manner. You have to be comfortable with your development environment and know the tips and tricks that will make you productive.
In short, you have to know a lot.
But you still need to have a depth of knowledge about the stack you are using daily. Learning a little about many things might be fun, but when it comes down to the working environment, shallow knowledge about many things will not help you when you work mostly with the same technical stack every day. Knowing how to build a hello world app in 10 languages might impress your friends, but not so your manager. You often need to have deep knowledge about the stack you are working with to bring real business value.
It is common to find a job offer that asks for X years of experience with a specific language or framework. And even though switching technology is easier as you get more experience, that’s the reality of the job market today, and we have to bend to the rules.
So how do we deal with this discrepancy?
We need to find a way to combine those two aspects without neglecting one of the two.
And the way is to become a T-shaped engineer.
What is a T-shaped engineer?
The T-shaped engineer is a mix between a specialist and a generalist. He is capable of solving difficult problems in his area of expertise but also manages to understand new problems and get up to speed quickly with new technologies, tools, or practices, thanks to the large number of concepts and patterns he is familiar with.
The vertical bar represents your depth of knowledge in your field of expertise. It might be a tech stack like Java backend, a business domain like banking or health, or a technical domain such as web performance or complex distributed systems.
This type of knowledge is useful when you have to solve a difficult problem that requires an important depth of knowledge about one specific topic.
The horizontal bar represents your breadth of knowledge of all topics related to software engineering. It is the technical background that you use to learn new concepts and be able to broadly understand the problem your coworker from another team is facing even though you have no real practical experience with it.
This type of knowledge is necessary for all software engineers, but even more so for experienced engineers that need to tackle architecture problems, where it is important to have a broad view of what exists, to know what are the potential solutions, and which solution suit best the current challenge.
Why being a T-shaped engineer is important?
The current trend for software engineers is to work on a large stack of technology and use more and more abstraction as a result. Those abstractions have started to appear everywhere, from infrastructure with Kubernetes, to backend with large frameworks like Spring Boot or frontend with Single Page Application frameworks and libraries such as React, Angular or Svelte. The necessity of abstraction has become mandatory because it has become impossible for an engineer to know every bits and pieces about each part of the stack they are working with.
But working with all those abstractions is fine until you encounter a problem that requires more in-depth knowledge about the topic at hand.
Expertise is also important to know when not to use those abstractions and go with a more lightweight or homemade solution that is best suited for the problem at hand, so as to avoid using the latest shiny tool because everyone has started to use it.
More, I find that being good at something is a skill in itself, and once you have become good at one thing, it is way easier to become good at another thing, because you can use your previous experience to know what is important and what is not.
A good setup would be to have a team composed of T-shaped engineers that have a large part of common knowledge, but that each specializes in a specific topic of the stack so that any potential problem that may arise can be solved by at least one member. And with time, those in-depth bits of knowledge will start to spread to the entire team.
Another important part of being a T-shaped engineer is that it reduces your blind spot, and allows you to be more aware of what you don’t know. This can prevent you and your team to struggle to solve a problem with X while you could have solved it in ten time less time if you knew about Y.
Of course, this is totally dependent on the context of where you work. Some company still requires specialist, working in-depth on a single topic, or jack of all trade, working on shallow problems that stretch across many topics.
But I think that even if you are in such a situation, working on increasing the length of your shortest T bar will make you a more future-proof, well-rounded software engineer, ready to tackle any problems your will encounter. By focusing only on a single technology or domain, you might shoot yourself in the foot, by stopping to learn about new things and risking closing doors. By being spread on too much technology, you might never be good at something and encounter the type of problem that can only be encountered when you have in-depth knowledge.
How to become a T-shaped engineer?
To be a T-shaped engineer, you need to focus on both bars of the T. Depending on your situation, you want to either enlarge your horizontal bar or lengthen your vertical one.
You will want to enlarge your T bar if you feel like you are becoming a one-trick pony. This might be the case if you have been working at the same company, doing the same type of work for many years. To do so, you need to broaden your technical background and find out what exists. The goal is to be familiar with many concepts, tools, and technology, understand why they are used, when to use them, and what are the tradeoffs. This way, you will always have a solution when you are facing a new problem, and you will just have to go in-depth when needed.
You can do so by consuming different types of resources :
- Listen to podcasts: There are a huge amount of podcasts about any technology or domain. This type of resource is convenient because it can be consumed passively while doing something else. You still need to be focused on what is said, but you can listen to it while doing something else. Some examples of great podcasts I listen to regularly are Syntax which is more focused on web development, InfoQ about software architecture, or Javascript Jabber for all things Javascript, but there are many more to discover.
- Read overview articles: By reading these types of articles, you will start to have a broad understanding of the topic, encounter the main concepts and get an overview what are the key aspects. Those articles can be found on any personal blog or publication on the web. One of the most popular ones is freecodecamp.org .
- Watch overview conference talks or videos: This one is very similar to the overview article. It is just the format that changes. As an example, the Big picture videos from Pluralsight are a great way to get a quick and condensed overview of a topic.
- Read generalist publications and newsletters: By doing that, you encounter new concepts that you might not have searched for by yourself. For example, the Hacker News weekly newsletter is a great way of opening up your horizon and discovering various topics that you can get into if you are interested. It is not 100% tech-related, but there is always something interesting to discover each week.
To lengthen your Vertical Bar in your domain of expertise, you will need to go in-depth. For that, there are again several resources and practices that you can use.
- Build a Project and ship it to production: By doing that, you will start to have practical knowledge. In my opinion, nothing can replace practical knowledge gained by struggling while doing your own thing. This is what you should focus on to go above shallow knowledge. Maybe shipping it to production is not always relevant depending on what you are trying to improve on, but getting production experience is a valuable learning experience.
- Read articles on advanced topics: Once you know the basics, you can go search for more in-depth articles. By doing that, you’ll learn about different or better ways to do things. You will then be able to apply those new tricks to your projects to put them into practice. The best way to find those articles is by identifying the proven experts on the topics, and checking out what they produce or recommend. Some examples of such persona are Dan Abramov for React or Martin Fowler for software architecture.
- Dive into the documentation: This one does only apply to technology or tools. Most of the time, the engineers working on building the technology are the more knowledgeable on the topic, and the official documentation is often the best way to get reliable knowledge.
- Read books: even though books are becoming less and less popular with the rise of the web, they are still a great resource to learn from. I find that books are more relevant when learning about broad concepts or domains, and less when learning about the latest hyped technology or tool. Some books have become classics that all software engineers should know about, such as Clean Code, Domain Driven Design, Design Pattern, and much more.
- Go to in-person meetings and conferences: By doing that, you will meet engineers that share a common interest with you. You’ll then be able to share your experience, challenge your current knowledge and maybe discover a new way of doing something that you have been struggling to handle for months. For example, the Java User Groups are a great way to meet other java developers.
One last important thing is to focus on the fundamentals. Contrary to the latest hyped framework, this type of knowledge will always stay relevant and will help you adapt to many situations, and quickly swap technology or domain.
Things like clean code, refactoring or testing are some examples of essentials fundamentals that every software engineer should get good at.
Wrap up
Being a software engineer means you are in for a journey of lifelong learning, and being a T-shaped engineer is, in my mind, the best way to go through it. It allows you to focus on your area of expertise which is usually the one from your daily job, and still have fun by discovering and learning about new concepts and technologies. This model is not a silver bullet and is not suited for every engineer, but it is the one I find the best suited for most engineers.
Top comments (6)
Great read!
I really enjoy discussions about specialization vs generalization.
I think it does not stop at our craft, it can be extended to life in general (e.g. sports).
There are even people who argue that vast experiences are a prerequisite for true mastery.
David Epstein explains this in this book Range.
I wrote about it in this article if you are interested:
Forget the 10.000 hour rule! Strive for range!
Tobias Haindl ・ Mar 27 ・ 2 min read
Really nice article! I did not even know that whole my career I am striving to be T shaped engineer. Thanks!
Love the article and the detail! If you get the chance. Check out:
Who's the Better Hire? - Jack of All Trades OR Master of One
Tina Huynh ・ Apr 22 ・ 3 min read
Thanks!
Great article! Useful tips for enlarging horizontal and vertical bars.
Thanks!