Today I discovered the podcast “This Developer’s Life”. It’s a very differently crafted podcast. Very true to the style of "This American Life” that it’s name is borrowed from. It is more in a story telling venue, better production quality, not about API’s or even craftsmanship, but rather “common” themes to lives programmers.
I listened to Episode’s “Play” & “Problems”. They are nice, but it stirred in me an issue that first surfaced last year at Tech Ed South Africa, when I attended a presentation that presented this clip from the Movie “The social network” about being “wired in” and then stated this is the best way to be productive. I remembered nights or days with my headphones on, programming in the zone, but I could NOT remember the last time I actually programmed with headphones. I don’t work that way anymore.
“Play” also described this state, but mentioned that it was hard to get into with programming. They argued that racecars could instantly move you into it, but code was more haphazard about when you’d get into the zone.
“Problems” talked about what I consider to be the opposite effect;Bugs and the frustration and confusion they bring about. They also talked about the lack of satisfaction when the bug is finally found. Techniques to build up success, when to quit or undo.
The Old Me
I remember a time when this felt very familiar. In fact most of my younger years identified heavily with these anecdotes. I use to say “you have to love programming to be able to survive because bugs are so frustrating.” However, this whole thing was more of a nostalgic experience for me. In fact, I found myself shaking my head often, wanting to correct the process. For example, In the “Problems” episode, when they are talking about the bug introduced while programming in Sinatra, all I could think was “use Git Bisect”.
I’m not sure exactly when the changes started and I became proficient enough in my new skills and attained enough discipline that I stopped having these experiences. And I should note that they haven’t stopped completely, I still have relapses sometimes, but they are much much fewer and father apart.
But I do know why I have changed.
The New Me
Nowadays, I am almost constantly in the zone when I’m programming. I rarely fight with a bug for hours, and almost never if it’s an regression bug, in fact 10 minutes is a long time for a regression bug.
I am more disciplined than ever in my code, and part of that is focus, and part of that is small steps building up success.
I also am frequently in a state I would describe as “brain on fire” a state of hyper creativity that makes the old “in the zone” feel a bit stale.
The changes have come from from eXtreme programming. I started on this road almost a decade ago in 2002, and I have to search back to around that time to identify with the concepts and stories in the podcast.
There are many practices in eXtreme programming that contribute to the overall effect, and the combine upon each other to get the full result, but I want to highlight the most useful ones. I’ll do it in order of value for me personally.
Pair Programming
When they talk about the zone, pairing brings that almost instantly. I am amazed at how focused I can be when pairing with someone. Email, twitter, other people… it all fades into the background, and the code pops in front of you. Even if a interruption occurs it is quick & easy to regain that focus.
Learn more about pair programming, here & here.
Test Driven Development (TDD)
A clearly stated problem, constant feedback, and regression about twice every minute! TDD has removed the massive hell that bugs by breaking things into nice little steps, and catching you if you slip. Nowadays when something goes wrong I know about it 30 seconds later, and Ctrl+Z is usually the answer.
“The journey of a Million lines starts with a single Unit Test.”
Learn more about TDD here, here & watch a video demo here.
Incremental & Iterative Development
TDD sort of forces you to do small steps in a iterative fashion with constant feedback, but eXtreme programming doesn’t stop there. It uses this technique with user stories, refactoring, continuous integration, source control, retrospectives and many other practices. It’s extremely powerful. Do something small. No smaller. Now add some more.
How powerful is smaller? Let me show you an example from my own history
Books written – 0
Blog Posts – 25
Tweets - 2,621
No comments:
Post a Comment