Sometimes it's not possible to fix everything at once, or to fully fix things at all. This is especially true of human behavior. In Changing Fearlessly I talked about focusing on a single change at a time. Even with a single change though, sometimes I can't get anywhere near a perfect outcome.

I'm starting to believe that often it's optimal to contain undesirable elements rather than try to eliminate them.

This comes up all the time in coding. There will be a mess of code that you simply don't have the time to rewrite properly. Rather than put the whole project at risk by attempting to be perfect, you compromise. Isolationg the dodgy code as much as possible effectively contains it until it can be dealt with in the future.

For 6 weeks I've been following Tim Ferris' Slow Carb Diet. There's a lot of things I like about it (its simplicity, its effectiveness) but what's surprised me is how it is now incorporated into my life. Of course all dietary changes are meant to be long term, but this is the first time I can remember where I'm not waiting to hit my goal so I can loosen up on the rules. This is in no small part because of the "go nuts" day, where you are required to eat like crap. This effectively contains my bad dietrary behaviour to a 24hr period.

Containment serves two purposes. The most obvious is that it puts a limit on the amount of damage that the behaviour can cause. It also acts as a reminder of the cost of that behavior. If you loosen up the rules gradually you don't always notice the negative results. But when you purposfully cram it into a short time period, it's a stark reminder of what you're controlling. I feel like shit after my "go nuts" day and that's a great reason to eat properly for the rest of the week.

I've had some success applying the containment idea to sleep. I have a horrible habit of staying up way too late: for around 3 years I didn't get more than 5hrs sleep/night. Now, I'm in bed by 11pm 6 nights a week and stay up stupid-late on the 7th.

My next challenge is to apply containment to TV. Like eating crap and not sleeping, it's an insidious behaviour that I get some joy from, but at too high a cost.

Slowly, I'm building up a complete day of bad behavior. Eat badly, watch too much TV, don't exercise, don't sleep. It's a perfect synergistic storm of self-destructiveness, which frees me up to live the constructive life I want to live the rest of the week.

By containing, rather than trying to eliminate, I'm finding it much easier to make meanful changes.

Permalink | Leave a comment  »

There’s a golden rule though: only change one thing at a time. Even if you have the mental ability to keep track of willy nilly changes all over the place, your tools, particularly souce control, won’t. That’s fine if you get everything right, but if you have made a whole bunch of unrelated changes since you last committed, unwinding the broken from the good can be a nightmare. 

Sometimes you get distracted. You’re really motivated and you’re finding all this code that needs minors fixes. It’s easy to forget to commit logical chunks of work and when you finally remember, it’s too late. All that motivation may have led to some good things, but it’s created a tangled mess as well.

Some days I wake up and decide “this is crap: I’m going to fix things”. I clean up my eating, start exercising, go to bed earlier, watch less TV. Then a few weeks later, it starts to fall apart. Things have improved, but it’s too much to keep track of. I forget everything I’m meant to be doing. Or sometimes, two goals conflict (say exercise and sleep). More often than not it all falls in heap.

I’ve realized that I have to limit myself to one change at a time, to give my mental tools a fighting chance at keeping up. I have a list of changes I’d like to make and I don’t start on the next one until I’ve bedded down the current one.  

But just like it’s hard to leave a bit of code broken until you finish what you’re doing, it’s hard to keep doing something that you know is keeping you in a place you don’t want to be. It takes more willpower to not start the next task than it does to complete the current one.

The effort is worth it. Although I don’t have the measurability of unit tests, or the history-rewriting of source control, sticking to a single change is letting me tweak, redefine or even drop a goal mindfully. That makes each change much less intimidating. I’m not changing my entire life, I’m just  a small aspect of it. I can approach each change, fearlessly. 

Permalink | Leave a comment  »

This article put me in the mood to read some fiction. It also also got me thinking about

 the patterns that appear in my life when things are going well.

I've spent time thinking about my anti-patterns: what it looks like when things are going wrong. But other than "not like X" I haven't thought much about what the good stuff looks like.

In the same way that smiling can make you happy, I'm starting to find that doing the things I do when I feel best helps me to feel, well... better. That sounds obvious, but there is some subtlety: the activities that I assume "make me happy" aren't necessarily the things I do when I am happy.

For example, I love a good argument, or sometimes even a bad one. I'm also partial to ranting. But the happier I am, the less I do both. They are ways to release frustration and to exercise my mind - when I'm fulfilled I rarely need either. There's a lot of others activities in the same category, like: drinking a lot of coffee; keeping up with the tech scene; buying gadgets; and getting caught up in politics.

So what do I do when I'm happy?

I read or listen to books, mostly fiction. I learn about non-technology fields, like history and economics. I drink more tea than coffee, and more water than tea.

