What's best choice career-wise, to know a little about a lot or a lot about a little?

Question

I work as a developer at a rather small company and we are providing a web application that is used by a big base of customers. Because we are so small everyone have to be able to do a lot of different tasks. It ranges from advanced support, developing the product (programming: c/c++, c#, php, sql, javascript, html, css), handle network configuration and network related issues and even sometimes go on sales meetings with potential customers.

My concern is that I don't really specialize in any specific area. I know and learn little about a lot. I have graduated from school two years ago and this is my first real employment and when I look at other positions out there they always require so and so many years of experience in a specific area (for example 5 years of C#). For me to get that kind of specialized experience will be really hard at my current job.

My question for you is what is, in your opinion, best choice career-wise, to know a little about a lot or a lot about a little? What path did you take? pros and cons that comes with that choice.

Answer 1

I would ensure that there are some subjects that you know a lot about. Why ? Because this demonstrates that you're capable of gaining and working with this much knowledge, and that you can comfortably operate as an expert in particular fields.

You can then supplement that with the subjects that you know a little about, but the fact that you're aware of these means that you can extend your knowledge in the future if required.

This has worked well for me in the past. I can demonstrate a lot of Java knowledge, and I'm happy to supplement that with a little knowledge in other areas (some subjects I knew a long time ago and have forgotten over the years). But I can point to my in-depth Java skills and clients can then reason that I should be able to extend my skills with the same depth to other areas.

Correspondingly, I'm wary of hiring people who have a wide range of skills without much in-depth knowledge. Why is that ? Do they not have the skills to drill-down deep ? I'm also suspicious of hiring those with one core skill and no supporting technologies. Do they not want to learn other stuff ? Are they going to solve every problem using the same technology ? You need a toolbox to do your work, and I'm happy that people will use some tools a lot more than others. It's just having those other tools to hand that will make the difference.

Answer 2

Neither. Take the middle ground: it's much better to specialize in a range of appropriate technologies and tools, while dabbling a bit in other technologies every so often so that you can stay aware of trends. This approach has a number of unique advantages:

• You're usually using a few related technologies together anyway. Usually the set you should specialize in will be some related technology stack -- for instance, {C#, ASP.NET MVC, NUnit, Selenium, SQL Server, TFS} might be one set, while {Ruby, Rails, Cucumber, MySQL, Subversion} might be another. Since you'll be using them together anyway, you may as well learn more about them.

• Insulation from economic vagaries. You're much less likely to be left out in the cold if economic trends shift away from one or two of the choices in your stack. For example, the odds that people may abandon SQL Server in droves are probably not very high, but they're there. But the odds that they'll also abandon C#, ASP.NET MVC, NUnit, and Selenium -- all at once -- are extremely remote. You're well-shielded from fluctuations in the popularity of various technologies.

• Need deep knowledge in more than one or two things to be an effective developer. You need deep knowledge in a set of related technologies to understand and use them most effectively, not just a little bit of knowledge about each one or deep knowledge in one or two. Knowing a little bit about each technology will limit the complexity of the situations you can use the stack on. Conversely, specializing in only one or two of them will leave you floundering when you try to put all the pieces together.

• You stay aware of evolving trends. By specializing in a stack and continuing to dabble, you can swap out elements of your stack with newer, better technologies as they come along. For instance, you might observe that Git seems to increase your productivity more than Subversion does, so you could replace Subversion with Git in the latter group.

• Can assemble new stacks to make the right tool for the job. As you learn new technologies, you can develop entirely new unconventional stacks that may confer specific advantages to your project. For instance, you could mix technologies from the above examples to form a {C#, ASP.NET MVC, Cucumber, MySQL, Git} stack.

Answer 3

little about a lot

You will be part of huge flock already there and knowing little know won't help much and you may feel uncomfortable being part of that flock.

In fact you should know a lot about alot. This is what most developers are like.

lot about a little

If that little has demand, you will be paid highly but you will struggle to find a job in the first place because little is little. In our country Java, Mobile develpoment and C++ is pretty less but anyone having lot know about them are highly paid once they get a job (rarely because it is little here).

Suggestion:

You do have to be a lot in any particular tech/language to claim authority at least in that. Knowing little about everything should not be much gain and with the passage of time, all developers automatically know little about a lot other than what they are adept in.