Why I describe myself as an expert generalist

Fowler, Joshi and Venkatraman put a name to a way of working that values fundamentals over tools. It's the closest fit for how I work, and for what I keep aiming at.

Articles By

Most job adverts for software roles ask for years of experience in a named tool. Five years of React. Three years of Kubernetes. The assumption underneath is that skill lives in the tool.

For years I described myself as “a jack of all trades, master of none”, usually in a self-deprecating way. The industry has at times treated breadth as a weakness. I always saw it as a strength, and I kept to that track.

In July 2025 Unmesh Joshi, Gitanjali Venkatraman and Martin Fowler published Expert Generalists, an article arguing that the assumption behind the job adverts is wrong, and that the industry should treat being a capable generalist as a first-class skill in its own right. It was good to read something that put a name to it. It’s the best description I’ve found of how I work, and of what I aim for.

What the article means by it

The term joins two things that are usually discussed separately. One is real depth in at least one area. The other is the ability to walk into an unfamiliar domain, learn quickly, and see the fundamentals beneath whatever tools happen to be in use. In the authors’ words, “being such a generalist is itself a sophisticated expertise”.

Their example is an experienced Python programmer joining a Java team. A keyword filter would reject them. In practice they’d be useful within weeks, because the things that matter carry across. Core programming concepts, breaking work into small testable pieces, and working well with the people who’ll use the software.

The authors admit that many people who fit the description wince at the word “expert”. I used to. These days I’m happy to own it. The alternatives are worse, in any case. “Generalist” on its own tends to mean someone who knows a little about everything and can’t do much with any of it.

Six characteristics

The article describes six traits. I’ve paraphrased them here.

  • Curiosity. The default reaction to a new technology is to want to understand it, rather than copy an answer and move on.
  • Collaborativeness. Nobody can learn everything, so expert generalists work alongside specialists and ask for help readily. Part of that is finding out why something odd exists before challenging it. There’s usually a reason.
  • Customer focus. Curiosity needs a direction or it chases whatever’s new. The question for any technology is how it helps the people the software is for. This is where I believe I stand out. It means understanding why something is being built in the first place, joining that up with what the business is trying to do, and carrying the answer into every technical decision that follows.
  • Favouring fundamental knowledge. Patterns and principles age slowly. Tool-specific knowledge ages fast. With limited time, learn the slow-ageing kind.
  • A blend of generalist and specialist skills. The authors are suspicious of anyone who presents as a generalist with no deep areas at all. The breadth rests on a few areas of real depth, usually picked up by building products. Mine is system design. APIs, data schemas, and finding the layers of abstraction that make a system easier to change.
  • Sympathy for related domains. A database designer should have a feel for the user interface. A designer should have a feel for what’s expensive to build. Someone joining a team should work with the grain of what’s already there.

One habit the article doesn’t cover, and which I’d add, is writing down a short set of guiding principles at the start of every project. Agreed up front, while the aims are fresh and nobody is under pressure, they become the reference point for the decisions that follow. When a choice is hard, the principles often settle it.

Fundamentals outlast tools

The authors’ observation is that the industry’s attention keeps going to the tools of the day, while the principles those tools are built on get far less of it. Tools and frameworks change constantly. The fundamentals underneath change slowly. The basic moves of refactoring are the same in every language, and a message queue behaves like a message queue whatever it’s branded as.

I’ve always encouraged junior developers to learn the fundamentals rather than the tools, for the same reason. Transferable skills last a working lifetime. The tool of the moment will be replaced, and there’s no telling when a project, a market or a career will demand a change of direction. For a specialist, everything is fine until it isn’t. A solid grasp of the fundamentals gives the confidence to make that move, and it’s what makes it possible to become useful quickly in an unfamiliar codebase, domain or team.

Why it matters for the work I do

An independent technology assessment means forming a view of an unfamiliar product, codebase and team in a few weeks. There’s no time to become a specialist in the stack, and no need to. What makes it work is recognising patterns and knowing which questions to ask. The article puts it well. “Faults are often not in the depth of a single technology, but in the implicit interactions between them.” The problems that matter in an assessment usually sit between things. Between the application and the database, between the team and the release process, between what the product does and what the sales deck says it does.

That breadth of knowledge and experience is what the insights I offer today rest on.

The embedded advisor role asks for the same breadth in a different shape. A small SaaS company can’t justify a specialist for each area, and the questions that reach an advisor range across product direction, architecture, security, supplier decisions, where AI fits, and whatever else turned up this week. That’s breadth plus judgement about where to go deep and when to bring someone else in.

Where AI fits

The authors argue that these capabilities become more valuable with large language models, and the reasoning is simple. A model behaves like a specialist on call. Someone entering a new domain can get quick answers, and the value comes from asking good questions and checking what comes back. Curiosity and a grasp of the fundamentals are, in their words, “exactly the behavior needed to overcome the unreliability inherent in LLM-given advice”.

If anything the case has strengthened since the article was written. Agentic coding tools now do a large share of the typing, and the limiting factor has moved to knowing what to ask for, recognising when the answer is wrong, and understanding how the pieces fit together. That favours breadth. Using these tools on unfamiliar codebases, I find the agents produce a map of the system far faster than a person could. Deciding what on the map matters, what’s missing and what the business actually needs still comes from understanding the territory. I’ve written about how that works in practice in Using AI on an existing codebase without handing over ownership.

A direction more than a badge

I describe myself as an expert generalist because it’s the closest fit for how I work, and because it says plainly what the old joke only hinted at. I’m glad I stuck with it. I also treat it as something to keep working at, which is why the six characteristics above read to me as much like a list of aims as a description.

References