Maybe it's a coincidence, or maybe it's how "my algorithms" have been serving me, but I've seen a lot of discussion on different parts of the interwebs recently about the "T-shaped engineer". By "engineer" we're referring primarily to software engineers, at least in the context that I've been seeing it. A large part of this article, though, will be to show how this idea applies to all kinds of endeavors — mathematics included. But first,
What is a "T-shaped engineer"?
A common question that practitioners of various fields ask is whether it's better to be a generalist, or a specialist. Obviously, with infinite time, we would become a generalist by become a specialist in everything, but alas we live lives of finite length and therefore this is simply not an option. People who try this approach often end up never becoming a specialist in anything, and/or burn themselves out.
Fortunately though, our finite life span still does not force us to choose one or the other. Specialist or generalist. And that's where the "T" shape comes in. The general consensus (from what we can tell, and with which we agree) is that it is best to become "T-shaped". Namely, have a broad understanding of your field (corresponding to the horizontal line at the top of a "T") while going deep (the vertical line in a "T") in a single part of your field.
This is often applied to software engineers because there are natural splits in that field that make this question most relevant. Should I learn a little bit of Python, C++, Ruby, Rust, Javascript, C#, and assembly, or should I become a Python guru? The "T-shaped" answer would be the following: know enough about as many languages as is reasonable (how close they are to the machine, which ones are scripting languages, which need compilers, and which use virtual machines, and high-level use cases for them (e.g., javascript is for web-dev, c++ is for high performance, etc)) while diving deep into one of them so that you know not just the syntax, but also the design principles and built-in functionality that you can use to build actual production-ready systems.
Similar questions from the world of software engineering would be things like whether or not you should focus on object oriented design, functional programming, or meta programming, or whether you should focus on web-dev, network programming, numerical programming, operating systems, etc. In all these different ways of slicing up the field, the "T-shaped" answer consistently wins out.
It's worth thinking deeply, though, on why the T-shape is optimal
Why The T-shape?
We've seen a couple general approaches to answering this question, so we'll summarize those here and then offer up our own addition — the fractal T. More on that in a second.
The T-shape has a couple great things going for it. By knowing a bit about a lot of things (the horizontal part), you can make a more informed decision about which of those things you start going vertical on. That assumes you go horizontal first, though. What if you go vertical first? Well, if you've become an expert — a real expert — in, say, python, it'll make it way easier for you to learn basically any other language (even languages that are syntactically more difficult or closer to the machine). You'll know what questions you need to ask about the new languages and you'll have a "go-to" language that you can map ideas back on to. So, going vertical helps with going horizontal just as much as the reverse is true.
Second, your value as an "entry-level" employee (where by this we could mean an early-career software engineer or e.g. a phd student in math) will likely come from the vertical part. Someone will want you to do some pretty specific tasks, and for that, details matter. As you progress, though, developing a healthy horizontal part will allow you to start having higher-level ideas, to see connections between things, and/or manage people better.
And this last point brings us to our favorite reason for loving the "T". By having gone vertical in some subfield, you know what it's like to go vertical. This is a tough thing to obtain that not everyone has, and this gives you two superpowers: you can communicate and collaborate with people who have gone vertical in other subfields because you know what that takes, and you can go vertical in new subfields if you ever have to.
Before jumping to how this applies to math, and our idea of a "fractal T", let's just give a last example about what this might look like for a software engineer. A software engineer will find themselves primarily working with one (of several) languages, in one (of several) design approaches (OO, functional, etc.), in one (of several) domains (web-dev, scientific, financial, mobile, etc.). Your vertical path includes every one of these "choices", and at each slice it's worthwhile to have an eye towards the horizontal as much as possible.
Math, and the "Fractal-T"
Math is no different. A budding mathematician can choose to learn a bit about lots of things — topology, algebra, number theory, geometry, etc. — or to immediately specialize. Specialization is key, since a mathematician's product is original research, which cannot be done without understanding very specific sub-sub-sub-field and understanding it so deeply that you know which things have not been done yet. In order to get sufficiently vertical, though, you need to be able to repeatedly get horizontal enough to know where you want to continue going vertical.
Let me give a specific example from one of us — let's call him Dave — in theoretical physics. In physics, the first "horizontal" thing to choose is experimental or theoretical (keep in mind that at each of these splits, it's still possible to do some combination of both, but typically these are the types of splits one goes through). Dave learned a bit about both and decided that theoretical is what he preferred; he enjoyed building stuff with pen and paper more than with his hands. So that was a couple horizontal steps, and then a vertical step.
Within theory, Dave had to learn a bit about condensed matter theory, particle phenomenology, theoretical astrophysics, high-energy theory, and plasma theory, to then decide he wanted to do high-energy theory (he liked differential geometry and Lie groups). Again, some horizontal stuff, and then some vertical stuff.
Within high-energy theory there's cosmology, more particle physics, beyond-the-standard-model stuff, string theory, Ads/CFT, etc. He chose a sub-field called scattering amplitudes. Again, some horizontal and some vertical.
And within scattering amplitudes, there's supersymmetric theories, there's amplituhedron-type-stuff, there's "double-copy" type stuff, there's numerical/computational problems to work on, etc. Dave decided on amplituhedron type stuff.
It's maybe clear now where we get the phrase "Fractal-T". Within any given "T", there are deeper Ts, and so on. At each T, it's necessary to balance the horizontal with the vertical. So far, the only "upside" to balancing these things might appear to be in one's ability to better decide where to go vertical next, but we actually think there's more magic in the Fractal-T — that is, working your way back up the fractal.
Going Back Up The Fractal-T
Once you're at the bottom of the lowest T — i.e., once you're at the frontier of your sub-sub-sub-field — you start doing research there. Once you've found and solved some problems there, the magic really starts. Namely, if you go back up a level in your fractal, you may start to see some connections to other verticals. Or maybe you start collaborating with people who went down a different vertical, one level higher.
The impact of these types of projects starts to grow, because now you're making impacts on multiple peoples' verticals, not just yours and the 8-12 other people in the world who are on the same lowest-vertical. Indeed, we'd be willing to bet (though don't have any hard data on the matter) that the most impactful mathematicians/physicists/scientists in the world are those that have a massively interconnected web in their Fractal-T. They can see big connections while also having the technical ability — or at least a detailed-enough understanding to know who to collaborate with — to get problem(s) impacted dozens, or hundreds of smaller verticals actually formulated and solved.
This model for research — and research success — that we're calling the "Fractal-T" is not perfect, but we think it's pretty reasonable. It shows how at every step, you really need both the horizontal and the vertical. Sometimes, at different stages of one's career, one is more important than the other, but both are absolutely necessary. If anyone wants to share with us their "Fractal-T" story, and where you currently sit in it (much like "Dave" above), then we'd love to hear from you!