Should Custom Software Developers Be Generalists or 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.

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).

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.

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.

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?