Back in those times when I just started learning how to code, I trusted the old wise weasels with their “Programming languages don’t matter” mantra. I grew obsessed with the idea of some day becoming a developer who can do just anything. That guy who transfers his experience from one technology to another and transcends the minutia. But that idea failed miserably.

The obsession with knowing it all

I learned C# and .NET across different application domains (asp.net, wpf, xamarin), js/ts (react/redux, node) and convinced myself that I had the power to do anything I wanted. My thinking was abstracted, I was efficient in several programming paradigms at the same time, and I had practical skills in all aspects of professional software engineering. I was all set for ridiculing those 40-something seniors with their addiction to a single technology, who had spent half their life to fathom what I could grasp in a week’s time. I was close to declaring that going deep into some knowledge domain was for morons who were happy to have the same job for the rest of their lives, whereas I was abstracted from it all.

I thought everything was just the same old thing, so I kind of saw a consistent pattern. Now when my job involved coding in some ludicrous Python, I would go, ‘Give me some time to have a quick read through the spec, and I’ll be all set to work with this shit at a senior level. Why, what complications could probably be there of the kind I haven’t seen before?’ And so I fell prey to the detail-neglection cult. Let juniors fiddle with the details, seeing that they are incompetent with abstraction.

Knowledge gaps are subtle and not immediately visible

I once cranked out a design based on abstract classes in TypeScript, and got ridiculed because apparently nobody does it this way in TypeScript. I certainly pretended that my colleagues were hopeless idiots. It used to help before, but that time it left me with a bad aftertaste.

Your reputation of a good developer can disguise your knowledge gaps both from your colleagues and yourself. You therefore are ignorant of an enormous number of critical specifics, but of course you can’t see them, exactly because you don’t know about them.

That’s when my bad streak started. Poof! I had no idea about the types of indexes in SQL. Bam! I forgot when I should call a static constructor in C#. Oops! I couldn’t implement IDisposable correctly without looking it up on Google. Oh, and I was trying to mutate the state of a react component.

I then suspected that my abstraction was not really working. That the types of technology I was dealing with were different after all and that details mattered. Each technical ecosystem has its own unique best practices. Your .NET experience won’t hurt when working with jvm, but it can’t replace it. My self-assessed skill of ‘having learned how to learn’ turned out a play of imagination. My learning speed was no faster than that of others. This realization came way too late.

My skill was just a bag of conflicting ideas — I was being torn apart with bits of knowledge from here and there. I did not automatically become a senior Jack-of-all-trades. Instead I became a multi-skilled mid-level developer, a laughing stock for 40-something seniors who had mastered one technology. Thus, I realized that choosing the path of full-stack was a mistake.

Beating myself up about it

The problem is, businesses need full-stack developers. No, not the imitations like me, but versatile seniors, the guys who have five years of experience in each of the full-stack technology under their belts.

However, these unicorns don’t exist, so businesses go for self-deception. They take a mediocre mid-level engineer who specializes in three big-time technologies and call him a senior full-stack developer. This job title turns the engineer into an impostor and serves as an inexhaustible source of an inferiority complex. Any ordinary developer who focuses on just one technology knows it better. Now I can admit to not being ready to collaborate on equal terms with people who are much better than me at something. Otherwise it’ll be a week before I’ll have beaten myself up to death.

Self-recrimination is a huge malady in our industry, but we cure it with the wrong remedy. We exchange proclamations of how we are superheroes surrounded by assholes. We deny such thing as senior devaluation, we keep saying we underestimate ourselves, we just need to throw away our humbleness and believe in our internal goddess of software development. We think we need to put on the arrogance hat and give the finger to anyone who has too little faith in us.

Well, we just need to acknowledge that development is hard not only to outsiders, but also to us. Not knowing about something at any given moment is OK. If you have a gap, it doesn’t mean you are worth any less and have to be expelled from the community.

But somewhere at the deepest level of self-reflection we are still beating ourselves up. Full-stack developers curse themselves for not having deep knowledge of technology. Single-discipline experts lament that they don’t have a broad range of skills.

Learning in breadth vs learning in depth

Here we have the same old dilemma: you can either learn in breadth or in depth, but not both at the same time. I noticed an interesting side effect: when you start learning a new technology, the old one seems less interesting. But in the IT world, if you don’t refresh your knowledge of technology within a year, it makes you obsolete.

If you want to keep being a full-stack developer, you will have to make yourself read through the release notes of some TypeScript, testing all of that as you read, even if you don’t feel like it. Still, you will be miles away from a developer who codes everyday specifically in TypeScript.

The major problem of this conflict is that we have no idea of what’s best. We, and especially businesses, want it both ways. To have everyone have the right, in-depth skills.

I don’t know what’s best, but I know how it feels from the standpoint of a full-stack developer. You will spend much more time learning, compared to single-language developers. This will go on as long as your career lasts, and still you’ll lack their level of proficiency.

You will be welcome everywhere, but nowhere really at home. Despite your enormous efforts, every guru of the next big thing will foam at the mouth claiming you are not worth to be called a senior.

You will be stuck at mid-level for ever.

I for one decided to stick to my path. I could try learning something really in-depth, I could retrain for management (the field where superficial knowledge is an industry standard), but I’ll rather stay the way I am and will endure suffering until I really learn everything about anything.