Transference of process or technique

You know how you're always hearing about work-life balance.  It really is a good idea.  You can pull from experiences in "outside" activities to enhance your software development skills/process.


When you participate in other activities like camping, hiking, bicycling, toastmasters, painting, etc you learn new techniques.  You gain insight into that activity that you can likely bring to your software development practice.

Give me an example

For instance, you're into bicycling.  You've picked up different bicycles for different types of terrain/activities.  You've added various accessories to your bike to make the experience more enjoyable.  You carry a back up tube and air pump for emergencies.  Water and a power bar and gel are along for the ride as well.  You've come to realize that you can go farther and faster over more difficult terrain when you're riding with a buddy.  After training for a while you are stronger and have better riding technique, know the bike better and how to adjust gears for the terrain.

Reflecting on the above you ask yourself:

  • Do I have or use different tools for different projects?
  • What accessories can I add to my development environment to make the process more enjoyable?
  • Where's my development safety net?
  • What do I do to keep going while I'm developing?
  • How can a buddy help me go further and faster creating software?
  • Am I better developer now-- that is, do I have better technique now? Do I know my tools better?
  • What would it mean for me to "shift gears for the terrain" in terms of software?


In summary, that work-life balance/outside activities can make you a better developer.

I encourage you to evaluate your experiences from other activities and bring that knowledge to your software development craft.

1 comment:

  1. I've stopped calling it balance and started calling it work-life integration. We'll see how long that lasts. You are very right; you can get a lot of ideas from things that have nothing to do with software development.

    In the leadership program I attend we go on these "Cross Industry Field Trips (tm)". Last week we spent 2 days at Honeywell/UOP a smaller company that has patented 30 of the 36 processes used in oil refining and has equipment in 80% of the world's refineries. How could a law enforcement guy learn anything from the oil industry?

    Honeywell/UOP has over a hundred mini oil refineries where they test their products. Their magic formula is their ability to go from the small scale and grow by a factor of millions to support a refinery over 10 square miles in size.

    What can that teach us about software development? A lot. Do you build "mini oil refineries" to test your software and scale it up? Maybe we should.

    Good stuff man, good stuff.