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.

Compared to the energy of creating and making things, consumption almost always feels draining. There is a difference between buying things and consumerism. For better or for worse it’s possible to be a consumer without spending money. Thanks to all the free content around the web I can easily spend hours and days consuming without spending a dime. Netflix, YouTube, Vimeo, Spotify, etc. are all incredible (and seemingly unending) sources of consumable content. I don’t spend any money (or at most very little money), but I do spend a large amount in terms of energy and time. It’s so easy to sit on the couch and just hit the next button. Before I know it, it’s dark outside, the day is gone, I’ve forgotten to get dinner and accomplished pretty much nothing. The problem with this form of empty consumption is that it’s not relaxing or refreshing and it’s definitely not useful. The day just melts away into a sea of unproductiveness.

Television is particularly soul-sucking. It’s almost drug-like in the effectiveness with which it shuts down my brain and makes the rest of the world go away. When I sit on the couch and turn on Netflix I can feel my brain turning off. There’s a fog of semi-consciousness descending on my mind. I’m awake, I can see and touch and feel, but I’ve lost all the will to act or do anything other than hit the next button. After a few minutes it’s more work tearing myself away than hitting “next”. I suppose this is what being a zombie is like. This is my brain on television and in hindsight it’s quite terrifying. Perhaps there’s a reason it’s been called the “idiot box”.

Modern society seems to be predisposed towards consumers. Everyone is a consumer whether or not they want to be. Even the point of creation is to make money to be used for more consumption. I’m not about to make a grand sweeping statement like “consumption is evil”. Personally I think the occasional (even regular) indulgence is fine, maybe even healthy. But for me, consumption as a way of life is depressing. It’s synonymous with days sitting on the couch watching bad television, feeling my brain gradually atrophy a handful of neurons at a time. It’s synonymous with buying a nice shirt and then wearing free t-shirts to class everyday. Even though it might feel good in the moment, it quickly turns to disappointment and regret. Personally, I’ll take the pain of discipline over the pain of disappointment and regret.

Creation is different. Creation should be harder, it should take up more energy, it should leave me feeling trained and tired. And sometimes it does. But even if I feel physically tired, at a deeper level I feel energized. It feels good to know that today I made something. It makes me look forward to getting up tomorrow morning and making it better. It’s good to be able to show something to people, to get their opinions and ideas and then go back and polish. It’s good to know that I can the change the world in some way and maybe, just maybe I can make a bigger difference. Creation is good.

I don’t know why being creative feels good. I’m sure there’s some reward pathway in the brain that gets triggered by designing something, making plans to make it happen and then actually following through on those plans. I would like to believe that what I make helps other people in some way. Even if it doesn’t, I think I’m fine with pursuing creativity for personal reasons. I’m hoping that a life with less random television, fewer RSS feeds and less time glued to Twitter and Facebook will translate to more blog posts, more working code and more meaningful connections with real people. I’m hoping that it’ll also keep away the dreaded feeling of brain decay that a few hours of “entertainment” produces. Even when I do consume, I’d like it to be good books, good music and movies, blog posts that are actually insightful and interesting and not shallow proclamations of half-formed thoughts.

What I consume should be what I aspire to create. I want to create more than I consume.

Though the piece focused on the tech industry and business, I think the basic ideas apply to all fields including (especially?) academia. In fact I think that the best researchers and scientists have always been those who have been spread out over a number of areas. While focus and diligence are necessary for productive research, I’m starting to think that it’s important (if not fundamental) to have a wider halo of interests and knowledge surrounding your core area.

As a new graduate student this is a question of great personal interest: I have a limited amount of time and energy in grad school (and later) and it’s in my best interest to make the most of it. As with many important things there’s a dilemma: if I spend too much time and effort on one thing I’ll miss out on everything else and that can be very limiting. I already know this first hand: I know a good amount about programming languages, but I’ve been scrambling to teach myself about networks and know next to nothing about AI. But on the other hand if I don’t dig deep enough into one relatively narrow area I’ll never have the knowledge or the insight to know what the important problems and come up with appropriate solutions.

