Productivity for Programmers, #2: Efficient vs. Effective

Bob Walsh and I are writing a series on Productivity for Programmers, which started with his article Productivity for Programmers, #1: Trusted Systems. In it he identified five trusted systems every programmer should have: Tasks, Decisions, Version Control, Code Snippets, and Bugs. I like Bob's break down (no, not the psychological one resulting from writing "Clear Blogging" - different story), so I want to talk about a related characteristic - Efficiency vs. Effectiveness.


Efficiency

The trusted systems are important, and they are about doing things right, what Drucker called "efficiency" (see David J. Anderson's article Drucker on Effectiveness for a bit more).

In this sense, doing things right means not making people (or yourself) angry because something bad and preventable happened. This is like the The Joel Test applied - You use a source control system (otherwise you could loose your precious baby), you have nightly builds (otherwise you won't know you've broken the build until much later), you have unit tests (otherwise you won't know you've hosed something accidentally), etc.

Similarly for actions/commitments - you should use something like Getting Things Done (otherwise you won't know what you should be working on, and something will fall through the cracks).

Also, your actions/commitments tracking should be integrated with your code-writing and bug-tracking processes. For the former, I strongly suggest an agile methodology like Extreme Programming, which uses stories (further broken down into tasks) to organize programming work. (A great starting point is chromatic's Extreme Programming Pocket Guide - short and concise.) To integrate the two, either block out regular time daily for coding and bug bashing, or transfer story tasks and bug fixing activities to your actions/commitments system - paper, digital, what have you. (I like paper, in spite of my technical bent, but with GTD it doesn't matter. Do pick a self-management system that works with your tools.)

For code snippets use whatever tool you like. I use my patented semi-structured Big-Arse Text File, but wikis and spreadsheets work fine too. In my file I have lots of tips, tricks, and hints, including how to start the database server in debug mode on windows, and the shell command to find text in files (I can never remember the syntax for using find with grep. I can't help it - it's genetic, but marks me as the unwashed...)


In my last job, we set up all these, with great success. It was very comforting getting email at 2am from our cron job saying the build broke, or that a test unexpectedly failed. And having all those unit tests (yes, even the GUIs were test-driven) made my boss very happy. (Not to mention what a mind-blower it was switching to writing tests first; you have to check out Test-driven development - really!)


Effectiveness

So if all that's about being efficient (an important aspect of productivity), where's effective come into play? Drucker's thought was working effectively meant doing the right job (vs. doing the job right - see above). In XP's terms, it starts with the stories being customer-driven. Customers are the ones who get to decide what's important (i.e., what has high business value), with us programmers providing what we know best (technical expertise that guides implementing the whole thing).

But beyond that, you should think about your greater contribution to the organization. You should spend some time every day connecting with the higher-level mission of your business, and thinking about the novel and innovative solutions and tools no one even knows they need yet. This is what moves us from vanilla programmers to more valued "knowledge workers." (The test: are you being told what to do, or are you figuring it out? The latter is what I understand knowledge work to be. The former is more in the "please outsource me" category![1])


So...

So how to do this? First, stop reading now, go out and buy My Job Went to India: And All I Got Was This Lousy Book by Chad Fowler, and read it. Don't let the title fool you - this is the book I wish I'd been handed when I started twenty years ago programming. It's a mind blower; highly recommended.

Second, start (or continue) to stay on top of technology, news, tools, and trends. These are a great source of ideas, and can get you asking those higher-level questions with high value.

Third, give yourself a 20% day [2] - little skunkworks programs (esp. tools that empower others, automate repetitive tasks, etc.) are healthy to work on - both for you and the organization.

Finally, consider starting your own little "Operation Bear Hug" (from Who Says Elephants Can't Dance? by Louis Gerstner - on-line here): visit or call five of your customers, listen carefully to what they love and what they hate about your program, show them you care, then think about whether there's a small change you could make that would implement one of those things, i.e., either add something they'd love, or fix something they hate.


That's about it for now. In the next few posts I'll continue the Productivity for Programmer theme with some highlights from My Job Went to India, then a post about networking tips for geeks. Cheers!


References

• [1] For more on making yourself "untouchable," check out these ideas from The World Is Flat: A Brief History of the Twenty-first Century by Thomas Friedman: The four categories of people whose jobs cannot be outsourced:
  • special - (only a few people) CEOs, stars, sports
    
  • specialized - knowledge workers whose skills are always in demand and not fungible (fungible: work that can be easily digitized and transferred to lower-wage locations)
    
  • anchored - (most Americans) work that must be done in a specific location, involving face-to-face contact with a customer, client, patient, or audience. but there are fungible parts
    
  • really adaptable - constantly acquire new skills, knowledge, and expertise - must be able to constantly create value - make the latest thing in field. adapt as parts of work become fungible. knowing how to "learn how to learn" will be one of the most important assets any worker can have
• [2] From Google's employment page:

  Google engineers all have "20 percent time" in which they're free to pursue projects they're passionate about. This freedom has already produced Google News, Google Suggest, AdSense for Content, and Orkut - products which might otherwise have taken an entire start-up to launch.

  
  

Comments

[Anonymous]

thanks for posting this....it helped me a lot...

[Matthew Cornell]

Glad to hear it, Anonymous. Thanks for reading.