Skip to main content

How full is full when you say Full-Stack Developer?

A meditations on why should we all pursue being a specialist.

Updated 3 min readMarkdown
How full is full when you say Full-Stack Developer?

Now don’t mind the title of the books, I just want a visual representation of books to somehow portray on the readers how much book you need to read in order to be decent at something. The name of books there is not relevant but my point is that’s the capacity or volume of books you need to learn to be actually decent at something.

FullStack as a Trap: A Reflection

In my opinion being a full-stack is a trap for someone who is new on the software engineering field.

I would rather be a junior on a specific end (front-end or back-end) rather than be a full-stack developer who works at the client side and server side but doesn’t have a deep understanding on what he / she is doing.

Yes, fullstack is a lucrative career. It looks great on a résumé and often comes with appealing salaries. But in my view, being a specialist will be far more rewarding in the long run.

It healed my impostor syndrome when I just focused on back-end. Having to understand your code line by line and not prompting your way to production will surely make your confidence grow. Also by going back to fundamentals and not skimming through the hot technologies, Please.

The Industry Problem — and the root of your impostor syndrome

Forgive me for what I’m going to say but, I noticed that there are just people in the industry that are guilty of this. We call ourselves “fullstack,” but what we’re really doing is building on top of frameworks without truly understanding the foundations beneath them. Of course you will feel a fraud, cause you don’t know how that x library works!

I think this the root of impostor syndrome, atleast on my own experience. Not having to question, how did that happen? Like example when you are using a library , a back-end library by just injecting that piece of code that x feature is working. Question it, like the famous Automapper library on the .NET community how did it map your entities to your DTO? The answer is reflection in c#. I’m not saying that you should really understand it to the point you can roll your own libraries. But having a grasp on those tools will surely make you a better software craftsman.

The Learning Problem

How can you learn or say that you are fluent in a technology when every year the knowledge that you need to partake increments? It’s impossible to learn everything in and remain good or relevant in an industry like tech, but having a deep understanding and a good fundamentals will surely make you still relevant for 1-3 years in a particular stack. That’s why full-stack isn’t for the new ones, It’s for the much seasoned developers who already have an in-depth understanding of one area, who are already experienced on more projects.

So here is my take, If you are lucky enough to land a role that let’s you dedicate yourself to one end. You may escape the paradox that ensnares a lot of new developers. You might be much more closer to the stillness, on the state of stillness that you are somewhat comfortable / decent on utilizing your stack.

“Now will you choose to learn broadly and risk knowing shallowly, or learn deeply and risk irrelevance?”

About the author

  • A software developer trying to write organic blogs in C# and .NET technologies.

No comments yet. Be the first to comment.