On Mastery

Stumbling around the intertubes I’ve recently come across a number of articles on the topic of mastery. The one to spark it off was Hugh Macleod’s article. Then there was Buster Benson on his blog. Finally yesterday my friend Ahsan from college wrote a post titled “The Speed of Masters”. Additionally I’ve been following Cal Newport’s Study Hacks for a good few years now and he has a lot to say on the topic of mastery and finding your passion.

Going through all that it became very clear that people have a lot of different ideas about what mastery consists and how to best go about it. Those ideas are widely different and often contradictory. While I’m no philosopher or psychologist, mastery is a topic that is important to me. I’m in a PhD program so I’m supposed to be spending the next few years (asymptotically) approaching mastery in my research area.

Keeping all that in mind I’m going to collect some of my thoughts here in the hopes that someone will find them useful. maybe it’ll spark some interesting discussion. (And writing things out is a surprisingly good way of actually thinking about them.)

What is mastery?

Good question. Very good question. There are multiple definitions but the ones I’m partial to are: “full command and understanding of a subject” and “outstanding skill; expertise”. I like these because they elucidate different aspects of mastery.

First, you must have full command and mastery of a subject. You can’t half-ass your way to mastery. This gets to the heart of my objections to notions like programmers don’t need to know computer science. If you want to be a master programmer, you must know how the machine works. All the way. Period. You have to understand algorithms, garbage collection, cache hierarchies, data-structure tradeoffs, network protocols, the whole lot. You can’t be expected to know it all from the get go, but if you don’t know it eventually, don’t expect to be a master.

The second definition answers the question: what can you be a master of? You can master a particular skill. Your skill has to be definite: something where it’s clear what mastery means. For a chef it’s Michelin Stars. For a scientist it’s a solid publication record. This means that if you want to be a generalist like an entrepreneur or “problem solver” then mastery is harder to define. But even then I suspect it’s possible: look for people with similar goals and ideals and look at their track record. Masters can be quiet and humble, but they certainly have a track record. You can’t be a master without producing great work.

Why mastery?

Now that is a harder question for me to answer. It’s been claimed that mastery is a worthy pursuit in and of itself. That it matters more than money and success. I don’t really buy that, at least not for myself. I think this is a personal question that everyone needs to answer for themselves. For me, mastery is a means to an end. Being a master programmer (or engineer/scientists) means that I’ll be in a much better position to identify and tackle important problems and maybe even have a chance of solving them. Mastery is not disjoint from money or success. Being wealthy or successful makes it much easier to work on and solve the problems you’re really interested in, if for no other reason than that you spend less time worrying about making ends meet. Of course it’s easy to let the pursuit of money or success get in the way of achieving mastery, but that’s a different matter.

How do I get there?

I often seen the idea of mastery linked to notions of passion and finding your calling. The popular reasoning is that once you know your passion you’ll have the motivation to work hard and long. And once you work long at hard at what you’re passionate at you’ll become a master at it. Romantic and inspiring as this view of mastery might be, I think it’s backwards.

Cal Newport has a different take on mastery that is probably closer to the truth. Passion is not what comes first. Competence in a particular area comes first and passion follows from it. It’s easier to become deeply interested in something if you’re already good at it. Of course this doesn’t mean that you’ll like whatever you’re good at or that you can’t decide to do something and put in the effort to master it.

The important thing to remember is that you can’t sit around waiting for your passion to fall into your lap. You have to go out there and seek it out – act with agency. And once you’ve decided what you want to master, plan out the path to mastery. Though hard and long work is necessary for mastery, I doubt it’s sufficient. As studies on deliberate practice show, the best musicians aren’t necessarily the ones that play the most – they’re ones that practice the right things every day with an eye towards constant improvement. Gaining mastery is hard work, but that doesn’t mean you shouldn’t be smart about it.

The best way to figure out how to master an area is to see how people who are already masters have gotten there. Be careful though, since media attention can easily obscure the details of their actual journey. Do your own research and verify your sources.

In conclusion

