I am currently employed in a technology-centric small-sized company. Due to the structure of the company and number of employees, I am usually pulled between different projects which involve different programming languages, technologies etc.

As this is my first job, I find that this prevents me from digging deeper into a particular language or technology and becoming an expert at it. Indeed, observing my co-workers, I see that even those who have been at the company for several years, fail to be experts in any particular area; rather they generally score about 3/10 at most of the tools they use.

How common is this state of affairs? How can I improve my situation? Is it time to look for something else?

  • 12
    Just a note - the goal of software companies is to make profitable or functional software, not become experts. It is not necessarily a requirement that both happen simultaneously.
    – enderland
    Commented Nov 8, 2012 at 15:44
  • 2
    @enderland while what you say is true, I would bet that you'll hardly find a profitable and functional software company whose developers don't have domains of expertise...
    – Intuit
    Commented Nov 9, 2012 at 1:59
  • 1
    I guess you need to define better what an "expert" really means. How does one even "score" a 3/10 anyway? Is that the result of a quiz-- which quiz? The point of work is to do what the job requires, not become a tool expert.
    – teego1967
    Commented Apr 30, 2014 at 13:47
  • 2
    Is a formal definition of expert really necessary for the point of the question to be clear? By "score 3/10", I mean that if I was asked "How would you rate your co-worker's Java skills?" I would reply "I'd give him a 3 out of 10"; not a scientific measure just a layman's estimate. "The point of work is to do what the job requires" but let's not forget that for many tasks a "tool expert" will do a much better job.
    – Intuit
    Commented Apr 30, 2014 at 13:54
  • 4
    I would say your expectation to become an expert in one language is a fool's errand. The industry is too fluid to devote to one language. Learn fundamentals, learn them well. Focus on data structures and algorithm design and be able to apply them to any language you use. Being a strong language agnostic developer so you have the confidence to pick up a project in any language. It will separate you from the 'script kiddies'. You'll go much further than having some esoteric knowledge in one area. Unless you're building compilers or an OS, breadth is better than depth. (IMO)
    – Bmo
    Commented May 1, 2014 at 11:25

6 Answers 6


I think this is fairly common at many companies, especially smaller ones where most employers, developers included, must juggle many balls at the same time. Only in larger developer teams and/or longer term projects can you really dig consistently deeper into a specific subject or area.

However, this situation has its good sides too: it exposes you to lots of different tools and technologies, widening your experience and skill set. This teaches you to pick up new subjects easier and faster, which may give you a distinct advantage in the future when looking for a new job. So embrace these opportunities and strive to get the most out of them.

Digging deeper into a technology / tool and becoming an expert of it (above what is explicitly required to do your current job) is not specifically supported by most companies, because - from the short sighted economical point of view - they may not see any direct benefit of it, OTOH it may increase the risk of you leaving them for a better job. (Of course, the rare top-level companies know very well that actively supporting you to increase your competence will bring them better, higher quality, more efficient solutions in the future, and increase your job satisfaction too, making it more likely that you stay with them - this is what makes them top level, after all :-)

However, alas, most companies are not quite there. Note though that this depends on you much more than on your employer. If you make a conscious effort to push yourself further in one or more favourite areas, allocating a part of your free time to experiment, study, and/or work on open source / pet projects, you are on your way to become an expert. You may also want to raise the subject with your manager, to discuss how the company may be able to support your education efforts better. In the best case, they may pick you more interesting / challenging projects, send you to some training or conference. In the worst case, your manager may not be able to help you, but at least (s)he is aware of your efforts, which may be a plus for you when it comes to e.g. salary negotiations :-)

  • 1
    +1 for acknowledging that increasing the competence of employees is essential to the company's success.
    – Intuit
    Commented Nov 9, 2012 at 2:10

I agree with everything Peter said before me. I would almost go as far as saying that being average or slightly above average in lots of fields/technologies is better than specializing in just one and being near clueless in the rest because the feasibility of specialization assumes the division of labor, and a successful division of labor, i should say, in which you do one thing very well but then the terrible pitfall of it is that it makes you dependent on the rest of the machine, AKA system, for everything else. Now that can all work out if the system is in place but what happens once it starts falling apart? Your risk will be significantly hedged if you can do many different things, albeit not so well as one specialty.

Adam Smith argued the same thing pointing to the great dangers of the division of labor. Frederick Taylor disagreed. Personally, between being a guru in one isolated technology and being mediocre in many but overall far more independent, going as far as growing my own food, prepping etc., I'd pick the latter. You always want to depend less on others and rely more on yourself.