So what are the lessons of Generation Flux and how do they apply? Accepting and adapting to change is definitely a big part of it. As danah boyd tells us: “We all have to learn new skills. Being able to live on one set of skills over a career is not realistic. Change is going to happen, not all of it good, in serious ways.” But simply being able to ride the wave is not enough. And it’s certainly not advisable to jump ship to the next shiny thing at the first sign of trouble. DJ Patil has more personal advice to offer: “At the end of the day, you have two things: your energy and your intellectual curiosity. If you’re willing to apply them, try to add value to the world, the possibilities are so endless.”

Patil, boyd and the other Gen Fluxers seem to be able to strike a balance between change and constancy. In times of perpetual change the key to success seems to lie in two complementary values: first is the ability to live on the edge of chaos and move fluidly from one spot to another. But second (and just as important) seems to be the ability to be tenacious, diligent and sometimes downright stubborn. Patil for example taught himself mathematics and worked midnight to morning to get computer access. While he’s worked on amazing projects he’s also turned down lucrative offers because they didn’t fit his vision of what he wanted to do.

Viewed through the lense of graduate school the lessons become: Explore broadly and lightly across areas related to what you’re interested and then buckle down, dive deep and keep going until you get to something novel. Of course the timing is critical and to some extent they have to happen in parallel. As Matt Might puts it: going rogue too early or too late can be fatal. Luckily that’s what advisors, mentors and colleagues are for.

Personally I’m still in stage 1: I’m still taking classes and exploring the broad regions of computer science but I’m also making forays deep into some areas (particularly programming languages and datacenter networks). Looking further ahead I think it’s great that we’re going to be living in a time where being a member of Gen Flux is a good thing. Gen Flux is perhaps just a modern term for Renaissance Men (or Women) – people with a breadth of knowledge and skills but also with singular and far-reaching accomplishments in some of those fields. And that seems like a goal worthy of a lifetime worth of time and energy.

An étude (a French word meaning study, French pronunciation: [eˈtyd], English pronunciation: / ˈeɪtjuːd /) is an instrumental musical composition, most commonly of considerable difficulty, usually designed to provide practice material for perfecting a particular technical skill.

I noticed today that Michael Fogus (one of the authors of Joy of Clojure) has a number of Github repos with names such as etude-ocaml and etude-syntax. I also realized this week that I’m a pretty slow programmer. I’ve been getting better over the years but I’m still slow, especially if there’s a good amount of API design involved. While I think that writing lots of code will make me faster over time, I do wish there was a more structured, focused approach.

In general, I wish there was more by the way of études for programming — problems and exercises of considerable difficulty designed to provide practice material for a particular (set of) skills. There are of course great textbooks for programming and computer science and those books have good exercises (I particularly like SICP and the K&R C book), however in most of those cases the point is to teach first and practice second. What I’d like to see is the reverse – assume that the reader already knows about functional programming or the C language but needs to “level up”, so to speak. The exercises would be harder and more in number but would also cover a broad area in terms of application of the concepts involved.

This is related to what I’ve written earlier in terms of deliberate practice for programmers. That post talks about “level up” lists – a list of programs to make that help explore the different areas of computer science and help you gain experience and hence “level up” as a developer. On the other hand études would focus on depth rather than breadth – each one would focus on a small technique or technology and fully explore that area. Together a continuous habit of working on études and doing level-up projects would give programmers a steady stream of deliberate practice exercises to work on.

The question is, where are we to find these études? I’m not sure if there are programming books out there that fit that description. If there are, I’d love to here about them. But in the meantime I’ve found an acceptable alternative — homework and assignments for college level courses. This semester I’m the TA for a course on functional programming and throughout the semester we have a set of 6 assignments for students to do. Each of them have about 3 to 4 problems (each with multiple parts) that tackle a small area of functional programming. I think exercises like this are great material for études. I’m currently working through the exercises at the same time as the students (other TAs are making them). Even though I’m already familiar with most of the material it’s been a good learning and great practice for me. I can’t really measure if I’m improving (apart from running my solutions through the test harness) but it’s more direct and practice in functional programming that I’ve ever had.

I’ll be done with this particular étude in a few months. I don’t think I’ll be releasing the code since the problems often get reused. However I do think there will be lot more where those came from. There are lots of college courses with website out there and there’s lots to learn. I’ll probably try compilers next. All that being said, it would be great to see some curation and collection. With Amazon’s Kindle Shorts and the growing interest in short, self-published books putting together a regular series of études might be a pretty lucrative endeavor.