I spend a lot of time with my family and doing stuff around the house. I rarely get frustrated with the kids. I exercise and eat well, not because I'm trying to acheive something, but because it's fun and feels natural. I catch up with friends. I get a lot done at work.

I worry less about why things are they way they are. I don't sweat the details.

Making myself 'act happy' isn't easy. Like any change in behaviour, in the beginning it takes a lot of conscious effort. It does seem to be developing a momemtum of its own though and I'm surprised at how well its working.

Permalink | Leave a comment  »

Four years ago, my Dad died unexpectedly. That kicked off a challening few years for my family and I. Both our sons were born; my Mum died; we moved interstate a couple of times; bought and sold a few houses; my wife and I both changed jobs; we had some friends diagnosed with termial illnesses and others commit suicide. It's been pretty full on.

In general I'm good at handling stress and change but this has stretched me, at times to breaking. It feels like my resilience been gradually worn down to where anything unexpected can bring me crashing down.

Failing gracefully is about knowing that unexpected things will happen, and having measures in place to deal with them. In software dev, that means (amoungst other things) proper exception handling.

Taking my queue from that, I tried indentifying situations that I was handling poorly. It worked fairly well: I'd notice things going down a certain path and stop it before it got ugly.

As much as this was progress, it was the life equivelant of dumping the exception stack trace to a log. Sure, I may have stopped the spectacularly messy crash, but I hadn't done anything to deal with the underlying cause.

Lately I've started meditating. It is, in essence, debugging my brain: removing some of the chaos and disorganisation. For me it's not spiritual or religious: it's purely pragmatic. And, just like with code, investing a bit of time to clean out the cruft is helping things to run much more smoothly.

Permalink | Leave a comment  »

The hardest part isn't keeping warm: it's making sure you don't overheat. The obvious temptation is to put on as many layers as possible so that you're comfortable when you get on the bike. But then, 10 minutes down the road you start to sweat, the sweat soaks your clothes and combined with the windchill, freezes you.

I've never consistently cycled in a Canberra winter before. So how on earth am I going to work out what I need to wear? Simple: I've started tracking the temperature, my clothing and how comfortable I was for each ride. That way I can check the weather, then look up similar conditions in my dataset and get a good idea of what has worked in the past, and what hasn't.

This idea indirectly came from my last job. The project manager and I were concerned about the amount of work our team was delivering, but didn't have any solid metrics to go by. After quite a bit of thought we came up with a way to measure the percentage of the team's time that was spend directly delivering on the work program. It was quite a hard metric to collect, but it was the one that mattered the most.

That you manage what you meaure cuts two ways: if you want to manage something, you need to measure it. But also you'll start to manage whatever metric it is that your collecting, even unintentinally. We knew this and didn't want to fall into the trap of managing something we could measure, rather than measuring what we wanted to manage.

For example, we could have chosen lines of code or service requests completed. Both would have been easy to calculate and would have given us a rough idea of the state of things. But improving those metrics wouldn't necessarily mean the team were performing any better. All other things being equal, what we really wanted was for the team to spend as much time as possible delivering on the work program, so that's what we measured. Of course that measure is open to abuse too, but overall it provides a good balance.

I wasn't around long enough to see if those metrics helped improved the team's delivery rate, but it certainly focused discussions on where time was being spent and how things could be done differently.

Now, when I don't have enough knowledge about something, I do my best to measure it. For cycling clothing that meant taking 15 minutes to set up a Google Docs form where I can easily enter the data for each ride. To manage my sleep I use Sleep Cycle, which records the amount of sleep I get and provides a running average. I use Runkeeper to track the average speed and monthly total distance for my cycling. Driving around with the trip computer set to show fuel consumption is a great way to get me to drive more efficiently.

I'm not a stats nerd (really!) but having the right metrics helps to motivate me and keep me on track. The trick is making sure that I have the right metrics.

Permalink | Leave a comment  »

But boy, it sure was fun. Even though at times the process was frustrating, getting a device to do something it was never meant to was remarkablly rewarding. I leant some new things and had some of my Unix knowledge refreshed.

There have been articles written about the importance of play in adult life, but I've never bothered to read them. I mean, of course play is important: that's obvious. But this recent geeking out made me realize that I don't actually have that much play in my non-technical life. I rarely do things just because I can.

Pointless, fun play is so important to my professional life. If I didn't just get in and mess with things, at work and at home, I wouldn't have been exposed to a lot of things that have been valuable in my real work.

I'm not sure how yet, but I'm going to insert more random exploration into my home life. Plan a little less, experiment a little more. And  just see what comes of it.

Permalink | Leave a comment  »

"She's learning the spaces she leaves have their own things to say" - Ani DiFranco

