Skip to main content

Growth in Depth or Breadth

When you have worked as an engineer for more than 3-5 years, you may start to panic about the question "What's next, how to grow?" If you don't accept the answer "move into management or start your own business" and decide to continue evolving in the role of an engineer, you have two paths of development: depth or breadth.

Subconsciously, we consider these options in the context of the abundant number of technologies being created and evolving around us every day. In other words, this choice translates into the following: either learn more new technologies or delve more deeply into the technologies you already know.

Each of these options has its pitfalls.

Choosing the breadth of development, you will likely encounter the following problems:

  • The vast number of technologies is only growing.
  • Memory is not what it used to be at the age of 20, and remembering all this is very difficult, even if you understand perfectly what is discussed in the documentation of a particular technology.
  • Lack of results - it seems like you've learned 5 new technologies, but it doesn't help in your current work or in finding new, more lucrative opportunities.

As for the option of deepening:

  • What to learn? Why doesn't Google provide answers to questions like how to master React thoroughly?

Well, I can say that for me, the option of deepening is more profitable, productive, and useful. However, to squeeze the maximum usefulness out of it, you need to change your mindset. You need to stop perceiving deepening as the study of narrower, less common use cases of technology, learning the unused API of that technology, and so on.

So where to look for this depth? Just imagine that you know the entire API and examples of usage of the technology perfectly. Will this allow you to write high-quality software? I strongly doubt it. What will allow you to do that then? Fundamental knowledge of how software development should be, knowledge of patterns, approaches, knowledge of the pros and cons of various approaches. In other words, theoretical knowledge. People who say that 80% of learning/studying should be practical are wrong if you plan to play the long game.

To make it more illustrative, I will provide examples of a more correct choice when learning something new:

  • Do you want to learn TypeScript? Better study how typing works in general, what happens under the hood, and how typing models are structured. Why TypeScript is bad and why it's good, what alternatives exist. How to live without TypeScript.
  • Want to learn Playwright, Cypress, or any other testing framework or tool? Learn different testing pyramid variations, why to write tests, when to write tests, what metrics tests should have, what coverage these tests provide, what tests are bad, which ones are truly useful, what needs to be tested, and what doesn't.
  • Want to learn Express.js, Nest.js, or any other Node.js framework? Study how asynchronous programming works in Node.js, database design, why all these frameworks are bad, when to take them, when to look in another direction, why choose REST API, why GraphQL, study design patterns, different architectures for building backend applications, templates for their implementation.

Do you understand what I'm saying? Choose knowledge that will make you independent of technology. This knowledge will show that you are an engineer, not just a coder.

Such questions and problems are more common in the world of JavaScript. In the world of Java and C#, everything is solved by platforms and large technological stacks like Hibernate. Somewhere they go as a dependency, but an indispensable one, somewhere as part of the platform, but the main point is that everything is well thought out, there are solutions for everything, and programming moves to the level of applied tasks because all systemic issues are already solved in the platform. In the world of Node.js, there is nothing like that; there are tens of thousands of libraries that are not coordinated with each other, but in principle, they can be made to work together. That's what programmers spend 80% of their time on—tying them together, smoothing them out, wrapping them up, and coordinating them. The logger fell off, then the configuration slipped, then the routing fell apart, then the validation dropped off. All this is due to versions, library support discontinuations, the emergence of new ones, and changes in library policies; their authors tailor them for themselves and their needs, which change. Collecting inherently incompatible puzzles with scissors and glue is quite difficult; at any given moment, it's solvable, but it all falls apart in your hands, and maintaining it is very difficult.