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.
