I recently crashed and burned at a technical interview. It's not the first time that happens mind you, but last time I successfully blamed the automated tool that was providing the exercises. This time the blame falls squarely on my shoulders.

But, silver linings and all that, it has exposed a potential flaw in how I have been learning, exposed some areas where I should know more, and probably helped me reason as to what I am professionally and what I aspire to be

In this article, I will explore why I have what I would call an 'unfocused' approach to learning, what disadvantages it has brought me, and what advantages I believe it has.

Why am I unfocused when learning

The short answer is that I do not see myself as a specialist, I today know more about web development and Ruby (on Rails) but I have dabbled with various languages, either professionally or as a hobby. And I see myself as a software developer, not a Ruby or Web developer.

The long answer is... Well, long. So I will have to break it up, I believe there are three fundamental reasons for this: my professional background, my volatile curiosity, and my self-perception.

Professional Background

Since before I started coding, I have always been more of a generalist, even in school where I combined a curriculum that had optional classes as eclectic as physics, history, and economics.

Once I entered the professional world, I had experiences in HR, Sales, and Logistics before I started coding.

And even there, I was very soon confronted with a very big app and several technologies, in my 5 years as a software developer I have been in small teams where adaptability was key, and have used (with more or less regularity):

• Ruby (on Rails)

• Postgresql

• jQuery

• React Native

• Vue

• Stimulus

• Node

• Dynamodb

• Python

• Bash

• Heroku

• Aws

And that holds also true for the functional roles I have had, not only technical full-stack-ish roles but also some product and people management.

This has led to me having to upskill in very varied areas and doing a lot of "on-the-job" training

Volatile Curiosity

I am a very curious person, the problem is that I am curious about 'big pictures' I have always had trouble getting super in-depth in a subject, and when that has happened it has been mostly through repeated contact more than a concerted effort to know everything about a subject.

On the other hand, that has led to me reading or playing with among others:

• Go

• C++

• Architecture

• DDD

• Refactoring

• TDD

• Clean Code

• Networks

• Algorithms

• Game Dev

• Python

But I have never gone in depth in any of those subjects.

Self-perception

I see myself as a developer, not as a web dev or a game Dev or an enterprise dev. As such, I tend to prefer learning about 'base concepts' rather than concrete technologies.

For example, I have finished DDD and Refactoring, but eloquent JavaScript and Ruby under the microscope are in that pile of books that I pick up occasionally to read a couple of chapters but never quite finish.

Disadvantages

So, I believe I have quite thoroughly established that I am neither an I-shaped nor a T-shaped developer, I am either a pancake or a plateau dev. But what are the disadvantages of that?

The main one that comes immediately to mind is that I am immediately unqualified for many expert positions. If you are looking for the X person... Well, it is not me.

The second one is that I am in a constant impostor syndrome mode, there will always be someone (or rather a lot of someones) that knows much more than me in any given subject.

Finally, while I will be able to explain a wide range of subjects, I might not be particularly precise in any of them (e.g. to this day I struggle to explain the difference between a proc and a lambda in Ruby, although I can use both and remember it's something about scope).

Advantages

Again, the advantages are rather 'obvious', the main one is that I am extremely adaptable, Do you want me to go code in a Java or Elixir codebase? I am pretty sure I will be able (with effort) to pick it up and be operational rather quickly.

I can also opt for many more positions, as tech stack does not matter that much to me, and the functional roles I can take are also very varied, from CTO/tech lead of small teams to back or full-stack dev on already established teams, from companies that see their developers work hand in hand with their product to companies that see their developers as doing 'only' the tech part.

Non-conclusion

All this has highlighted some areas where I want to put a bit more focus in the coming weeks, the first is networks (top-down), the other one is a subtopic of networks and it is more, what happens in the lifecycle of a browser request.

And you? How would you describe your knowledge? What is your big little blind spot?

Tell me here or at Twitter or Mastodon