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?
Best post I've read all month! I've been learning ruby for about 6 months now and I'm finally at the point of never letting a ruby what-if escape me. Usually I don't have the time to refactor immediately, but now I have lists that I keep as "rewards" for completing the core tasks for each day. As soon as I get through the core list I get to work on an outstanding refactor/test/exploration item. Fun!
Nice post - thanks Gregory.
"don’t let anything slip through the cracks without at least noticing it" resonated with me. My practice is not to optimise things the first time, because it's a waste of time to spend five minutes fixing a problem that's cost me thirty seconds, once. But the _third_ time I mixed up the Expose and Dashboard keys, I labeled my keyboard. The aggregate effect of a million tiny fixes is large.
Can we hear more about that toaster of doom?
I really dig what you are saying about _noticing_ in the buddhist/mindfulness sense. But the other half of that, which I know you probably are thinking about but didn't really make clear in this post, is non-judging.
Noticing every little thing we do 'wrong', every little annoyance in our code, every un-productive habit (reading blogs before settling down to code? no, I wouldn't do that!;-) will not improve our productivity if we couple the noticing with judging. I'm great about noticing, and awful about judging. Oops. I mean: "I notice that I judge myself, and that judging myself is not a skillful means of achieving productivity."
I'm so immersed these days in new ideas (TDD, BDD, metaprogramming, semantic web, ruby), new ways of working (being a web worker, part-time consulting, managing work and my kids, working with my spouse, distributed work, writing about technical topics, and so on), and at the same time having to teach things I've only just learned myself, and yet I still expect myself to instantly grok all the new stuff, instantly incorporate it into my processes and mental frameworks, and be instantly hugely productive with it. for example, everyone talks all the time about how amazingly productive Rails is, so it can be really disheartening when something takes me much longer than i think it 'should' take me to do in rails. (it doesn't help that clients have also heard the hype about rails and don't have the best (okay, any) sense of how timeconsuming software development is to begin with. The difficult truth is that we can only develop as fast as we can develop, that we generally avoid looking straight at how productive we are, because it's much less productive than we think we _should_ be.
So noticing is the first step toward increasing our productivity: really being able to see what we are doing, what we are capable of doing, how we are doing it. But unless we can at the same time learn to be gentle and non-judging with ourselves about what's really there, we will always be fighting an uphill battle to notice it, because it's incredibly emotionally painful to notice only in order to compare ourselves to what we wish were true. So we must learn to notice and to be kind to ourselves about it.
When we quit judging, we can notice better. Fine. This is the state of my code. This is how fast I can work. This is how long I spent responding to a blog entry instead of writing code this morning. Okay. Was that skillful in the sense of advancing my goals, or not so skillful? It's like benchmarking to find the bottlenecks in code. You don't get angry at a select statement for being inefficient. You try a different select statement.
Excellent post. Procrastination about working on a problem in your code is like a code smell. If you are procrastinating about fixing a problem, there's a reason. Identify that reason, and break it down into nice bite-sized chunks using TDD/BDD as exploratory tools, and you are halfway home.
@amy,
You make a very good point, but I'd probably lean towards saying it's better to avoid expectations than judgment. It'd be wonderful if we could look at the technology world and see still water, but I think the reality is far different than that.
When faced with utter chaos and information overload, I wouldn't overlook the value of judgment for narrowing the scope of things. It's when we couple these judgments with expectations of gain that we get ourselves in trouble.
To me, maybe this is the difference of saying "I know that module can't be the problem, so I'll completely ignore it while debugging", and perhaps saying "I don't see where that module could have caused the problem I'm seeing, so maybe I'll start somewhere else first".
I might be splitting hairs here, but I think there is a subtle difference between practicing being non-judgmental in your life and applying that concept to software. Maybe I left that out of my post because I'm not so sure how I feel on that, but I don't really know.
One point you made that is very important is to look on your failings and problems with a certain kindness. I think we lose a lot of good contributions in open source because people try something once, see that it's not as easy as they expected it to be, and then give up. An acceptance that programming really is *hard* and takes patience is very valuable.
@gregory: maybe what you're advocating is more discernment, in the sense of discerning what's truly important,than judging, as in 'this bad, this good'. or maybe you're just less unkind to yourself than I am to myself (and for your sake, I certainly hope so! ;-), so you're able to notice more without such a focus on refraining from judging. I certainly am not advocating producing awful code and saying 'oh well, there's my awful code, nothing I can do about it, I'm okay, you're okay, the code's okay. let's go have a slushie." Just that I think it's very easy to get into a completely neurotic frame of mind which skips right to judging. Which is totally unproductive for me. today, for example, I was actually judging myself for reading and responding to a blog entry instead of coding. But in retrospect I realize what an off day it was for me coding anyway. And thinking about the post and my response were helpful to me in a meta way, even though it looked like I was just blowing off getting my real work done.
I don't know, I probably just have to think about it some more.
anyway, it's good stuff. i see a book about coding and buddhism in your future. ;-)
@amy,
I know where you are coming from... but maybe you're thinking too much. :)
@gregory: i'm sure you're right. but you started it! you and your toaster of doom... ;-)
"So… what is real productivity to you?"
Learning to say "no" to the right things.
I had a designer insist that we have some eye candy that added absolutely no value (other than aesthetic appeal) to an intranet tool and would have taken several hours to implement and many times that to debug.
I said no -- this was a bad use of limited engineering resources. I won. We all won.
I had a speach at RailsToItaly conf last month about productivity with RoR. I think we share a few points.
http://beneathzooppa.blogspot.com/2007/11/railstoitaly-slides-and-material.html