Listen to this post
Reading Time: 4 minutes

Full Stack Developer vs. Software Developer, which is right for you? Let’s reframe the question.

To specialize or not to specialize, that is the question.

The software industry is not the only industry that faces this question. No matter what industry you’re in, it’s a loaded question. Like the answer to most queries, it depends. If you’re in a corporate setting, specialization is typically the norm, and within start-ups, it’s the opposite. In a small group, the specialty will impede a person’s ability to create value. In a large group, the value specialization brings has the potential to be off the charts.

I’m a generalist and have always had a propensity to chase the knowledge dragon.

Look! It’s a Knowledge Dragon in the wild.

This approach has worked for me, but it’s not without its challenges. I’m a jack of all trades, master of none. As a result, my imposter syndrome symptoms rage on. My specialist colleagues leave me in the dust on several topics. Fortunately, many people recognize the value of a multi-faceted perspective and will accept my lack of more in-depth knowledge of subjects. I can’t know everything.

Sometimes I consider deep diving with one technology and sticking with it. I then sweep that consideration aside when another shiny paradigm comes along. I’ve always loved learning big concepts that apply to all technologies. I’ve also enjoyed playing with new tools and breaking them ever since I was a child. I would disassemble radios, inspecting them, then put them back together again. I would try to fix them and sometimes with success.

Anyway, that’s enough about me, this is about you.

Should you be a full stack developer or a software developer?

Many businesses start with a specific product and specialize in that product. It’s usually a successful strategy until it’s not. It’s 2020, and Zoom is trending well over the past six months.

Specialization appears to have fueled most of their success. Zoom invested in a specific product with a limited set of applications. In the beginning, their product’s quality was low, but they’ve improved over the years.

Meanwhile, Microsoft is bundling Microsoft Teams into Microsoft Office, and it now has video conferencing. Microsoft is not a company that specializes. It has always focused on creating general solutions for broad applications. It remains to be seen if teams’ video conferencing will gain a foothold.

So why am I talking about companies and not you?

Companies are an excellent way to observe the advantages of generalization vs. specialization. We can correlate the outcomes that companies realize with either approach then choose the right path based on our goals. Start asking yourself some questions.

  • Do I want to start my own business in the future?
  • Does mastery bring me joy?
  • What will I do with a broad set of knowledge?
  • What about a deep set of knowledge?

This question is loaded and requires some introspection to answer.

If you’re building a team, finding a balance of generalists and specialists is likely the right approach. Without specialists, the hard to solve problems that require a deep understanding of software technology are impossible to solve. Without a generalist, a team might miss out on a perspective that will make a challenging problem go away altogether. The law of the instrument comes into play when we have tipped the balance too far towards specialization.

I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.

Abraham Maslow – 1966

I once worked with a guy that used the SQL Server database for everything. He succeeded in tightly coupling the whole enterprise to SQL Server. This guy stored the entire user interface definition in the database. He was enthusiastic about the power of this paradigm. I wasn’t sure if he was joking, but he talked about creating a SQL MVC book.

On the other hand, knowing a small amount of everything isn’t useful. It’s important to deep dive into key concepts like design patterns, clean coding techniques, etc.

In the end, deciding between being or hiring a full stack developer vs software developer is not cut and dry. This decision depends on your goals, your organization’s goals, and the environment. Here is my take on the subject.

Full Stack Developer vs Software Developer

Which is the right choice?

Software development is incredibly complex with lots of nooks and crannies.

The Software Developer is already spread thin and must bear with a large cognitive load.

The Full Stack Developer bears an even larger cognitive load and may become overwhelmed.

Full Stack Developer

Pros
  • Can move from team to team
  • Variety is the spice of life
  • Learns to quickly learn new things
  • Brings a diverse perspective to problems
Cons
  • Cognitive load can get out of hand
  • Squirrel?!
  • Focusing can be a challenge
  • Might make the wrong decisions when using complex tools

Software Developer

Pros
  • He had one job, and he did it well
  • Can become the lynchpin that makes the plan come together
  • It’s easy to find a job if your specialization is in demand
  • Lower workloads bring better focus
Cons
  • Might miss the forest from the trees
  • Opportunities to save time and effort could be missed
  • If the specialization becomes obsolete, what now?
  • Overfocus is a thing. Are you missing an opportunity?

Conclusion

Like any comparison or solution, take mine with a grain of salt. The differences between these two disciplines can be vast or just a few frameworks away from full-stack.

It’s not easy to see or pick the right path. Whether you’re a developer or a company deciding between the two you have your work cut out for you. Do some soul searching and try to find the right balance.

Share this post

2 Comments

  1. William

    I’ve been leaning into the concept of a “T-shaped skill” set, or the “generalizing specialist”, as a good way to steer my time. It focuses on a broad set of basic skills, with expertise in at least one.

    If a “Full stack developer” skill graph looks like: —
    And a “Software developer” skill graph looks like: |
    Then the “generalizing specialist” skill graph looks like: ⊥

    It’s a nice middle ground that admits that it’s important to know enough skills to make progress on basic tasks and ask informed questions to experts, but perhaps not something you want to dedicate your life towards. It’s also important to be that expert, so your teammates with basic knowledge can use you as a resource.

    In practice, let’s say I am a developer who enjoys working in the AWS cloud environment, and I wish to gain expertise in it. My study pattern might look like:

    AWS articles
    Python
    AWS Certification #1
    networking
    AWS POCs
    testing strategies
    AWS Whitepapers
    database performance
    AWS Certification #2
    etc.

    This concept can work for any skill and time scale. Perhaps I have a career as a server-side Java developer working with AWS. It’s not an unreasonable idea to transition to a client-side Node developer working with AWS, or an Ops engineer working with AWS, etc. You say you are a “master of none” but as a thought experiment, what are the common threads holding your 20+ year career together? Are you the “go to guy” for anything, even as a self-identified generalist?

    • I tend to be the go-to guy for a lot of different things. I’m able to quickly learn about something even if I’ve never seen it before. It takes me a short amount of time to understand a language or tool, understand a problem someone is facing, and find a solution.

      I’m specialized in relational databases and raw web technologies. The funny thing about that is that I don’t get to use either of them much anymore. The web has been abstracted away quite a bit with frameworks and tools. Databases have mostly become warehouses where people ship their denormalized blobs of data. Your mileage will vary, the environment you’re working within can be drastically different depending on the project.

      Fundamentals are where I focus all of my learning nowadays. It’s all about design patterns, domain-driven design, and looking at every tool as just that. It’s a means to an end and not the end all be all.

Leave a comment