No matter the size of the time gap, I've got it covered. Audiobooks on my cycle to work, podcasts while I'm doing housework, Twitter and mobile browsing whenever I feel like it, and an ebook to read or a game to play when I'm waiting for lunch. It's pretty amazing: I can effortlessly ensure I have no time during the day to think.

In software design, too many features can distract from the core purpose of an application. It's called feature bloat. Software companies like Apple and 37Signals are finding huge success by knowing what to leave out. Applications like WriteRoom (and DarkRoom) are popular precisely because of the features they lack.

It's a mindful trade-off between potenital ability and directed focus.

For the last few weeks I've had a rotten flu. Constant headaches and an ear infection stopped my usual information consumption. By the time I was on the mend, the habit was broken.

My mind cleared from the flu. I started to think.

One night I sat on the kitchen bench for maybe an hour, remembering our completely unplanned week-long honeymoon drive around the Western Australian south coast. On the way to work I started thinking about side-projects I wanted to start, getting completely lost in my imagination.

I'm not going to completely disconnect: I get a huge amount of joy out of the infomation I consume. But it's clear to me that I'm missing the space to use what I learn effectively. I'm missing the space to think for myself.

So I'm turning off features that I thought I needed, but never really used. Unscubscribing from podcasts, unfollowing on Twitter. But most of all, I'm creating time where there are no distractions and nothing to do. But think.

Permalink | Leave a comment  »

The first 3 C's are obvious. A solution should solve the problem (be correct) with as little effort as possible (be concise) while being as easy as possible to understand (be comprehensible). The last, not so obvious C is compromise: in almost all cases an elegant solution will have to break a 'best practice' rule.

In FizzBuzz there are compromises made to balance conciseness and comprehension. For example, not using {} to enclose the "if" statements. That is a superficial, stylistic choice. But the use of a temporary string, and the use of the += operator on it, both have the potential to impact performance. The more technically correct method, in Java and C# at least, would be to use the StringBuilder class, or to not use a temporary string at all. Both of those options make the code ugly to read and in most real-world situations the performance degradation would be imperceptible.

The 4 C's hold up well when applied more broadly. To bring elegance to my career path I needed to change organisations. Where I was, the ability to achieve my goals at all (correctness) was questionable, and it was certainly not going to be easy or easily understood. So I went looking for, and found a job that satisfies the first 3 C's nicely. The compromise component was difficult: I had to reduce the amount of time I spend with my family as well as move from a into the private sector.

But already we have a noticeably better, more elegant life. I don't worry about work when I'm home, so I'm more present when I am with the boys. I've started cycling to work which frees up the time I used to spend at the gym. There's bonus elegance points here, with my exercise providing both fitness and transportation. So far it looks like those compromises were the right ones to make.

Too often I've seen people (myself included) let dogma about the detail stop them from reaching the broader goal. An organisation doesn't (or shouldn't) want a good CMMI score, it wants to make great software. My goal isn't to spend lots of time with the boys, it's to be the best dad that I can.

The 4 C's are a valuable tool for ensuring decisions, about coding or otherwise, are focused on producing an elegant outcome.

Permalink | Leave a comment  »

In software development, refactoring is the process of improving how code is structured, usually because the original implementation was sub-optimal or the circumstances in which the code is being used have changed. The aim is elegance: that subjective and elusive blend of functionality and simplicity.

My family recently decided to set a ‘theme’ for 2010 - a guiding concept for the decisions we make through the year. We chose “simplicity”, but it has since occurred to us that what we’re really after is elegance. I want to move through life with as little resistance as possible, while still achieving and growing and living. That means cutting things back to their simplest yet most functional, removing the accumulated cruft, reforming into the optimal shape.

One of the interesting things about elegance is that it is underpinned by a clear purpose. While you can superficially simplify, you cannot hone down to the core functionality without knowing the exact purpose. In order to work towards creating an elegant life I need to clearly define what I want to achieve, which obviously has been rattling around in my head a little lately.

Essentially, I want to refactor my life.

Although I know how to refactor code, applying those same principles to my life is sure going to be interesting. But I like it as a metaphor because refactoring is most effective when it’s incremental and constant. Small achievable improvements done regularly, rather than wholesale re-writes, sounds like a pretty good way to approach life.

Permalink | Leave a comment  »

As a professional developer I know a fair amount about creating good software. But as a relatively new dad (and at 30, a relatively new grown-up) I'm still leaning an aweful lot about creating a good life.

This Coding Life will contain a series of articles focused on taking the principles and strategies I use in my career and applying them to my every day life. My experience so far is that applying professional rigour to my personal life helps make it more elegant, useful and enjoyable. Hopefully, that will continue...

Permalink | Leave a comment  »