When I first moved out to Charlotte, I didn’t have much experience working in a corporate environment, and I went along with many of bad practices the company had. Around the same time I picked up The Pragmatic Programmer by Andy Hunt and tried to use the tips in the book. Sometimes I used the tips at the wrong time or misinterpreted principles, but for the most part it helped bring out many of the social and communicative aspects of being a programmer that I wasn’t very good at. Being able to detect a bad situation before things turn ugly can be a lifesaver. It also helped with preventing me for constantly working 50+ hrs a week and not benefitting from it.

That was about 4 years ago. Fast forward to yesterday, where I attended an Agile Carolina meetup. I’ve been a member for about a year, but haven’t attended to any meetings lately. Then I got an email saying Andy Hunt was coming down to Charlotte and was going to give a talk on how to “Refactor Your Wetware”. Odd title, but if it was going to be anything like his books, I couldn’t miss the talk.

For the most part, the talk was less about programming, and more about we operate as people. It reminded me a little bit of when I took psychology courses, but used with metaphors like CPUs, shared buses, and memory to describe how our brain works. Here’s a couple of points I found interesting about the talk:

Aesthetics affect cognitive performance.

There’s a reason why you should get up and walk around when stuck on a problem. Dwelling on it in the same space won’t solve them. Brining in other senses by stepping away from the keyboard and taking a walk, smelling the ink while using a whiteboard, or taking a break to play a video game can help stimulate other areas to help solve a problem.

Write everything down.

Everything. Yes, everything. He maintains a personal wiki, covering everything from daily habits, to one-time affairs. I’ll have to look more into this because it seems interesting. I’ve always used wikis for work, but never in my personal life. I also noted the act of writing is more important than going back and reviewing what you wrote. Sometimes you have to write something and remind yourself multiple times, but other times writing it down once is enough to never have to look again.

Andy suggested that our memories are terrible. He even went as far as saying those memories you believe to be vivid will change over time or possibly never occurred in the way you imagined them. He suggested that even if it doesn’t make sense, keep writing. Use a moleskin, small stacks of paper, whatever. Just keep writing. I suppose the idea here is that the more you notice something and write it down, the more you think about it. Instead of your brain sitting idle, it’s working more and more. Then your brain gets used to thinking this way and you are able to come up with better ideas and solutions. This was probably the most important part of the talk for me.

Failing takes the pressure away.

If it’s ok to fail, then you won’t. A little funky, but makes sense when you talk about unit testing. Basically the first thing you do when you write the test is that it actually fails. So I suppose if we’re already failing at the beginning, that takes some of the stress out.

Handling Interruptions

Interruptions happen all the time and can take a long time to get you back in productive mode. One interesting tip Andy mentioned was getting as much information out of your head before you’re completely interrupted. So if the telephone rings, you’d type out as much as you could before answering the phone. It’s alright if it’s not a full sentence, but the idea is to leave breadcrumbs and be able to pick up where you left off faster.

I’m a left-brained guy (with the right side sneaking out to play guitar), so it was nice to hear from someone who could offer tips on how to improve your wetware. I’m probably the youngest in the group, but Andy presented in a way that was understandable to pretty much every generation of programmer that was there. His book comes out really soon and I’d recommend it to anyone who’s a fan of the pragmatic series. It was also nice to put a face and voice to all the words you have read that helped shape the way you are as a programmer.