The most important thing I’ve picked up with each RubyConf I’ve attended is a new outlook on my work. Each year the talks invite people to have their minds bent a bit, both technically and philosophically. Though I didn’t take notes and my attention span is usually too low to keep a full talk in my head, the following discussion is largely based on ideas from various talks I attended, especially from Nathaniel Talbott, Eric Hodel, Ryan Davis and Evan Phoenix. It also has some sprinklings from the hallway track, as well as some delusions from the back of my mind. Sorting all that out is up to you.
So what is real productivity? Maybe we can look at it as the coding nirvana that we’re all striving for, but I think it’s even more simple than that. True productivity just involves eliminating apathy from your life, leaving you with nothing left but things you care about, and no choice but to take care of them. What follows is a simple extension of that general idea into software practices.
Know yourself and your needs.
We can learn practices by rote memorization, or we can fake the funk and pretend that some idea we’re holding on to is helping us when it’s really getting in our way. Neither of these things will end up helping us become better programmers, much less happier people.
Here are plenty of examples of things from my own life that maybe some of you can relate to:
- It took me over a year to ‘get’ why TDD/BDD is a good idea.
- I refused to use TextMate for years because I believed there was one true editor (vim).
- I’ve followed community models designed for projects with 50+ active commiters for projects that only had me and casual contributors involved.
- I used to think it was inconceivable to not host all your project services on RubyForge
- I used to care whether or not my projects worked without RubyGems
We probably can’t stop ourselves from getting caught up in this cycle now and again, but when we miss the next bit, we’ve really got ourselves in trouble.
Listen to the world around you
If eight people call you an ass, there might be a pattern forming. Same goes for any serious criticism that pops up again and again. Listening is more difficult than hearing and responding. If you’re skilled at debate, you can present yourself as being correct, justified in your actions, and even untouchable.
But the bottom line is, if you’re still an ass at the end of the day, you’ve only succeeding at saving an ass-face. The funny thing is, this isn’t necessarily a permanent state, some really nice people will surprise you with how bull-headed they can become if they get involved in a flame war on a blog or mailing list. I’m not sure if I qualify as ‘really nice’, but I’m probably ‘nice enough’ and if you search some Ruby archives, you can find more than a few instances where there is no evidence of that whatsoever.
This almost always is the result of failing to really listen. All it takes is a second of hearing what you wanted to hear instead of what someone actually said, and you’re off on a dead end path.
But this isn’t supposed to be a lecture on kindness or ethics, it’s about productivity. Getting mad about technical or philosophical issues rarely results in growth, so cutting it out of your life will inherently make you more productive.
Here’s what’s more: In this global community of hackers, we have limitless access to criticism from very smart people. That’s a very powerful tool, if used right.
Be meticulous about your practice
Some of you may know that I spend a lot of my non-coding time studying Buddhism. Though this is certainly not the forum for religious discourse, there is an especially good concept I found in one of my Dharma books which I’ve applied to all aspects of my life, including software development. This one is so simple, but kind of hard to keep up with: Just be very rigorous about what you do.
We try so hard to discipline ourselves, to teach different mind tricks that let us be more productive: The various GTD systems are an example of this. However, it’s worth realizing that the core of all of this is just paying attention to what’s going on in your life.
If you find yourself stumbling over a bug more than once and you haven’t written a test for it, write the test. If you can’t do that right away or you don’t know how you’ll do it, write that down somewhere. Noticing that the last hour of your working day always goes way slower than the rest? Look at your schedule and try to figure out why.
Whatever problems you’re having in your code, don’t let anything slip through the cracks without at least noticing it. There is a tremendous difference between thinking “Oh, I should learn how to fix this problem”, and “This is the 20th time this problem has come up, and I still haven’t taken the time to learn it”. The latter lets you know exactly where you stand and how these things effect you, the former is the ‘maybe someday’ trap.
Take care of the small annoyances, and ignore the big things
Whatever happiness we have, it’s mostly relative to how happy we just were. I’ve been playing a lot of the board game Go lately, and it’s really taught me how a single mistake can throw off your mental state and send you tumbling through a downward spiral. Seeing this while playing a game, has allowed me to see it in my work.
Ruport provides a great source to practice this idea with for me. I spent over 2 years focusing on how the whole system would come together and how we’d address the problems of our users and even our mythical potential users, completely ignoring a bunch of the small annoyances.
Recently, I’ve turned that on its head. Now, whenever I see a method that throws back an absurd error that’s completely incomprehensible, I throw in a fix that handles the case better. Each one of those shaves a few seconds off of my thinking time every single time I encounter the problem again.
Sure, maybe there is some big shiny thing in the future that will make my life better, but it’s probably expensive, and it probably won’t pay off right now. The small stuff does.
That’s all for now
Here is where I start to run out of steam. Maybe it’s because I’m tired, or maybe it’s because if I keep on rolling, I’ll deviate completely from technology and start talking about the divine theoretical toaster of doom, or something even more absurd. But really, what I’m interested is what kinds of things influence your lives as developers, and some of the thoughts and practices that drive you to be productive and happy.
So… what is real productivity to you?