Ask HN: Is it better to be quick generalist or a slow specialist? | Hacker News Reader

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

In development world, we often espouse idealistic ways of writing and managing code: readability, maintainability etc...it's a very deep subject.

Compare this to the reality of many jobs, where some manager needs stuff delivered NOW.

It would seem a "hacker", someone that can bodge things together and make them "work" is more valuable often than someone who does everything following best practices....which would be seen as more naive perhaps.

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

I know people complain, that you leave a mess for others to deal with. But really why would you care? It's not your problem anymore.

View on HN

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

I second this so much. Not everywhere is the USA, or a FAANG. What I do would probably be split among 2/3 positions in a large company. In a sense this means I'm less efficient, but it also means I'm able to give a lot of value to the company in a lot of different scenarios.

Many more companies than you think are very happy to take that tradeoff.

I appreciate the reminder. I work at a smaller place and boy am I all over the place depending on the work that's coming in.

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

For this to be effective, it has to be understood all the way to the top. The problem I see is that managers are often not technical enough and simply want to appease their bosses with something tangible ... or they are technical, understand this but their boss is not technical, in which case they end up doubling down anyway to appease their boss. Odds are your middle manager has very little clout to argue for much anyway.

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

It is better in theory, but not in practice.

A startup needs to deliver ASAP, and doesn't care if something is built carefully if a competitor beats you out the door with a subpar product. And that applies to any size company in fact.

If you want to take your time doing it well, work for yourself. Because out there what matters the most is delivering as quickly as possible.

Oh the ThoughtWorks gang... it's about billing the customers by dragging the project longer for quality and therefore earning more

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.

Such a great point.

What are you some stable environments in our industry? Are they going to be stable in 5-10-15 years?

I wish I picked Emacs up a while back. It seems to be stable.

Compilers are stable, I think.

A tenured computer science professor?

Thinking about this highlights the fact how backwards our industry is. It's either a handful of ultra specialist roles or continuing to jump from tech stack to tech stack to stay employable. My cgi-bin experience is worth nothing currently.

The pragmatic thing then, is to be a generalist.

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.

Like I say at work about quick and dirty do it now stuff:

“Nothing’s more permanent than a temporary solution.”

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.

Perhaps I'm being too contrarian for my own good again, but it seems to me that knowledge that doesn't extend beyond a single tool or programming language isn't very deep in the first place.

The easiest way to quickly pick up new tools and languages is to have a deep understanding of the relevant concepts.

It makes sense. Knowing three similar languages is better than knowing one language three times as deep, because you start to see patterns, similarities and contrasts. It makes you more experienced and able to think outside the box, because you now know what the box looks like.

I would argue that you're better off knowing 3 very different languages than 3 languages that are similar. That way you're more likely to be able tackle a problem with an approach that's suitable.

Or to put it another way, if I've only got 3 hammers of different sizes then everything will still look like a nail :)

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.

Reply on news.ycombinator.com