So I would not be looking at your situation as particularly unfavorable. You can build a comprehensive, full-cycle portfolio of technical credentials. E.g. be a self-reliant LAMP stack developer and admin all in one, capable of dishing out a complete solution without any help from anyone else.

  • 3
    +1 for pointing out the benefits of an "all-in-one" person. While this starts to break down as the company grows (and therefore, requires more specialized knowledge for high-end scaling purposes), being a "full-cycle" asset is a boon to small companies.
    – Shauna
    Commented Nov 8, 2012 at 20:42

This sounds completely normal to me. If you are a part of a smaller engineering team, your responsibilities are greater then that of a engineer in a team of hundreds or thousands. Every day I am switching between different languages myself, I improve and learn on my personal time and occasionally during down periods I am allowed to use work time to learn. My employer also offers each employee a personal development budget once a year (that is quite substantial). Although I am aware many don't have such a luxury where they work or even know of such programs.

This is the norm I am afraid. It's sort of a misconception that there are developers out there only working with one language, especially if you work with the web. It's not uncommon for a modern day web developer to know all aspects of front-end, but also multiple back-end languages, databases and server administration.

I would definitely bring this up in your next review and I encourage everyone else to do the same. Speak with your manager or boss about wanting to advance your skills in the form of extra study, new software or even just getting a couple of hours per week to experiment and learn something new.


This is very common. There aren't many places that just stick to the one language, the software/web landscape is constantly evolving and we're all expected to be good at many things instead of great at one or two things. At times it can suck, but the world keeps on advancing and we have to move fast to stay on top of it all.


Learning a bit from multiple tools is also a specialization, and people doing so are experts at using multiple tools. It's also a very valuable specialization: instead of mastering a single language you're able to choose the language/tools that fits the task the most, and assemble a working solution from multiple tools, each one doing it's part the best.

Consider an example of a web system that need to import some data from other systems on a daily basis:

  • Java expert would insint on using SOAP web services to import data, triggered by quartz threads running on some application server. The 'stupid DB tasks' would be at best done with Hibernate (slower? - buy more machines and do JBoss clustering). The web layer would be some JSF.
  • Oracle expert would love to do the import in stored procedures, and the web layer in oracle forms or similar. The queries will be light-speed, but the other things would require extra power - no problem, Oracle cluster too, yeah, licence costs a heck but it runs like a dream
  • Multi-tool expert would make a simple MySQL DB schema, download the external files with shell script run by CRON, convert the format and import to DB with Python or Perl script, the web layer will be PHP with jQuery as client frontend. Everything will run probably on single PC.

In reality, you'll need multiple experts to write a single application. Each of them will do their part. Multi-tool experts don't go so deep with every of the technology, but they are able to do every job in the development. Both have pros and cons, it just depends on the situation.

Narrow experts are often very good payed (just because it takes at least 5 years to reach their level) but they also fall from sky very rapidly, if the technologies change. I've know an ex-C-expert, which was extremally good paid, and then has problems finding any job, because his primary speciality were the C UI libraries, which are no longer used, and he actually couldn't do anything else, so he had to learn from scratch - degraded from top-expert to a junior.


Many skills you develop as a software engineer are not tied to any specific language (encapsulation, do not repeat yourself, etc). So, one might not become a Java guru by using Java together with many other languages, but one can become a very good software engineer. For some companies, knowing every nook and cranny of Java might be very important. However, many companies do not care about those nooks and crannies and value a very good software engineer who is flexible in their tools.

Working on many languages makes you better as a software engineer. Especially languages that use a very different paradigm (e.g. functional vs object oriented) can really broaden your vision. In addition, it enables you to pick the correct tool for the situation at hand. In some situations, Python is a good match, while C++ would shine in another.

In conclusion, working on many different languages does not make you a guru in a specific language, but still makes you a good software engineer. Of course, you one can also become a bad software engineer by only using one language, or many.


I'll just add that the degree to which you can become an Authority in a specific area varies over your career, depending on what your employer needs to be able to speak with authority upon or influence for business purposes.

I was lucky enough to be prototyping an XML Document Object Model at a time when IBM was just starting to get interested in XML; that led to my spending several years working with the W3C on that design, helping to keep it as open and general as possible while also being fairly easy to implement and thus helping to make XML more widely useful and available. I then spent several years helping to develop and support IBM's XSLT processor, leveraging my XML knowledge.

But it's also a matter of what you invest your own time in, off the job. IBM and Apache might not have had an XSLT processor -- certainly not that quickly -- if Scott hadn't spent a week home with the flu entertaining himself by throwing together the first prototype of what became LotusXSL, which eventually became Apache Xalan and IBM XSLT4J/XSLT4C.

If you want to be an expert, don't wait for the company. Pick an area that you think the company is going to need and lead the way, on your on time if necessary. You may not convince them to follow you, but it's more likely to happen that way than if you wait for them to discover the need; among other things, by that time someone else is likely to be positioned to grab that role.

Not the answer you're looking for? Browse other questions tagged .