DEV Community

Hannah Masila
Hannah Masila

Posted on

When do you become a Jack of all trades but a master of none?

I have been learning and learning new languages every now and then. Yes, I have the basic knowledge of all these languages. My question is, am I slowly becoming a Jack of all trades but a master of none?

Top comments (33)

Collapse
 
ben profile image
Ben Halpern

I have this fear sometimes. I am not a real expert in any technology, but I have a decent grasp of many. Over time, I have developed more of an expertise around browser networking, if I were to pick anything, but I'm still no expert there.

Over time, I think the goal should be to develop a "t-shaped expertise", that is, that you have a broad array of skills, but some certain area has become your greatest expertise.

I personally am more than happy to hire "generalists" as long as I think they are good learners and could develop an expertise if the situation calls for it. Anyone who is too strictly focused on one specific language or environment might be too rigid to shift when the shift needs to happen.

Collapse
 
lepinekong profile image
lepinekong

I have recruited mostly generalists in the past but with a programming twist they are capable of taking a more holistic approach to a problem instead of just I have to do a piece of code that compiles and pass unit tests.

Collapse
 
thomasjunkos profile image
Thomas Junkツ • Edited

The underlying question is: What is the basis people bring with them and are you - as an employer - able to work with them.

The notion of "generalist" or "specialist" is bias laden in one way or the other. And if you take the dimensions of our industry, we are all at some point "specialist": tied to only a subsection of our field.

What is missing in the figure: the area of requirements, which mostly overlaps the generalist as well as the specialist.

The gaps of knowledge are uninteresting. Interesting is: "Are they willing to fill the gaps"?

Collapse
 
k2t0f12d profile image
Bryan Baldwin • Edited

There is always a need for generalists. People who would otherwise identify as strictly focused on one specific thing are also really generalists, because they have had to adopt other skills to drive their specialization. Whether your workplace can subsist solely on generalists depends on how important and technical your work is.

You can tell this in a team where the core of the team, even just one key person, lives in a very narrow band of language|environment|technology. Not because they are too rigid to shift, but because they work at the very edge of what technology can provide, whether that is performance or reliability.

Most languages|environment|technologies can do neither. If you aren't very concerned about getting the most, while taking the least, out of the hardware you are running on, your work isn't that technical. If you don't have to assure bulletproof reliability because there is a reasonable belief that downtime wouldn't put anyone's life and limb in jeopardy, it probably isn't that important.

But if there are people already doing both, why aren't we building on that expertise instead of enervating the industry with rubbish fad tech?

Collapse
 
krissiegel profile image
Kris Siegel • Edited

The "Jack of all trades but a master of none" phrase is a misnomer. It's bullshit.

Originally "Jack" or "Jack of all trades" was used as a saying for someone who was a generalist. Someone who didn't have expert level knowledge of thing things but lots of general knowledge of multiple topics. The "master of none" was later added just to turn it into an insult. So the first thing here is to drop the "master of none" as it serves no purpose but to be insulting to yourself.

Having said that, here's the rub: a "Jack of all trades" doesn't specify a depth of knowledge for each "trade" it references. Software development is incredibly complex and almost no one has what I would consider "full depth" on a topic. There are just too many abstractions. So what you may consider shallow enough to be a generalist, someone else may consider deep enough to be a specialist in a specific topic. It's a vague phrase attempting to be applied to an area of immense complexity.

It just doesn't work.

Something else to consider is a "Jack of all trades" likely knows enough to be a Master or Expert at picking the correct tool or at integration whereas someone who is, say, an Expert in JavaScript may want to use JavaScript for every single job even when it's inappropriate / not a good fit.

Collapse
 
maryannepeters profile image
Macpeters

There's also something to be said for new perspectives - every language/technology I've picked up has taught me things that apply to all of them. The quirks of each can shift your perspective enough to make something clear that was previously foggy. Even after I abandon something that's no longer relevant (cough...actionscript) - I know I got something out of learning it.

Collapse
 
feoh profile image
Christopher Patti

You can pick at the author's choice of phrasing, but there is a real danger to anyone's career that he's speaking to.

I did this for most of my early career - focusing on one shiny thing after another, never really developing any depth in any one topic. This way lies madness, because you'll look up after a great many years and think "What have I actually accomplished?"

Collapse
 
humzakhan profile image
Humza K. • Edited

Depends on how one perceive things. For some people, it might be a win-win situation for working over a large number of technologies while others may think of it as a hold back to their careers.

Collapse
 
nyehs profile image
Emma

It's entirely possible. Sometimes I don't even feel like a Jack of all trades. I feel like because I've worked with so many different languages and only created 1 or 2 projects in them, I barely know anything about programming at all.

I hail myself as being a Java developer, but I don't remember the last time I wrote anything in Java.

I do however think it's possible to become a mixture of both. You can know one or two languages very well but also be flexible to create projects in languages you don't use often.

Collapse
 
jjude profile image
Joseph Jude

This is a question I have struggled with in the early part of my career. Coincidentally, this is the exact question I have been discussing in a blog series. I'm linking to these posts at the end. Read them (and watch the videos) for details. Here is the summary:

  • In the early part of the career, do as many things as possible. This way you will know what you like and what comes naturally to you. This includes languages like go, swift, node etc, but also other business functions like marketing, business analysis.
  • Once you nail few areas, go deep into them. Build your expertise.
  • Know that you don't have to know everything and that too not now. We take about 5 - 6 years to master a skill. So you can build your career in a layered fashion.

If you follow this pattern, then you become a T-shaped expert as Ben says. The top guys in the military are known as "generals".

Like every advice, this advice is contextual.

If you need more details, read these posts:
Should you specialize or generalize? What Jack Ma & Derek Sivers says about this: jjude.com/specialize-or-generalize/
The curse of everything and now: jjude.com/all-and-now/
You got 11 lives. Live to master 11 areas: jjude.com/11-lives/

Collapse
 
homberocom profile image
Andrew

I like most of these points, however for accuracy "marketing, business analysis" are not developer roles.

Collapse
 
jjude profile image
Joseph Jude

Right Andrew. But when you come up in career (even as a developer), these skills (marketing, especially) help you accelerate your career.

Collapse
 
ivanovyordan profile image
Yordan Ivanov

There is a great book called "The pragmatic programmer" by Andrew Hunt and David Thomas. In this book they say we need to learn at least one new language every year. Learning new programming languages helps us broaden our thinking. In general learning is not a bad thing. It's something good.

Collapse
 
nitya profile image
Nitya Narasimhan, Ph.D

I chanced to read this thread and it resonated deeply. This has been an issue that has dogged my entire technical life (well over a decade) in the software industry.

When I first started in the space, I definitely felt that depth was better than breadth. Better to be really really good at one thing than to know a lot of things. So I got a PhD (in distributed systems & reliability engineering) and my first job in that domain. I worked in it for all of 10 months - then got an opportunity to work on a new project in mobile. I knew nothing about anything in that space, but I was younger and more fearless I guess because I jumped in without worrying about it.

It changed my life and I never worked in the area of my PhD expertise again.

Instead I have since worked on multiple projects (large and small), in different domains, with different stacks, languages and devices. And had to pick up new ideas, tools and technologies along the way constantly. And my takeaway was this. It was not the topic of my PhD that helped me -- it was the capacity it gave me to look at a problem, explore it from different angles and try to innovate solutions by using a wide variety of tools from analogies to trial-and-error to multi-disciplinary collaborations.

So my answer to you is: It depends on YOU. On how you approach the whole idea of learning and applying what you learn. And what your GOAL is when you pick up a new language to learn.

Don't learn for the sake of learning. And don't simply chase after every cool language or technology. Definitely spend an hour reading and absorbing the details but after that ask yourself what your goal is. Then set aside the right amount of time and plan the effort out so that the task itself goes from "just something I did for fun" to "this is what I learnt from doing X and now I can apply it to doing Y later"

In my case, I try to do one of three things for every new language/technology I learn

  1. I spend just an hour or two, understand it, then think about where I would apply it. Then file that away in my head and move on. It comes in handy when having discussions with others or in seeing patterns in other contexts.

    1. I spend a few weeks on it. I build something concrete with it (side project or hack) and see if it lives up to my expectations. If it does, then I try to do a talk on it. (I am trying to start blogging regularly but I do love interactive discussion better). At this point my goal is to share knowledge and learn something new in the process. It also solidifies my basic understanding and gets me out of "beginner" mode.
    2. I spend a few months on it. I build something for a client, or I build layers to a side project. And I get a real sense for how it could fit into some bigger project or platform. I look to collaborate with others who might need that piece or might be able to fill other pieces that I need to make that project come to life. And at that time, it has become a new tool in my coding tool-belt that I can pull out and use for future needs.

Hope that helped :-)

Collapse
 
humzakhan profile image
Humza K.

Perfect! Thanks for sharing :)

Collapse
 
rrackiewicz profile image
rrackiewicz • Edited

I find that generalist and specialist are the wrong axes to measure. Each is problematic. When it comes to developers I like to compare those with a deep understanding of computer science, who can pick up any language as they see fit vs. those who learn enough coding, algorithms, and data structures to pass a job interview. The later can be effective when the waters are calm, but when the storm hits (and it always does), I'll take the former every time. Scientists vs. opportunists.

Collapse
 
annarankin profile image
Anna Rankin

I think you're building up a skill in addition to these languages - the skill it takes to fearlessly pick up a new language! It can feel like you're not mastering any one particular thing, but I find that's hard to do until you have a real reason to solve a specific problem with a specific language. If you've got basic programming knowledge in a variety of languages, you've probably got a good grasp of the abstract concepts - possibly better than if you'd stayed with just one.

Still, it's a good idea to keep an eye out for situations where you can deepen your knowledge and mastery in an area you're interested in. Try solving new problems, or implementing design patterns, rather than solving the same problems in a new language.

Collapse
 
gregorgonzalez profile image
Gregor Gonzalez

Everything is relative. I believe that starting on a new language It's the most difficult part. It's really great if you already achieved that part and with the basics you can continue to any path.

Complex programs requiere a base knowledge and complex algorithms are made of multiple basic algorithm.

I like to learn new things, I'm stuck on PHP because my work. Here sometimes you find experts that doenst know how to make a simple html form and others newbies that can do almost anything with a good guide.

Keep it simple.

Collapse
 
elpibeperez profile image
Eduardo • Edited

I think that there are two diferent things here. If all you do when you code is learn how to create a hello world in
each language, then you are screwed. But if you as a developer put some effort in becoming a better programmer, and think in coding clearer and better, then those concepts Will follow you no matter what paradygm or language you use. I am a tech lead un nodejs and I can't remember if the length of a string is a method or a property. Stackoverflow is there for solving formal stuff. But when I make a code review, I analyze if things are named correctly. If the architectonic patterns are followed. If refactoring is needed and sutch. You must distinwish wich things of a language are just formal concepts and which concepts will make your code more readable and mantainable. After all, the most important role as a developer is create a piece of software that can be understood, replaced or modified by anyonoe. Because requirentes will change and programmers will change. Those are the only certenties