Is it better to be quick generalist or a slow specialist?

> Put another way, is it better to be a ultra pragmatic could-care-less hacker or an opinionated craftsman.

Is that really put another way? You can't swap out generalist for careless hacker and specialist for craftsman, they don't mean the same things.

You're also attaching it to people's identities which doesn't make sense to me. A better question is - when is it okay to be sloppy in order to get something done and when should you take your time and pay more attention to all the details. << that way it can be the same person who is sometimes making some tradeoffs to meet a deadline and sometimes moving slower and thinking about long-term consequences, instead of someone always carrying the label "quick generalist" or "opinionated craftsman" or whatever.

I would say it depends where you work: A big multinational corporation or a more or less medium sized local company?

I work in the latter and being a "jack of all trades" (who can do many things okay...ish but little really well) fits really good.

Any decent manager who demands immediate delivery better be aware of the long term costs. In the long run, it's usually cheaper to deliver a well-built feature over a longer time period, compared to a poorly built feature delivered promptly.

https://martinfowler.com/articles/is-quality-worth-cost.html

If it's a one off task then doing a bodge may get the manager the result they want quickest. However, managers don't want just the one task completing quickly they want a series of task to consistently be completed quickly. So let's take this into account and compare Programmer A (who regularly bodges things to get them out the door as quickly as possible) to Programmer B (who takes a bit of extra time on each task to keep the codebase maintainable)

As time goes on those bodges Programmer A is making will accumulate in the code and make it harder and harder to make changes and each new task takes longer to complete.

Programmer B on the other hand will find the code in a good state that's easy to change so each will be able to deliver tasks at a steady maintainable rate.

Of course if Programmer A is going to make a couple of changes and then leave the project there's no incentive for them to do anything other than bodges, that why we have things like code reviews so that those programmers who are going to be on a project long term can spot the bodges before they get into the live codebase.

Specialists thrive in stable environments, while generalists are much better in unstable environments.

Change kills the value of a specialist.

Quick work has a very real long-term hidden cost. Not only it creates tech debt - meaning the work has to probably be redone at a later stage, but also racks up wasted hours of bug fixing over time. Most importantly, if a codebase is entirely composed of "quick work", it creates a legacy codebase - which means it will be harder to hire engineers that want to maintain it. Or again, you'll have to redo it.

So, it depends. If there's a high change whatever you're working on is there to stay, it's better to do it well.

If you're still experimenting, or unsure if the feature is there to stay, then the tech debt incurred might not matter.

Specialization leads to higher pay. Being a generalist will keep you locked to roles where a generalist is useful. I have a very high breadth of skills with everything you can imagine from Cisco to Exchange servers, but my expertise is resurrecting dead equipment. I have the rare intersection of software engineering, reverse engineering (to bypass serial numbers for long unsupported software), and electronics repair skills.

So, if you want a machine on which your business runs resurrected, regardless of parts availability, you will come to me and pay several thousand dollars.

How much job mobility do you want?

It's better to decently know 25 technologies, than being the world-class expert in the Spring Framework and nothing else.

Software engineering gets more complex and branches off every single day. The more things you know, the better, because it's not how deep your knowledge is, but how quickly you can get up to speed with something which you didn't know existed until today.

Ability to learn >>>> specialisation. So get good at learning by learning something new every single day.

Disclaimer: My HN profile says I'm a "jack of all trades", so I'm very biased.

Taking extra time is no guarantee of a better quality result the same way being fast is no guarantee that work was sloppy.

It depends on the situation, but going slow misses out on learning opportunities that come from a faster iterations.

Depends on the ecology.

Usually in complex settings you need a whole suite of problem solving strategies.

If you're asking about people's personal preferences it's going to be, funnily enough, personal. Right?

The question is which approach fits you better personally. Besides, it's highly dependent on what you work on - ability to adapt is more important here.

Be a specialist in some topics. And generalist enough so that you can apply your specialized knowledge to solve other problems of others

I think it depends on what you want to become. Good developer -> Slow specialist. Good entrepreneur -> Quick generalist

Quick specialist.