While last semester was a good learning experience I got a lot less done than I could have. While I don’t want to cry over spilt milk I certainly don’t want to make the same mistakes again. My class load and TA work are about the same as last semester. However I have a better idea of how much time each takes so I can schedule blocks of time more effectively to get large chunks of work done at a time (and not worry about it otherwise). That in turn means that I can have more time for research (which is something I definitely want to do more of this time around).

I’m really happy about the choice of classes I have for this semester. I’m taking Advanced Programming Languages and Datacenter Networks – both are areas in which I have an interest but I know less than I would like to. I have great professors in both and so far the material has been very interesting (and useful). I’m the TA for a class on functional programming which is turning out to be a good learning experience as well. I’ve done some amount of functional programming but not a lot and not in a structured way. I’m working through the exercises and homeworks myself so that I can better help out the students and learning a lot in the process. Since I’m going to be doing a lot of functional programming in the future (Haskell programming in particular) this a good way to level up as well as get my TA duties done.

Last semester I had a small research project which was more of way to get familiar with the concepts and tools I’ll be using later. I am a little disappointed in that my final deliverables weren’t as complete as I would have liked but the experience will come in handy. This semester I have a more concrete (and more ambitious) project. I’m also starting sooner and thanks to last semester I have a far better idea of the challenges I’ll face and how much work it will take to get around them. My main interest in programming languages and right now the project isn’t very language-oriented. But there is a lot of cool systems-hackery involved and once the foundations are laid I can move on to the more higher-level language-oriented parts of it. I’m still taking baby steps (figure out build systems, building testbenches and having rather intense discussions with my compiler) but within a week or two I want to progress to the real meat of the project.

Aside: In case you’re wondering, it involves networks and trusted computing, but more on that in a future post.

Apart from school and research work I’m hoping to do some more exploring. Cornell has a really nice campus but I only saw a small fraction of it last semester (and probably spent a bit too much time in my apartment). I’d like to be able to get out more and take advantage of everything that Cornell has to offer. That’s a bit easier said then done in winter, but that’ll change as things get warmer.

I’m still trying to work out the best “work life balance”. While things like Cal Newport’s fixed schedule productivity seem appealing it might be unworkable for me right now. More importantly, I’m still not sure how separate my work and my life should be, or even what constitutes “work”. I haven’t decided if I consider my writing or my on-the-side hacking (which I’ve been doing far too little of recently) to be work, play or something else. Part of me would like to think that the work-life distinction is only applicable to a more Industrial Age setting where you don’t like your job and want to spend as little time doing it as possible. Ideally you should do work you love (which I’m gradually approaching) and have no need to draw a distinction. While that seems appealing I’m afraid it might lead to sitting (or standing) in front of my machine all day which is not what I want to do. Luckily these aren’t questions I have to answer definitely right now, but I can keep refining my answers over time.

I’m hoping that the rest of the semester will have lots of great learning, cool hacks and maintaining some semblance of a life away from my machines. I know that graduate school can easily become a drag and very stressful and I’m determined to not let myself end up in such a position. Luckily I’m in a good department with great support from friends, family and professors. I’d like to see this semester be more productive and a step on the way to deciding exactly how I want my grad school experience to turn out.

Programming

All I Need to Be a Better Programmer I Learned in Kindergarten Sometimes the basics can be boiled down to just a few sentences. Sometimes I think I knew more when I was five than I do now. Of course, that’s a lie, but it’s worth thinking about.

Code Fearlessly I think version control is amazing. I’ve been using Git for a few years now (Subversion before then) and I keep all my writing as well as my code in repositories, backed up to Amazon and a VPS. The great thing about version control is how it lets you make mistakes and try out wild ideas without worrying about how you’ll get back to a working state if you break something.

Health and Fitness

The Creative Brain on Exercise I know, I know. Exercise doesn’t come naturally to most of us spending our days in front of our screens. But given how much of our work is creative in nature, it makes sense to take care of our engines of creation. I think the time spent in exercise will more than pay itself back over the years (in saved medical bills and lost work time if nothing else).

