Monday, February 16, 2009

Code Freeze 2009

I just noticed this in my drafts. I started writing up some details around Code Freeze, and then just left it sitting there. For some reason, I thought I had posted it. I'm only posting it now so it gets indexed and I don't forget the books/links I was interseted in from the conference...

Last week, on a day so cold we stayed in the sun while walking to lunch to avoid sticking to the sidewalk, a number of us from work attended the University of Minnesota Code Freeze 2009. In the past there have been a few coworkers there, but this year there was a complete contingent, including two coworkers who were coordinating the conference, folks from my department, folks from Findlaw, alumni of Findlaw, a folk from TTA, and others from the content area.

I've been to two other Code Freeze events in the past and the scope of the topic is generally pretty broad "Innovation" in 2008 (with a lot of Agile talk), "Global Systems, Global Development" in 2007 (with a lot of offshoring talk), and "Maximizing Developer Value" this year (a mix of how not to get interrupted, agile, estimating, testing and the odd other topic).

Neal Ford spoke on "On the Lam From the Furniture Police". I thought he was by far the most interesting speaker and his presentation was enjoyable with a good sense of humor and specifics about how to avoid "context-switching" as a developer, that problem we've all had that we just get going on code when someone drops by to talk about something completely unrelated. It's not just a developer problem. It happens to everyone. It even happens to managers, as I can attest in my recent role trying to coordinate two distinct workstreams that kept stepping on each other. When I worked with our large, priorprietary database, I worked with a dozen partners at once and seldom had issues with flipping from project to project (to project to project) even within the same few minutes. However, when I was doing the role of a data analyst and my standard role earlier in that job, when I had much less work overall, switching between the two roles often threw me for ten or fifteen minutes each time I moved from one to the other. It's interesting that context switching can be context specific.

Ford also talked about the value in engaging both sides of your brain, the logical and the holistic (intuitive, call it what you will - the side that says "aha" about problems). He then related this back to context switching by pointing out that it took a lot of work to get your right side engaged while coding, and context switching was death to your aha moments.

So what does Mr. Ford offer as ways to reduce context switching and engage right brain thinking? Toys - provide some little toys and brain teasers so that the left side of the brain is engaged in a repetative activity allowing the right side to override the noise. Get rid of "pin prick" distractions. Turn off your notifications. Use a tool like Tweak UI to turn off balloon tips. Employ a screen dimmer like Jedi Concentrate that ensures the window you're working with garners your attention. Use tools to track relationships like an external brain (he called it an exo-cortex): a notebook, Personal Brain (perhaps useful for writing a novel as well), Larry's Any Text File Plugin (in conjunction with Google Search), and using Rooted Views.

Use automation and continous integration to cut down on unnecessary distractions from your own code. Use virtual desktops to mimic how you would lay out papers on a larger desk. Have walking meetings. Exercise. Take a nap at 3:30 each day. Don't work in a cube. Avoid sitting where the noise is heterogenous instead of homogenous. I see this last one in effect at work almost every day. We have developers who work on a particular type of project and they seem very capable of flipping between those projects and avoiding the context switching associated with many projects, although we have initiatives to try and ensure that any one person is on a minimal number of projects for that reason. However, in the same area are developers who are on completely different types of work, whose day-to-day worries are more along the troubleshooting line, tackling a problem of the day, or a tricky hardware issue. When they meet to discuss the issue of the day, it can suddenly engulf everyone nearby, even developers from other areas who can't avoid the heterogenous noise.

Books mentioned:
Andy Hunt: Refactoring Your Wetware
Pragmatic Thinking and Learning
Peopleware: Productive Projects and Teams
Raston - Human Interface (locus of attention)
Flow: The Psychology of Optimal Experience
The Productive Programmer

Nate Schutta - Hacking Your Brain for Fun and Profit
Nate was the second presenter, and the only other one I want to talk about. Susan Standiford, Andy Miller, Tomo Lennox and Luke Francl were interesting, but they weren't on topic with anything that resonnated with me. Nate continued Neal's presentation in some respects, focusing on what there was in the brain of a developer that lent itself toward productivity. He focused on some of the physiological effects of not sleeping enough, not getting enough exercise, email apnea, and continuous partial attention. He offered up solutions such as no-meeting Fridays, f-off flags (in use at TR in a few places), and a zero inbox. All great ideas. While talking about the importance of sleep, he referenced these amusing videos of Peter Tripp staying awake for 8 days.

Part I -
Part II -

Books mentioned:
Brain Rules
A Whole New Mind
Mind Hacks
Your Brain: The Missing Manual
Lifehacker (GTD)
Getting Things Done
Pragmatic Thinking and Learning
43 Folders (web site)

No comments: