This essay focuses only on expanding knowledge within programming and business, but I think to truly be successful, you need to generalize outside of programming too.
My favorite example that I like to repeat often is that as a Site Reliability Engineer, more than once my knowledge of sports, entertainment, politics and current events have been quite relevant to my job.
When we were trying to figure out why people suddenly stopped watching Netflix in Mexico and Brazil, it was important to know that there was an exhibition match in Soccer/Football between the two countries, and knowing that that was culturally important and something that they would be using the TV for instead of Netflix.
Good point. It helps to be well-rounded in general, not just in technology.
To be fair, if you work for Netflix, entertainment is part of your business domain. One of the things the article highlights is the importance of knowing the business domain for your customers/clients.
> To be fair, if you work for Netflix, entertainment is part of your business domain.
That's true. But politics isn't really part of that, but came in handy (knowing when the President was making a big speech or another country was having an election or debate, for example).
> But politics isn't really part of [entertainment]
That's a very naive view of politics :) -- if you think I'm just being a smartass: Reagan, Berlusconi, Trump, Schwarzenegger, Trudeau, Paquiao, Blair... the list of politicians who were entertainers before getting into politics is huge and getting longer (and more popular) by the day.
That only became true when politicians started appearing on TV. They even touch on this in Back to the Future. When the only thing people knew of politicians was via printed word, and later radio, no one cared what they looked like.
That is the exact concepts I was going for. I had never heard that terminology until I read your link. Thanks for the information. I still like the concept of a topo map because I believe that the skills nearest your specialty or more important than those that are further away. A T just indicates that you have a specialty and the your have broad knowledge.
I agree with this advice, and especially the follow up comments about being well-rounded in general.
But one thing I hate is when a business or a manager tries to politicize this whole "t-shaped skills" buzzword, by arguing that importance of generalist skills entitles the business or manager to almost completely disregard someone's specialization.
If you hired someone as a machine learning expert, and instead you've got them working on a legacy Ruby on Rails codebase or going down some rabbit hole about containerization, then it's gone too far. Yet politically, this will be defended endlessly in the name of "team player" and "business bottom line" HR code words.
But specialization of labor is hugely important to society. We need people to be deep experts, and for the trend of getting deeper and deeper into a field to continue, and well-defined roles within an organization are important for this. And yes, this does require managers and planners to work very hard to actually understand the business's needs, so that they can hire a machine learning engineer when they need one, instead of hiring one, then trying to repurpose the engineer into a Rails engineer by appealing to "be a team player" nonsense.
Any way, I think it's just important that as good as generalization, well-roundedness, and basic curiosity are, developers and knowledge workers especially have to be really pedantic and adamant that businesses respect specializations. Don't let the politicization of "be a generalist" get used as an excuse for your employer to stop respecting your specialization.
This is a major reason why I dislike the trend of "full-stack" development. It's great when developers really do have full-stack skills. But it's a huge red flag about a company when they actually want, and encourage, people to work in an essentially purely generalist capacity. It can often mean the company is either trying to get by cheaply (i.e. they're happy with relatively lower quality work from a generalist working in a specific area that is not the generalist's specialization) instead of seeking higher quality solutions through the appropriate specialists, or else they are just not doing the hard work of actually mapping their business needs correctly onto the skills that different specialists have, meaning that "full-stack" is just a hiring buzzword to avoid hard work somewhere up the staffing foodchain, and build in plausible deniability when it doesn't work out (e.g. "But we hired full-stack people...").
Great points. One of the things that I tried to point out is that the breadth of your skills specifically supports your specialty. A company should appreciate your breadth of skills because it makes you better at your specialty.
I think there is a difference between hiring someone as a machine learning expert with the intent of having them work as a ROR maintainer and hiring the person and asking them later when an urgent need comes up. If you are a small company growing rapidly it is impossible to anticipate all future needs in advance. This means on occasion you get mismatched between skills and needs.
If this happens once or twice and gets resolved quickly, then sure it's OK. It can happen, and even if "team player" is often misused as a politicized HR code word, most of us developers still do want to be team players in the real sense, and so helping out is not a problem.
But if the issue lingers over time, either because the small company doesn't want to foot the bill to hire an appropriate specialist, or because the company tries to paper over the wrongness of the on-going situation by acting like this sort of "team player" working-outside-my-speciality-because-someone-claims-it's-urgent status is just "how start-ups work" or "that's just start-ups" or "everyone's got to wear many hats" or whatever other bullshit, then that's a huge red flag.
It means that not only did the company fail to plan for its needs (which should be some cause for concern, but not catastrophic since start-ups are hard), but even more, after learning that they didn't plan staffing correctly, instead of considering the deleterious burnout effects it might have on a specialist to force them to work way outside their area for prolonged times, the company just doubles down on it and even tries to build their company culture around it, as if "just do what you're told, no matter how hilariously far off it is from what we said you'd be doing" is a centerpiece of company culture, and indeed that somehow that's "just how it is" at any start-up.
So, even if there is no intentional deceit or planned bait-and-switch, it's still a big red flag if this happens a lot and/or doesn't get resolved quickly.
If you are a specialist, any employer who doesn't care enough about your specialty to be sensitive to the request to make you work way outside of it is really bad news for your career, unless you have other reasons for wanting to work there that, for you personally, supersede however much you value career progress in your chosen specialty.
At the very least, companies should be apologetic about this when it happens, and should really work to find a compromise that doesn't cause burnout or create big gaps of time on an employee's work history during which the employee is not gaining experience related to their actual career specialty. If managers can admit the situation is not ideal, and level with you about the business emergency causing it, that's somewhat better (though still not an excuse for it to linger on for a long time). But if the business can't be bothered to admit they are doing something really suboptimal, something specifically fucking with your career progress and ability to gain experience, then it's probably time to just move on to another job. The company's not showing you any loyalty at that point, but they are expecting a pretty extreme form of loyalty and trust on the engineer's part.
It is defiantly a problem if a company does not learn and adapt to changing needs. It is an inefficient use of resources and ultimately will lead to developer churn if allowed to continue.
Companies do have problem recruiting people to do the work that needs to get done verses the work developers want to do. Maintaining old code is not popular and getting good people to do this is hard. This is no excuse for engaging in bait-and-switch tactics though.
I think a lot of companies are shooting themselves in the foot in this respect. They bias themselves towards people with visible portfolios of greenfield work, then hire them to do maintenance. Not only does this select negatively for the type of person who would be good at maintenance, it also sends the signal that maintenance is a career dead-end.
I agree that there is a major issue between what companies say they want and what they actually reward people for. Be a team player and work on code maintenance, but when we promote or recruit we want a “rock star” who has 100 projects on GitHub.
I actually think it's really fun. Of course, my attraction to engineering has always been to figuring out how things work and making them better. Unfortunately, most maintenance is just ticket-punching. I love the kind of maintenance that is "find a way to speed up the critical path in X" or "find the source of the intermittent crash in Y" rather than "change every occurrence of FONT_COLOR='#239a11' to '#239a33'".
I take this even further. I think all maintenance should be framed by the business as:
>What ideas do you have about how the solutions to these specific bugs/tickets/requests can simultaneously improve the existing system, even in ways unrelated to the specifics of the bugs/tickets/requests. How can we give business priority to those ideas?
The difference is that if you challenge someone to not just meet a minimal set of criteria to "solve" a bug/ticket/request, but to use their wits to go further and not just solve it, but solve it in a way that creatively improves things around it too, then they'll be way more engaged. Almost all studies on this sort of thing have shown that you get higher quality work, people work faster in this set up, and they generally report feeling satisfied about it. This was a big part of the book Peopleware, where it talks about how in software at least, the notion that you have to trade-off speed of implementation against quality of implementation is a total myth -- just not borne out of any data measuring task completion time, degree of spec completeness, and bugs.
To me, things like Agile tend to get politicized in a company and then get misused, to the point where rote emphasis on minimally clearing tickets ruins any chance to let people be creative about how they solve maintenance issues.
And at the end of the day, even if you have great system architects, usually it is the maintenance developers who have really seen the nitty gritty of the codebase and have the most intuition about good refactoring design choices.
My mother says a specialist is someone who knows more and more about less and less until they know absolutely everything about nothing, and a generalist is someone who knows less and less about more and more until they know absolutely nothing about everything.
While these sayings are fun, and sort of true, they are kind of not useful. You should be a jack of various trades, a master of some. Specialization is for insects :)
Something I've learned from the Dreyfus Model of Skill Acquisition is that once you achieve expertise/mastery at a skill, it becomes much easier to learn other skills at the competent/proficient level. In other words, you learn how to learn, when what you're learning is hard and requires much effort.
Having achieved expertise/mastery at a couple of different things (software deployment, guitar playing, other things), I find all sorts of common patterns between these seemingly unrelated skills, patterns I can then reapply for other skills. For example, being an improvisational musician has made me keenly aware of the passage of time, and immutable deadlines - an awareness that helps me with every other skill that involves the passage of time.
There are many interesting ways that the Dreyfus Model of Skill Acquisition could be applied to the ideas in the blog post. There should be a few areas where you are an expert, a handful of things you should know at a proficient level, many things you should know at a competent level. You should be expanding the number of things in which you are an advanced beginner.
I also like what you said about your knowledge of music was useful to your programming skills. Being well-rounded individuals can make us better specialists.
I've been partial to Heinlein's idea of the "general specialist" lately:
"Computermen sent up to install Mike were on short-term bonus contracts— get job done fast before irreversible physiologlcal change marooned them four hundred thousand kilometers from home. But despite two training tours I was not gung-ho computerman; higher maths are beyond me. Not really electronics engineer, nor physicist. May not have been best micromachinist in Luna and certainly wasn’t cybernetics psychologist. But I knew more about all these than a specialist knows—I’m general specialist. Could relieve a cook and keep orders coming or field-repair your suit and get you back to airlock still breathing."
Similarly, another quote from him that always resonated with me:
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
You should be enough of a generalist to understand how your part fits into the whole. You also need to be enough of a specialist to do your part really, really well.
Also, get into several specialities as you move along on your career. I'm almost 40 years old, and can list quite a few specialities in my resume.
You'd never to go to a neurologist to get a ACL reconstruction. In other professions, specialization is seen more respectfully and also pretty vital. Whenever I interview with startups, I get a feeling they want "generalists" because they need to get the same amount of work without hiring a lot of people. I'd personally prefer specialists but are inquisitive enough to jump on random things and can move the boat without waiting for someone.
Another reason startups prefer generalists is that at the early stage, you don't know what specialists you may require. As a general rule, the later the stage of the company, the more specialists you will find. For example, you will find people at google whose only job is to make icons for a very specific screen. The same task at a startup may be done by the founder or really anyone who wants to take a stab at it.
One problem with this that many orgs face is that later down the road when your business has grown, now you need to hire a lot of specialists (usually in a big hurry), and in fact at that point hiring the new specialists often matters way, way more than continuing to take care of the generalists who got you to that point.
On one hand, if you defer to the market, you'll end up being forced to pay high wages to those later-on specialists, and probably also more equity than would otherwise be warranted for their time of entry to the firm. Lots of early-on generalists could get mad that they aren't paid well and that even if they have more equity, it's not fairly proportioned to how much up-front work they put in.
On the other hand, if you don't agree with this market problem, then you end up hiring only specialists who don't know how much they are worth, or else have other factors that make them cheaper to hire -- generally meaning you hire crappier later-on specialists to save money and to keep the equity proportions "fairer" to the early-on generalists. These firms often get a bad reputation for doing crappy work in the specialist area, and specialists stay away from it.
I see this a lot with machine learning. A smart machine learning specialist is not going to join a Bay Area start-up for $150k and 0.1% equity as employee number 40. If you waited until employee 40 to start investing in highly specialized machine learning talent, and it's something your business needs, then you're either going to have to raise the wage super high (much higher than the early-on employees who may resent this), or you're going to have to offer completely disproportional equity, or both; or else, you're going to have to hire inexperienced and/or crappy people who don't mind taking a job as employee #40 for that kind of "conventional start-up wisdom" pay/equity range.
To me, this suggests one hypothesis is that start-ups preferring generalists is actually a bad idea. Instead, they should excel at forecasting which specialists they'll need, then hire the best of that speciality very early on. To entice them to put up with generalist work for a while, pay them a lot or give them better than market equity, and be as flexible as possible with what kinds of working style / environment you offer them.
Then when the time comes to really turn up the heat on specialist labor, you'll already have the specialists, and they'll already know how the systems work. At that point, you can expand hiring on the generalist front, which should be relatively easier to do at the current start-up wage level, and have those later-on generalists take over the maintenance and generalist work from the early-on specialists.
This is way easier said than done, of course, but it would be interesting to see whether there's a relationship between start-ups that succeed and start-ups that choose to specialize early and generalize later. Most start-ups fail, and anecdotally, most start-ups also seem very inflexible about accommodating what an early-on specialist might want (like say, to avoid working in Agile or to work in a quiet office) and seem more geared toward hire pools of generalists (mandate team-wide Agile, have lots of social outings, use open-plan offices). Maybe this is a big part of going wrong?
Problem with that is most specialists suck or have very little interest in generalist work.
People became specialists because they particularly enjoy that kind of work. When you put them in an environment where things are changing rapidly, including their day to day nature of work, in my experience most specialists don't respond well to it.
I actually think hiring too many specialists is one of the biggest mistakes early stage startups can make.
I agree specialists will not be satisfied with just doing generalist work without any other offsetting compensation, but this is why I said you have to pay them well and be very flexible about work style and work environment. You're already selecting for specialists who were open enough to the idea of working at a start-up that they even applied at all. That self-selects for some things, and an open mind towards generalist work is probably part of it. But just because they are open to the idea of sacrificing time they could otherwise have spent gaining more specialist experience in order to do early-on generalist work for your start-up, that doesn't mean they'll do it cheaply or be willing to fit into cultural situations they don't feel compatible with.
It's hard for me to believe most start-ups can really say anything conclusive about the quality of early-on specialists, because so few start-ups are willing to be flexible with office layouts, introvert v. extrovert working styles, and many other things. If a start-up is simultaneously rigid about those types of things and also claiming they can't get a good early-on specialist, well it's no surprise why they can't.
For legitimately cash-strapped start-ups, I think your point would hold true. Even if they are very flexible, they just won't be able to afford a good early-on specialist at all, even such a specialist who is already sympathetic to start-up lifestyle and willing to trade some salary for flexibility on certain working conditions won't go for it.
The other factor to consider here is that not all specialists are focused on a technology. Some specialists focus on a process or a business domain. If a startup is working on financial software, finding someone that has a deep knowledge of finance software might be incredibly valuable. This could be very true if your software needs to meet regulatory requirements like Sarbanes Oxley.
I assumed the context here was developers. For other kind of specialists, they can be INSANELY valuable from the get-go. In fact, one of the first hires I'd recommend anyone doing enterprise startup is hiring a domain specialist. These people are relatively inexpensive and add tremendous value in giving product feedback between early iterations. They can also talk to early customers with more credibility and thus help adoption of certain features that the customer may other not see much value in.
Actually, I was talking about developers. In my experience working on projects that needed FDA part 11 compliance, it can be incredibly helpful to have developers that know how to write software that meets to compliance rules from process, validation, and auditability standpoints. I presume the same is true for SOX or HIPPA.
It's true that a neurologist wouldn't work on your knee, but to become a neurologist, you would have to study the knee in medical school. Even specialists need to have a proficient knowledge in other areas.
Think of your career as being a generalist, but learn things like a specialist.
You want the opportunity to work on a wide array of problems so you build a repertoire of solutions and insights that can be applied to various problems.
Being a full-stack engineer is a great place to start, but it's limiting because you never gain enough depth beyond plugging together front-end, back-end and off-the-shelf components.
Instead, you want to rotate between various roles so you can focus on different areas. This way you can understand the pitfalls and best practices of certain systems (like infrastructure, queues, machine learning, angular, etc).
Being a specialist/senior dev you can get up to 120-160k/year for languages like ruby, rails, go, java, js, .NET, c++, etc. You can give speeches, write books, etc.
As a 'generalist' you'll be between 60-80k at most, because everyone will hire you as a entry level programmer in their stack since you're not expert.
On the other hand, a "generalist" with a couple of really deep areas of expertise can be very valuable.
I like the T-shape model; able to help out in many areas, able to make significant contributions in a smaller number of areas. (I would add: And with a significant and continuing track record of growth in knowledge).
That's how I handle my contracting gigs. I'm not sure if generalist is the right term for what I do; polyglot might be more appropriate.
Every project I do, I'm typically brought in to accomplish something specific, which involves learning whatever that thing is down to the level where I can comfortably build and maintain a system. It's varied over the years: Django and Rails for web stuff (just recently Elixir and Phoenix), several different families of microcontrollers, C#, Java, C & C++, DSP work with software radios, OpenGL work (recently doing some intense linear algebra using shaders), etc, etc. I jokingly call myself a full-full-stack engineer: I can design circuit boards and write a web app to talk to them.
It's kind of a TTT model. I've got enough experience under my belt (and did both EE and CS in school) that there's a few areas that I'm quite excellent at, and I've written code in enough programming languages that picking up a new one for a project isn't really a big deal anymore.
Edit: Another thing that ends up happening when you get to a point like this is that ideas start inter-breeding. You have a client ask you about some mobile app that they've been thinking of, and you realize that there's a pretty straightforward image processing or DSP algorithm to do what they're asking about, as an example.
You'll definitely find specialists in python but they'll also be experts in specific frameworks or packages like Django/Pylons/Pyramid etc. I'd say the same thing goes for ruby...if you're a ruby expert it's almost explicit that you'll at least have an intermediate knowledge of rails.
Simply untrue. There are opportunities to join established teams of specialists looking for someone to bring it all together; perhaps to fill the role of someone senior who has moved on. Accomplished generalists are rare enough that one's starting salary should be more than competitive.
As a contractor or job hopper you're better off as a specialist for the reasons mentioned.
As a long term employee, a specialist gets stuck in one place and doesn't advance. A generalist moves around in the company, impressing people and getting raises, and helps with the valuable stuff like integrations and customer facing contacts.
The paradox is that if the specialist chooses correctly, they have a better shot at moving around outside their original company. No matter how my blog posts people write or discussions we have here, the vast majority of companies will still hire a one-trick pony over a generalist as long as that one trick is what they need at the moment. Hiring, like so much else in the corporate world, is far too short-sighted.
I agree that being a specialist is where the money is. What I was trying to show in the blog post was that the only way become a well-paid specialist is to improve your skills in the surrounding technologies. I doubt there are many developers making tons of money because they know Ruby really well. If there are making good money as a specialist, it is because the know a lot about a framework (probably rails), a communication protocol (HTTP), a design language (CSS), a plugin ecosystem (gems), and an editor. If you want to be a great specialist, you have to know the surrounding technologies as well.
A number of years ago, my team hired an experienced individual who was quite invaluable to our team despite the fact that their experience was in a different problem domain and a different technology stack. The reason they were still useful was because they had a good understanding of what we might call "systems management software". That is, if you need to write software to manage a set of heterogeneous systems distributed across a networked environment, this person had a lot to offer.
(Unfortunately management did not recognize this person's value to the rest of the team until they had already accepted a better job at another company, but that is a different story.)
It seems that there are three different ways one can "specialize": problem domain (e.g. business accounting), solution domain (e.g. "systems management software", "data science"), or tool-set (e.g. J2EE). Each form of specialization has its trade-offs, but it strikes me that tool-set specialization is particularly likely to get one stuck working on frustratingly complex legacy systems.
My attitude about specialization vs. generalization (that I think resonates with the OP) is not whether we should specialize, but when. To my mind, specialization is a necessity, and it does increase one's income, but it also incurs the risk that the specialization will become obsolete before you are ready to retire. When you look at risk-adjusted lifetime earnings[1], it seems to me that the most reasonable strategy is to delay specialization as long as possible.
As someone that specialized in Palm OS programming for a few years, I concur that there is a risk in picking the wrong specialty. But I did learn a lot in my days as a Palm OS dev. I earned the right to design and implement some really interesting solutions. I got to solve hard problems. I wouldn't have had those chances if I hadn't proven myself to be very good at what I was doing. On the other hand, my vast knowledge of the API of an obsolete OS isn't helping me much these days. I actually keep a copy of one of my Palm OS books as a reminder to never get to tied to one technology.
That's a good point. I might phrase it thusly: in order to build up expertise within a solution space (such as doing cool mobile device applications) you end up having to stick with a particular platform/tool-set long enough so that your knowledge of the platform isn't a barrier to solving complex problems.
It sounds to me like you more or less ended up doing the correct thing.
Another specialist/generalist vector I've encountered... at a lot of startups, they're looking for a "full stack developer" (generalist). Which is fine when staff is limited. But when you're a big company and you have a product that costs a thousand dollars a minute when it's offline and the database crashes, who do you want looking at the database... the girl who's lived and breathed nothing but Oracle for the past 15 years, or that full stack dude?
Short answer - between the two - specialize is superior.
If money matters to you - its easy to figure - hrs x price. Your price generally is higher if you specialize. Best thing is to be a rare bird - expert in something very valuable that few people can do.
You can eat good just doing basic web dev (for the time being at least), but if you're very ambitious - to really outperform - you'll want to be more special than that.
63 comments
[ 5.3 ms ] story [ 136 ms ] threadMy favorite example that I like to repeat often is that as a Site Reliability Engineer, more than once my knowledge of sports, entertainment, politics and current events have been quite relevant to my job.
When we were trying to figure out why people suddenly stopped watching Netflix in Mexico and Brazil, it was important to know that there was an exhibition match in Soccer/Football between the two countries, and knowing that that was culturally important and something that they would be using the TV for instead of Netflix.
To be fair, if you work for Netflix, entertainment is part of your business domain. One of the things the article highlights is the importance of knowing the business domain for your customers/clients.
That's true. But politics isn't really part of that, but came in handy (knowing when the President was making a big speech or another country was having an election or debate, for example).
That's a very naive view of politics :) -- if you think I'm just being a smartass: Reagan, Berlusconi, Trump, Schwarzenegger, Trudeau, Paquiao, Blair... the list of politicians who were entertainers before getting into politics is huge and getting longer (and more popular) by the day.
-Versatilist
-Generalizing Specialist
-Technical Craftsperson
-Renaissance Developer
-Master Generalist
But one thing I hate is when a business or a manager tries to politicize this whole "t-shaped skills" buzzword, by arguing that importance of generalist skills entitles the business or manager to almost completely disregard someone's specialization.
If you hired someone as a machine learning expert, and instead you've got them working on a legacy Ruby on Rails codebase or going down some rabbit hole about containerization, then it's gone too far. Yet politically, this will be defended endlessly in the name of "team player" and "business bottom line" HR code words.
But specialization of labor is hugely important to society. We need people to be deep experts, and for the trend of getting deeper and deeper into a field to continue, and well-defined roles within an organization are important for this. And yes, this does require managers and planners to work very hard to actually understand the business's needs, so that they can hire a machine learning engineer when they need one, instead of hiring one, then trying to repurpose the engineer into a Rails engineer by appealing to "be a team player" nonsense.
Any way, I think it's just important that as good as generalization, well-roundedness, and basic curiosity are, developers and knowledge workers especially have to be really pedantic and adamant that businesses respect specializations. Don't let the politicization of "be a generalist" get used as an excuse for your employer to stop respecting your specialization.
This is a major reason why I dislike the trend of "full-stack" development. It's great when developers really do have full-stack skills. But it's a huge red flag about a company when they actually want, and encourage, people to work in an essentially purely generalist capacity. It can often mean the company is either trying to get by cheaply (i.e. they're happy with relatively lower quality work from a generalist working in a specific area that is not the generalist's specialization) instead of seeking higher quality solutions through the appropriate specialists, or else they are just not doing the hard work of actually mapping their business needs correctly onto the skills that different specialists have, meaning that "full-stack" is just a hiring buzzword to avoid hard work somewhere up the staffing foodchain, and build in plausible deniability when it doesn't work out (e.g. "But we hired full-stack people...").
But if the issue lingers over time, either because the small company doesn't want to foot the bill to hire an appropriate specialist, or because the company tries to paper over the wrongness of the on-going situation by acting like this sort of "team player" working-outside-my-speciality-because-someone-claims-it's-urgent status is just "how start-ups work" or "that's just start-ups" or "everyone's got to wear many hats" or whatever other bullshit, then that's a huge red flag.
It means that not only did the company fail to plan for its needs (which should be some cause for concern, but not catastrophic since start-ups are hard), but even more, after learning that they didn't plan staffing correctly, instead of considering the deleterious burnout effects it might have on a specialist to force them to work way outside their area for prolonged times, the company just doubles down on it and even tries to build their company culture around it, as if "just do what you're told, no matter how hilariously far off it is from what we said you'd be doing" is a centerpiece of company culture, and indeed that somehow that's "just how it is" at any start-up.
So, even if there is no intentional deceit or planned bait-and-switch, it's still a big red flag if this happens a lot and/or doesn't get resolved quickly.
If you are a specialist, any employer who doesn't care enough about your specialty to be sensitive to the request to make you work way outside of it is really bad news for your career, unless you have other reasons for wanting to work there that, for you personally, supersede however much you value career progress in your chosen specialty.
At the very least, companies should be apologetic about this when it happens, and should really work to find a compromise that doesn't cause burnout or create big gaps of time on an employee's work history during which the employee is not gaining experience related to their actual career specialty. If managers can admit the situation is not ideal, and level with you about the business emergency causing it, that's somewhat better (though still not an excuse for it to linger on for a long time). But if the business can't be bothered to admit they are doing something really suboptimal, something specifically fucking with your career progress and ability to gain experience, then it's probably time to just move on to another job. The company's not showing you any loyalty at that point, but they are expecting a pretty extreme form of loyalty and trust on the engineer's part.
Companies do have problem recruiting people to do the work that needs to get done verses the work developers want to do. Maintaining old code is not popular and getting good people to do this is hard. This is no excuse for engaging in bait-and-switch tactics though.
I agree that there is a major issue between what companies say they want and what they actually reward people for. Be a team player and work on code maintenance, but when we promote or recruit we want a “rock star” who has 100 projects on GitHub.
I actually think it's really fun. Of course, my attraction to engineering has always been to figuring out how things work and making them better. Unfortunately, most maintenance is just ticket-punching. I love the kind of maintenance that is "find a way to speed up the critical path in X" or "find the source of the intermittent crash in Y" rather than "change every occurrence of FONT_COLOR='#239a11' to '#239a33'".
>What ideas do you have about how the solutions to these specific bugs/tickets/requests can simultaneously improve the existing system, even in ways unrelated to the specifics of the bugs/tickets/requests. How can we give business priority to those ideas?
The difference is that if you challenge someone to not just meet a minimal set of criteria to "solve" a bug/ticket/request, but to use their wits to go further and not just solve it, but solve it in a way that creatively improves things around it too, then they'll be way more engaged. Almost all studies on this sort of thing have shown that you get higher quality work, people work faster in this set up, and they generally report feeling satisfied about it. This was a big part of the book Peopleware, where it talks about how in software at least, the notion that you have to trade-off speed of implementation against quality of implementation is a total myth -- just not borne out of any data measuring task completion time, degree of spec completeness, and bugs.
To me, things like Agile tend to get politicized in a company and then get misused, to the point where rote emphasis on minimally clearing tickets ruins any chance to let people be creative about how they solve maintenance issues.
And at the end of the day, even if you have great system architects, usually it is the maintenance developers who have really seen the nitty gritty of the codebase and have the most intuition about good refactoring design choices.
Having achieved expertise/mastery at a couple of different things (software deployment, guitar playing, other things), I find all sorts of common patterns between these seemingly unrelated skills, patterns I can then reapply for other skills. For example, being an improvisational musician has made me keenly aware of the passage of time, and immutable deadlines - an awareness that helps me with every other skill that involves the passage of time.
I also like what you said about your knowledge of music was useful to your programming skills. Being well-rounded individuals can make us better specialists.
"Jack of all trades, master of none, though oftentimes better than master of one." https://en.wikipedia.org/wiki/Jack_of_all_trades,_master_of_...
Puts a different spin on it.
Gives it quite a different meaning.
"Computermen sent up to install Mike were on short-term bonus contracts— get job done fast before irreversible physiologlcal change marooned them four hundred thousand kilometers from home. But despite two training tours I was not gung-ho computerman; higher maths are beyond me. Not really electronics engineer, nor physicist. May not have been best micromachinist in Luna and certainly wasn’t cybernetics psychologist. But I knew more about all these than a specialist knows—I’m general specialist. Could relieve a cook and keep orders coming or field-repair your suit and get you back to airlock still breathing."
from The Moon is a Harsh Mistress
"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."
Also, get into several specialities as you move along on your career. I'm almost 40 years old, and can list quite a few specialities in my resume.
On one hand, if you defer to the market, you'll end up being forced to pay high wages to those later-on specialists, and probably also more equity than would otherwise be warranted for their time of entry to the firm. Lots of early-on generalists could get mad that they aren't paid well and that even if they have more equity, it's not fairly proportioned to how much up-front work they put in.
On the other hand, if you don't agree with this market problem, then you end up hiring only specialists who don't know how much they are worth, or else have other factors that make them cheaper to hire -- generally meaning you hire crappier later-on specialists to save money and to keep the equity proportions "fairer" to the early-on generalists. These firms often get a bad reputation for doing crappy work in the specialist area, and specialists stay away from it.
I see this a lot with machine learning. A smart machine learning specialist is not going to join a Bay Area start-up for $150k and 0.1% equity as employee number 40. If you waited until employee 40 to start investing in highly specialized machine learning talent, and it's something your business needs, then you're either going to have to raise the wage super high (much higher than the early-on employees who may resent this), or you're going to have to offer completely disproportional equity, or both; or else, you're going to have to hire inexperienced and/or crappy people who don't mind taking a job as employee #40 for that kind of "conventional start-up wisdom" pay/equity range.
To me, this suggests one hypothesis is that start-ups preferring generalists is actually a bad idea. Instead, they should excel at forecasting which specialists they'll need, then hire the best of that speciality very early on. To entice them to put up with generalist work for a while, pay them a lot or give them better than market equity, and be as flexible as possible with what kinds of working style / environment you offer them.
Then when the time comes to really turn up the heat on specialist labor, you'll already have the specialists, and they'll already know how the systems work. At that point, you can expand hiring on the generalist front, which should be relatively easier to do at the current start-up wage level, and have those later-on generalists take over the maintenance and generalist work from the early-on specialists.
This is way easier said than done, of course, but it would be interesting to see whether there's a relationship between start-ups that succeed and start-ups that choose to specialize early and generalize later. Most start-ups fail, and anecdotally, most start-ups also seem very inflexible about accommodating what an early-on specialist might want (like say, to avoid working in Agile or to work in a quiet office) and seem more geared toward hire pools of generalists (mandate team-wide Agile, have lots of social outings, use open-plan offices). Maybe this is a big part of going wrong?
People became specialists because they particularly enjoy that kind of work. When you put them in an environment where things are changing rapidly, including their day to day nature of work, in my experience most specialists don't respond well to it.
I actually think hiring too many specialists is one of the biggest mistakes early stage startups can make.
It's hard for me to believe most start-ups can really say anything conclusive about the quality of early-on specialists, because so few start-ups are willing to be flexible with office layouts, introvert v. extrovert working styles, and many other things. If a start-up is simultaneously rigid about those types of things and also claiming they can't get a good early-on specialist, well it's no surprise why they can't.
For legitimately cash-strapped start-ups, I think your point would hold true. Even if they are very flexible, they just won't be able to afford a good early-on specialist at all, even such a specialist who is already sympathetic to start-up lifestyle and willing to trade some salary for flexibility on certain working conditions won't go for it.
You want the opportunity to work on a wide array of problems so you build a repertoire of solutions and insights that can be applied to various problems.
Being a full-stack engineer is a great place to start, but it's limiting because you never gain enough depth beyond plugging together front-end, back-end and off-the-shelf components.
Instead, you want to rotate between various roles so you can focus on different areas. This way you can understand the pitfalls and best practices of certain systems (like infrastructure, queues, machine learning, angular, etc).
Being a specialist/senior dev you can get up to 120-160k/year for languages like ruby, rails, go, java, js, .NET, c++, etc. You can give speeches, write books, etc.
As a 'generalist' you'll be between 60-80k at most, because everyone will hire you as a entry level programmer in their stack since you're not expert.
I like the T-shape model; able to help out in many areas, able to make significant contributions in a smaller number of areas. (I would add: And with a significant and continuing track record of growth in knowledge).
Every project I do, I'm typically brought in to accomplish something specific, which involves learning whatever that thing is down to the level where I can comfortably build and maintain a system. It's varied over the years: Django and Rails for web stuff (just recently Elixir and Phoenix), several different families of microcontrollers, C#, Java, C & C++, DSP work with software radios, OpenGL work (recently doing some intense linear algebra using shaders), etc, etc. I jokingly call myself a full-full-stack engineer: I can design circuit boards and write a web app to talk to them.
It's kind of a TTT model. I've got enough experience under my belt (and did both EE and CS in school) that there's a few areas that I'm quite excellent at, and I've written code in enough programming languages that picking up a new one for a project isn't really a big deal anymore.
Edit: Another thing that ends up happening when you get to a point like this is that ideas start inter-breeding. You have a client ask you about some mobile app that they've been thinking of, and you realize that there's a pretty straightforward image processing or DSP algorithm to do what they're asking about, as an example.
From what I understand, Python's broad set of available libraries and APIs make it somewhat more suitable for use by generalists.
As a long term employee, a specialist gets stuck in one place and doesn't advance. A generalist moves around in the company, impressing people and getting raises, and helps with the valuable stuff like integrations and customer facing contacts.
The CTO is a generalist, not a specialist.
(Unfortunately management did not recognize this person's value to the rest of the team until they had already accepted a better job at another company, but that is a different story.)
It seems that there are three different ways one can "specialize": problem domain (e.g. business accounting), solution domain (e.g. "systems management software", "data science"), or tool-set (e.g. J2EE). Each form of specialization has its trade-offs, but it strikes me that tool-set specialization is particularly likely to get one stuck working on frustratingly complex legacy systems.
My attitude about specialization vs. generalization (that I think resonates with the OP) is not whether we should specialize, but when. To my mind, specialization is a necessity, and it does increase one's income, but it also incurs the risk that the specialization will become obsolete before you are ready to retire. When you look at risk-adjusted lifetime earnings[1], it seems to me that the most reasonable strategy is to delay specialization as long as possible.
[1]Warning: statement made without real numbers.
It sounds to me like you more or less ended up doing the correct thing.
If money matters to you - its easy to figure - hrs x price. Your price generally is higher if you specialize. Best thing is to be a rare bird - expert in something very valuable that few people can do.
You can eat good just doing basic web dev (for the time being at least), but if you're very ambitious - to really outperform - you'll want to be more special than that.