Specialist or Generalist?
Developers tend to be curious persons, and it is quite common to struggle with the thought that should you narrow down learning to a particular niche. In this blog post, I'll share some ideas how to think the classic divide between specialists and generalists differently. The blog post a bit longer version of an email that I sent to How To Get Started As a Freelancer -email list. The content applies to freelancers and employees.
Why do we get the feeling to specialize?
At the beginning of the software development career, everything is new and shiny. For the new developer in the industry, it doesn't matter what technologies are used in the project as the developer is creating something more meaningful than school projects. In a smaller company, being just a developer isn't always an option, and the developer has to learn how to do support, project commissioning, talk with the clients, etc.
I think the initial thought of specializing comes after the first job. If the developer has done, for example, C# in the first job, should him/her continue on that path? Especially, in the job interview when going through an extensive list of things you have done lately, you get the feeling being average on everything you do. Would it be great to know "everything" about particular technology/subset of a field?
"Jack of all trades, master of none" describes the feeling of being average. The same idea can be found from many cultures and Hungarian take on the wisdom is quite easy to imagine: "You can't ride two horses (at the same time) since you only have one ass."
It is possible to do it, but notice that the horses are connected to each other, same should apply to your skills also.
Original video of Indian stuntmen
A full-stack developer is a job title where skillsets are well-connected. One developer could implement a feature without waiting for a backend developer to implement required changes. There are limits what full-stack developer can do, but those limits are relatively rarely met on regular web-projects where userbase is small, and most of the development is creating Crud for an entity.
But being an average developer, for example, on Java and C# instead of shining on one, isn't usually beneficial as there aren't that many projects that would mix those two. Many StackOverflow users probably think, "Wait, Jon Skeet is excellent in both C# and Java, and he is doing alright?" Correct me if I am wrong, but even Chuck Norris of programming is writing only one of those at the day job. C# is like hobby taken to the extreme (wrote a book, given talks + SO fame).
If you have a diverse set of skills, should you forget most of the skills and focus on one or two?
Perhaps there is an another way
In this chapter, the term job title is used to describe what you offer, whether it is a freelancer selling services or an employee thinking about a career.
If you think about new job titles, such as UX designer, UX developer, data engineers, CX Manager (Customer experience manager) DevOps Engineer, growth hacker, etc. they are all job titles that combine multiple disciplines.
Having a shorter introduction phrase gives you more credibility than a long-winded collection of things you have done lately.
When a fellow developer asks from you at a meetup: "what kind of work do you do?"
"I am a DevOps guy at a bank."
VS
"I have done a bit of software development, setup infrastructures, quality assurance, helped to create automated build and deployment systems and I am a good communicator."
It is easy to forget that everything cannot be packed into a compelling and compact description, for example, in a small town close to my area, there is an electrician who is also a personal trainer. The electrician/personal trainer has a web-site where he offers both services. No one takes seriously an electrician who doesn't focus on his craft and vice-versa with the personal training offering.
I have associated my expertise to term full-stack developer, but lately, I have been thinking about how vague it is; it doesn't tell much what you can do. Backend could include machine learning, data mining, integration with hardware, etc. and I don't have expertise in those areas and to be honest, no time to learn those either. Keeping up with the Web development is more than enough.
What I did was that I went through projects that I had done and searched for patterns like technologies, business domains, web/desktop/embedded, etc.
I noticed that I had delivered value and also enjoyed the business side of things when working with SaaS companies. Of course, I don't have to discard all other projects like internal tools from CV/Resume, but I tend to highlight SaaS clients and when looking for potential customers then I use SaaS as criteria.
When I approach a potential client, I summarize my expertise to one sentence: "I help to build successful SaaS products."
In the freelancing world, the job title means a bit more that when you're an employee because it is part of your introduction when talking with a potential client. The job title is a mental model that helps to decide which projects to take and what projects should be highlighted to emphasize the message of what I do.
The discussion doesn't end on the opening line, and the next question will be how are you going to help to build successful SaaS product. That's when the generalist approach will benefit you as a success of the SaaS product is rarely about one particular ingredient.
Conclusion
I think you can pack a broad expertise in a neat package that is easy to sell. You might have to drop few unrelated things to make it work. New jobs and titles are created based on the demand, and it is hardly ever something entirely new. For example, a doctor can focus on certain kind patients or diseases on studies and career. At some point, the field is officially approved by the industry, and the pioneer doctor is recognized expert in this area. In IT, this process is happening in a shorter timespan and more unofficially, but the idea is same.