The polymath is a systems engineer

“Polymath” is a dangerous word. It suggests a finished person with a wall of certificates and an answer for everything. The real practice is closer to the opposite: a permanent admission that you do not yet understand the system in front of you.

I started building for the web in the early 2000s, when a page was still a small act of craft. Since then the work has moved through front end, back end, infrastructure, design, marketing, and security. None of those transitions felt like a career change. They felt like following the same problem into the next room.

That is the useful definition of range: not knowing many things, but refusing to stop at the boundary of one discipline when the problem crosses it. A fintech product is not a front-end problem or a security problem. It is a trust problem, a latency problem, a regulatory problem, and a design problem wearing one interface.

Range is a systems skill

The most expensive failures I have seen were not caused by a lack of specialists. They were caused by a missing translation between specialists. The security team names a risk the product team cannot price. The design team ships a flow the data model cannot support. The infrastructure team owns a failure mode nobody measured. Nobody is incompetent; the interfaces between them are.

Working across domains gives you something narrow expertise cannot: you learn to hear the same constraint in different vocabularies. A threat model, a user journey, and a database schema can all be describing the same missing assumption. The value is not that you can do every job. It is that you can tell when two jobs are actually one job.

The tax nobody mentions

There is a cost, and it is real. Depth compounds faster than breadth. While you are learning the third domain, someone else is becoming the person the market calls first for the first one. Switching costs are not a myth, and context switching will quietly erode your best work if you let it.

My answer is not balance. It is sequencing. I go deep enough in a domain to ship something real and to recognise quality, then I carry the pattern forward instead of carrying the identity. The stack changes. The questions do not: what is the constraint, what will break first, who carries the risk, and what does done actually mean?

What I optimise for

Not the widest list of skills. The shortest path between a real problem and a working system that someone can trust. Sometimes that path is a single afternoon of boring code. Sometimes it is a week of learning a domain well enough to know which obvious answer is wrong.

The Renaissance ideal was never about knowing everything. It was about refusing the artificial split between thinking and making.

That is still the job — and it is still unfinished.