Real Productivity

by Gregory Brown

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.


10 Comments

Jim
2007-11-09 06:21:10
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.
Gwyn Morfey
2007-11-09 06:24:29
"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.
amy (not hoy)
2007-11-09 07:45:06
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.


Lori
2007-11-09 08:09:26
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.
Gregory Brown
2007-11-09 09:48:14
@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.

amy
2007-11-09 18:46:00
@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. ;-)

Gregory Brown
2007-11-09 19:03:29
@amy,


I know where you are coming from... but maybe you're thinking too much. :)

amy
2007-11-10 03:22:02
@gregory: i'm sure you're right. but you started it! you and your toaster of doom... ;-)
Joe Grossberg
2007-11-10 09:35:14
"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.

ngw
2007-11-10 09:57:24
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