How Getting Buff Can Make You a Better Rubyist. In case you’re wondering about whether any of this exercise and diet stuff actually works or not, here’s some evidence straight from the source. This is worth watching even if you’re not a programmer, but just someone who has a normally sedentary work life.

Tim Ferriss on the 4-Hour Body at the NEXT conference I know that so-called “extreme” advice such as provided by Tim in his book always earns a skeptical look, but I find his idea of minimum effective dose quite interesting. If you’re looking for the most efficient ways to change your body for the better, this is a must-watch.

Eat to Live If you’d rather have advice from a medical doctor who’s also changed the lives of dozens (if not hundreds) of people, this book is your best bet. I tend to think of it as more of a primer on nutrition and health in general rather than just a diet or fitness book. It might take you some time to get through it (though it’s a small book) but again, the investment is definitely worth it.

While I want to improve as a computer science researcher I also want to improve as a developer. For me, the fact that we must take our beautiful algorithms, logics and abstractions and express them in terms understandable to a dumb machine is not something to be despised. In fact, I consider it a pleasant challenge and a source of infinite creative joy. I would like my job a lot less if it didn’t involve a significant amount of programming. That being said, how exactly do we level up as a developer? In fact, what does leveling up even mean for a developer?

For the last few months (years?) I’ve been a growing fan of the idea of deliberate practice – the idea that the best way to improve is to take well-defined measurable steps towards getting better where at each step you get feedback as to what you did wrong and how you can do it better the next time. Deliberate practice has been applied by athletes and writers, can we apply it to programmers? In particular, can we come up with something more detailed than “Read code. Write code. Repeat”? Luckily for all of us, Jason Rudolph took some steps on that path a few months ago.

Remember that deliberate practice requires that we have a list of well-defined, actionable goals on our path to excellence. We must know clearly what the goals are and also be able to unambiguously tell if we’ve achieved them or not. Jason came up with a list of simple yes/no goals that will exercise your programming muscles. What I love about Jason’s list is that it combines a lot of what it means to be a good developer. There are goals for learning tools of the trade (different languages, environments and frameworks), goals for learning core concepts (different paradigms and parts of the software stack) and social goals (open source and community involvement). There are a lot of things on the list, but then again, computer technology is a vast field.

Jason’s list is also necessarily incomplete. I’d argue that it’s practically impossible for one man to know all about the computer technology field today. But the good thing is that we have the technology and the community to take one man’s starting point and extend it for our own purposes. Jason’s list is available as a gist on Github and has already been forked many times by people who are using it as their own deliberate practice guidelines. I have my own fork where I’ve fleshed out sections on uncommon programming languages and more theoretical learning goals.

It might be a bit naive to think that just going through a list of programming challenges will make you level up. However, I think the list is a good head fake. The point isn’t really to go and do everything on the list. The point is everything that comes as a side-effect of completing the list. You’ll definitely put in a few thousand hours and churn out thousands of lines of code in a variety of different languages and environments. You’ll expand your mind by learning about programming styles and tools that you would have missed out on otherwise. As you encounter problems you’ll have to ask around on forums, mailing lists and IRC for help. This is important because deliberate practice is useless if you’re practicing the wrong things. In the absence of programming coaches, the global communities of programmers are your best bet to find mentors and guides. If you release your code to the world you’ll gain some street cred, get valuable feedback and maybe even provide something of lasting value to fellow developers. If you follow through on the social and community goals you’ll gain non-programming, but useful skills and meet a lot more people who can point in new and interesting directions. You’ll discover interesting new problems and come up with applications and solutions you might never have thought about otherwise. Maybe, just maybe, you’ll learn enough to level up as a programmer.

As a parting note, let’s all keep in mind that this will not be easy. It will take time and effort. I’m in graduate school so I might be able to make it part of my day job to do some of these things. But a lot of it will have to happen on my own time and energy, when I could be exploring Ithaca’s gorges or watching infinite Star Trek episodes on Netflix. This is even more true for people who have legitimate day jobs and families. We all need to come up with our own reasons for why we want to invest all this time and effort in deliberate practice. But one thing I keep telling myself is that the time will pass anyway and my energy will be spent somehow. I would rather spend it on writing my own operating system than on Star Trek reruns (no matter how much I love Star Trek).