It’s fall, college is in full swing, and apparently it’s hunting season for research projects and internships.

Or so I would guess from the number of emails I’m getting about that, both here at TFF and from my grad school institution, which apparently still has my name and email on a list of grad researchers that would-be undergrad researchers can find.

So, perhaps an advice post is in order.

Now, this will be tricky to write because, all else being equal, being more focused and doing fewer things deeper is usually what most people need to hear.

On the other hand, you can go too far in that direction, which I probably did earlier in my career. That got me an academic reputation, which probably helped getting interviews, but it only helped me actually do the job up to a point.

Academia rewards hyperfocus on a small body of knowledge, the rest of the world rewards being good enough at the right combination of knowledge.

I think there is a healthy synthesis of these to to be had, and that’s what I will attempt to describe in this post.

Note that this post is heavily biased towards technical careers. It’s probably applicable to others as well, but that’s outside my experience so I can’t vouch for the reliability of this advice elsewhere.

Sequential Focus

Doing too much at once is a common mistake that I frequently call out here.

Note that I’m not criticising doing a lot, just doing a lot at the same time.

We’re not computers, and our minds don’t really work well in parallel, or even with frequent context switches.

In most cases, you’ll get way more done in a given period of time if you do one thing at a time, than if you attempt to do everything simultaneously.

There are people who seem to be able to do a lot at once and succeed, but they’re rare.

Most who do that succeed in little but looking busy.

When I was in college, a professor told us something to the effect of

“Don’t worry about the news. You only have one chance to be here and learn what this place has to teach you. The world will still be there when you’re done.”

Turns out he was right. It was still there when we got our diplomas.

There’s a bit more to it though, so read on.

Focus for Depth vs Focus for Speed

Early on, you focus on a limited set of things for a long time because that’s the minimum required to get good at hard things.

After that, focus will assume a different role. Or rather, two different but related roles.

One is just to quickly execute the small tasks that make up most of any job. The other is to quickly learn smaller but useful skills so you can keep growing.

I talk more about this Macro Focus vs. Micro Focus.

Get to the plateau and jump

A lot of skills develop like what is called a sigmoid curve, slow at first, then with a short period of very rapid growth, followed by a slow plateau, during which it takes a lot of effort to get even a little better.

Sometimes, your chosen endeavor may require continuing to work in this plateau.

Most of the time, you’re better served by realizing when you’re good enough, often early in the plateau, and switching to the next thing.

Note that the next thing should be complimentary. If you choose a sequence of complementary skills, your overall effectiveness can grow rapidly, almost indefinitely.

If they are not complementary, you’re essentially starting from zero each time, and your total ability won’t really increase much even though you’re putting in a lot of work.

I talk about how to pick complementary skills in this book review.

To make this clearer, I’ll give you two examples from my own life.

Example: Writing

There are many components to being a good writer.

First, you learn how to put together coherent sentences and paragraphs, basic grammar, etc.\

Then, coherent short pieces of content. For me this was columns I wrote for a homeschool magazine and college essays.

A key thing here was not just write a lot – that by itself doesn’t make you grow and can reinforce a bunch of bad habits. The thing was to write, get feedback, rewrite, and keep going until the piece is tight, clear, and polished.

Doing this with word limits and deadlines is also very helpful.

This is roughly how I started writing, and it gave me the core skills for being a good writer later.

In my case this happened in high school, after which, my writing practice was effectively dormant for a decade

I wrote papers in college, but I’ve never found that this style of writing helps that much since you don’t usually do enough drafts and grading is only vaguely related to the quality of the writing.

In college and grad school I authored a few research papers – which is good practice for clarity, tightness and deadlines but only tangentially related to making you good at other kinds of writing.

Unfortunately, it also had the side effect of making my writing voice very formal and dry, something I had to unlearn later.

When I started The Focus Formulas, I worked on consistently producing content every week on both my blog and email list, as well as making my voice more conversational and less formal.

This kind of writing doesn’t have to be the most polished, but it has to be clear, entertaining, and useful to the audience. It also has to be produced fast, because I didn’t have hours and hours every week to spend on it.

I also learned about marketing and copywriting, both to make my free content more compelling and to sell my first product.

I now feel like I’ve mastered this skill of consistent content sufficiently for my purposes, so I’m scaling it back a bit by not always doing a weekly blog post and instead working on producing longer, more detailed blog content at a slower tempo.

The next step will probably be a book of some form, so stay tuned.

Example: Data Science

So, to start off with, data science was not what I originally aspired to do. The term supposedly wasn’t even really coined until my junior year of college.

I started off wanting to do physics, but discovered that I liked the math in computer science more. So, college was spent buried in math that had computing applications.

I avoided programming like the plague, both because it didn’t interest me that much at the time and because I found the math to be all consuming.

Also, I was new to programming, and still at that stage when debugging could involve multiple hours of frustration, only to discover that the problem was a misplaced period.

I’m a calm guy, but this kind of thing inspired eyebrow-singeing storms of invective that turned heads in the computer lab more than once.

What’s worse is that, at this stage, you don’t have a good sense for how long things are going to take, which is hugely stressful, especially when you also have a mind-bending math problem set due the same day as a rage-inducing programming assignment.\

So, I stayed focused on the math as much as I could.

Grad school was about the same, I stayed focused more mathematical aspects of a subfield of machine learning.

The good news here was that I did well enough to look great on paper. The bad news was that what I had spent years honing to a fine edge was only somewhat related to day-to-day work.

The art in non-academic technical work is being good enough at a whole bunch of disparate pieces and fitting them together into a holistic whole that solves a real problem, and doing it fast.

I found myself being really good at a few pieces, below average at the others, and with a bad tendency to overemphasize the parts I knew.

I got over those, but it took a few awkward and stressful years.

I still had my hard-won deep skills to distinguish me from the competition, and I got good enough at related topics (databases, prototype-level programming, data visualization, etc.) that I could take on big projects on my own without stumbling on small technical details.

In retrospect, I don’t think I would have changed what I did during undergrad. That depth was useful, even if I didn’t employ the full range later in my career,

If I would change anything, I should probably have used grad school, with its more relaxed schedule, to do small projects that would force me get better at range of the less interesting but highly useful technical skills.

Where to go from here

To, to recap, the approach is recommend is sequential focus on complementary, high value skills.

The time and effort required to get good at foundational skills is much higher, and should be done early.

The time and effort required to get good at ancillary skills is generally much less, especially with foundations in place, and should be a continual process.

Most day-to-day technical work will require you to figure out a high-level solution for a given problem, breaking it up into components, and knocking these components out quickly with high enough quality that the final result fulfills its intended purpose.

The higher level aspects of this you’ll just learn by experience. Executing the individual pieces is a matter of being good enough at the right skills and being able to focus so you can get it done fast.

Focusing for quick execution is its own art, which I had to learn the hard way, but you can learn the easy way from my course on the subject.

Quick execution forms a significant positive feedback loop with experience, because the faster you do low level tasks, the more high level tasks you’ll have time to get done, and the better you’ll be at them.

This snowballs very quickly, and can make the difference between mediocre and superstar performance over just a few years.

To ensure a lifetime of continual improvement, get that foundational knowledge early, and after you’ve got that, keep chaining together relatively short, focused periods of getting good enough at complimentary skills.

Do this consistently and there’s no real limit to how effective you can be.