Mastery involves the acquisition of a complex skill and complete understanding of a subject. Your reasons for wanting to master something can be deeply personal, but it’s important to know what they are. Mastery must be actively pursued. If you don’t know what you want to master try out different things, gain basic competence and see which one appeals to you. Study the paths of previous masters and learn from their lives and track records.

The question I have for you, dear reader, is: What are you trying to master? How are you getting there?

Grit for Programmers

It turns out that the best indicator of success isn’t IQ or natural talent or how well off you were at birth. Rather it’s something called grit – the perseverance and passion for long-term goals. Grit requires a clear goal, self-confidence and a careful balance between stubborness and flexibility. For the last few months I’ve been living one of the most productive (and most challenging) times of my life. I’ve been building a system that has more parts, does more things and is much larger than just about anything I’ve built before. It’s been challenging and rewarding work and I couldn’t have done it without lots of support from great mentors. As I’ve stumbled, fallen down, hit brick walls, picked myself up and kept going I’ve been wondering – does grit apply equally to programmers and success in building good software?

Programming culture is generally synonymous with hard work and long hours — death marches, all-nighters, 80 hour work weeks, we do them all. But we’re talking about grit here, not masochism. Grit isn’t strictly equal to working obscenely hard, long hours. Part of the problem with thinking about grit in relation to programming is defining what success means for a programmer. Is your definition of success simply finding a working solution? Does it mean finding the most efficient solution? Are you successful if you cover every single edge case or is it enough to just take care of the most common ones? Is your program really better if it handles everything you could throw at it or should you handle core uses cases well and fail gracefully on the others? Part of the problem of coming up with a good solution is asking the right question. This is especially true of building software. However merely coming up with the right question requires a certain amount of grit. We need the patience to look beyond the obvious problems and solutions and ask the hard questions.

So now we’ve found the right question and defined bounds on the possible solutions. What next? How does grit help with the actual act of writing code and building stuff? Programming is not easy. It can be fun and exciting and uplifting, but sometimes it is downright hard and depressing. Sometimes we spend hours sifting through possible solutions before hitting upon the appopriate one. Sometimes we spend several intimate hours with a debugger tracking down pointer bugs before finding that one variable we forgot to initialize. Being tenacious and persistent in the face of seemingly unrelenting roadblocks is not an added benefit for a programmer – it is a bare necessity. When it comes down to the act of sitting down, writing and debugging code grit is not optional. Without it not only can we not be good programmers, we can’t even be an average ones.

But if our goal is to be a good (maybe even great) programmer, then grit will continue to help. One of the qualities of good programmers is that they get a lot of stuff done. In particular they do a lot that isn’t strictly their job. This includes fixing and extending their tools and improving core infrastructure. They do this even if they aren’t in charge of infrastructure because they realize that their code depends on what’s underneath. Grit is the difference between waiting for someone else to fix the annoying bug in the library that you depend on and diving in and fixing it ourselves. When Steve Yegge talks about the difference between “superhumanly godlike” and “smart”, grit is a part of what he’s talking about. Not that there’s anything wrong with being smart, but it might not be enough. Of course to cultivate that level of grit we need to cultivate a good deal of courage. Diving into someone else’s code and fixing it can be a daunting task but it’s one that has to be mastered.

While I’ve always liked programming it’s taken me a long time to understand the importance of grit. When you do something because you like it (mostly) it’s tempting to stay away from the parts that are painful and hard. For a long time I avoided writing large programs because I was afraid of all the complexity that was involved. I was afraid of becoming familiar with complex algorithms because I was afraid of the possibility that I’d get it wrong. I understand now that I can’t become a good programmer if I don’t push myself to do the things that I consider hard and dislike. I need to have the grit to handle large complex problems and spend the time to understand and apply advanced algorithms. The good news is that just like perseverance and discipline, grit can be trained and improved. I’m no longer as afraid to dive into unknown codebases as I was a few months ago. I now find it much easier to hold complex code paths in my head. I’m certainly far, far away from being superhuman, but I try to suck a little less every day.