I think a career is comprised of steps. Some are small and some are quite big. The small ones tend to be more tangible, things like learning a new language, a new design pattern or some new tool. While they seem big at the time, really, they’re just newer ways of doing something you’re already trying to do. Still a step forward, just a little one.

I think the bigger steps are also changes in the way you do things, just on a much higher scale. Test Driven Development would be an example that comes to mind. Still writing code, just changing the way I think about it.

Maybe that’s a bad example…no, that’s a bigger step than using, say Eclipse, instead of Visual Age for Java but still not a BIG step.

I don’t really have an expression for them but two big steps have come to mind recently. The first is the notion of getting others involved in what you’re working on. I see (and used to be) so many software developers working within their own little world. They sit at their machine and cut code all day. Agile is supposed to alleviate this a little, getting customers involved (a great idea) but leaves an element out. The developer in that case is often still left with a screen full of their own code. Pair Programming is a start, but it’s still missing the step. The step I’m referring to is when a developer wants other people in their code, wants their peers to see what they’re doing. Code Reviews fail in this respect in the same way as pair programming: it’s usually someone else’s idea. Yep, a developer (or at least this one) should want people to look at what they’re doing. Developer’s should stop looking at what they do as being the trade putting insulation behind the gyprock. Developers need to see themselves as (using the same metaphor) cabinet makers (or any trade with a precise skill under constant scrutiny).

That’s the first one.

For the second step, you need to listen to a little story. I’m an alumni of NOLS, having spent time kayaking with them in the Sea of Cortez. The most significant lesson I learned on those travels was the concept of Leave No Trace (lnt). A lot of the lnt princicples can be applied to software developmet. What are some “traces” that I would consider trying not to leave?

-Major server configuration changes
-Additional memory requirements
-newer hardware
-container classpath changes

This list could go on forever. By trying to apply lnt principles to software development, the developer needs to use their mind to devise creative ways around environmental constraints. This way their application can be moved from server to server and deployment won’t be an issue. Deployment can just happen. The tents come down and the next camper doesn’t know you were there (so to speak). I want to continue trying to make this step. With the falling costs of disk space and memory, the temptation will always be to write less efficient code and place the burden on the infrastructure. tsk, tsk I say. Chopping down one little tree does have an impact.

To summarize: Invite lots of people on the camping trip and leave the campsite looking like you were never there.

Originally published at http://jamiemcilroy.wordpress.com on March 31, 2005.

Husband and Father. Wilderness First-Aid Certified. Terrible at tying knots. I play Squash. I like things that Trade. Leafs fan. FRC and Scouts Canada