On Being A Journeyman Software Developer

Being honest vs Making excuses

noreply@blogger.com (Corey Haines) — Sun, 07 Aug 2011 16:30:16 PDT

The other day, I was involved in a conversation with a group of developers. Several of them work at a large company whose product is built on Ruby on Rails. We were talking about the development environment there, specifically the test suite. The codebase is quite a few years old and has a very slow test suite in part due to some design issues in the codebase. I asked what their test suite was currently running at, and I don't remember the exact figure, but it definitely had a lower bound at 30 minutes (I think it might have been an hour). I then asked about just the unit test suite, the one you should be running frequently while developing. The speed for that was on the order of many minutes. Someone else then asked how it was to run a single set of examples, the type that's focused on whatever part of the codebase you're actively working on, the type that should be run almost constantly while writing code. This was 'better,' being on the order of 30-45 seconds. I remarked that this was still horrible, especially when working on a piece of the system that didn't need specific features of Rails*. One person remarked that this was inevitable with a large codebase. I disagreed. That is, I disagreed with the statement that the size of the codebase was the cause. Slow unit test suites and the inability to quickly run focused subsets are an indication of a design problem with the codebase, not the size. As we talked more, I started to notice something that I've seen before but had a hard time placing: extreme rationalization of bad situations.

This got me thinking. Often times, we choose to be in certain situations and then, rather than admitting that the situation is bad and dysfunctional, then convince ourselves -- and justify to others -- that this is the only way it can be. While we are free to choose trade-offs for whatever situation we place ourselves in, it is important to be honest with ourselves about the causes of the situation. For example, the above company has interesting computer-science-types of problems which makes up for the bad situation regarding the actual development process.

If we are not honest about the causes of a bad situation, we pose a significant danger to those who are either less-experienced or uncertain about their own situation. Take a slow test suite, for example. Having a test suite that actively hinders a developer from running portions of it while developing is a deterent even to run the suite at all. As the run time climbs into minutes, the test suite becomes an antagonist, rather than the helper and guide that it should be. Instead of rationalizing, say you have some serious design flaws in your system. Or, say you have a large codebase and a huge team consisting of people with varying desires to write automated tests. When we mask the real causes of a problem, it has the potential to confuse less-experienced developers who look to us for guidance. For example, thinking a slow test suite is inevitable could stop someone from asking for help optimizing their own codebase while there is still time. If you are talking to a less-experienced developer and you mask the fundamental problems, what message are you conveying to them?

The point of this post is not to point out how people are wrong or that you have to fix, or are able to fix, a bad situation. I just want to raise a reminder that there is a difference between rationalization and being honest with the reasons for something. By rationalizing, we are fooling ourselves and those who learn from us into thinking that you can't do better and it isn't worth trying. By being honest with the reasons, we have the opportunity to both learn from our mistakes, and teach others what pitfalls might await given certain decisions.

So, the next time you find yourself talking with someone and describing a less-than-optimal situation, ask yourself whether you are being honest about the causes. It doesn't mean you have the power or inclination to fix the problem, but talking about the causes can lead to valuable conversations about how we can do things better in the future.

also... can we stop using the terms 'ivory tower' or 'real world' when rationalizing our situations? As DHH said, "The real world isn’t a place, it’s an excuse. It’s a justification for not trying." (other inspirational quotes)

*In fact, I will put forward you can't do an effective test-driven development cycle with a feedback loop that long.

As always, thoughtful comments are happily accepted.

My talk from SCNA2010

noreply@blogger.com (Corey Haines) — Wed, 23 Mar 2011 12:14:31 PDT

I was honored to be asked to give the closing talk at the Software Craftsmanship North America conference (SCNA) last year. It was a fantastic event filled will great thought, exciting conversations and wonderful people. This was the talk I gave introducing the idea of positivember.

Dates have been announced for this year's version of SCNA, November 18-19, 2011, so make sure to go check it out.

The video from my talk has been put up, so I wanted to share it. You can watch it on this page, full screen or click over to vimeo to watch it.

SCNA 2010 / Corey Haines from Brian Pratt on Vimeo.

Turbulence, measuring the turbulent nature of your code

noreply@blogger.com (Corey Haines) — Wed, 02 Mar 2011 05:37:47 PST

Recently, Michael Feathers has been investigating the idea of mining all the data in our source code repositories to start finding information about our codebase and system design. He wrote an article about possibly using a churn v complexity chart to look for areas that could use some refactoring love called "Getting Empirical about Refactoring".
Since he has joined Obtiva as Chief Scientist, he is here in Chicago fairly frequently. I had the pleasure of spending a morning with him, and we naturally talked about his ideas. I was inspired to build a short bash script that generated a churn graph for my own codebase on MercuryApp. Chad Fowler took my short script and merged it with a script he wrote to run Flog over the codebase. While Michael, Chad and I were in Boulder, CO, for a coderetreat this past weekend, we put together a project called Turbulence.

Turbulence is a gem that you install and run in the directory of your code. It does a churn report, combines it with Flog data, and generates a nice scatter plot view. You can find instructions on the Turbulence project page. Although it currently only support Ruby code, we have plans for expanding the project to support other languages.

One goal is to have people take a screenshot of their graph and post it to twitter with the hashtag #codeturb. This will allow us to view the graphs on hashalbum and see what we can see.

Another goal is to have people send us their data, so we can do some analysis on different contexts. If you'd like to take part in this project, please email me. We are working on finishing up an anonymizer function that will mask the filenames, in case you might worry about directory structures/file names giving away your codebase's dirty secrets.

We are also proposing a series of talks at conferences outlining both results, recommendations and tools for helping analyzing your design based on the shape of your metrics. Keep watch for those.

I've uploaded my current graph for MercuryApp, you can see it in all its glory by clicking on the picture below.

On the goals of Coderetreat

noreply@blogger.com (Corey Haines) — Wed, 09 Feb 2011 06:53:33 PST

Last Sunday, I facilitated a coderetreat in Cleveland, Ohio, at the Leandog Software boat. It was a great time, filled with writing code, practicing technique and learning both obvious and subtle lessons. I'm always excited to see people's reactions about the event (for example, here and here), as they gain more insights into their journey. Over the past two years, I've found my own role as facilitator transform into a guide, poking a bit here and there at the code.
The full benefits of coderetreat come clear through the course of a whole day, starting with a session, or two, of understanding the problem domain, then the rest of the day is spent pushing our limits, accepting that our 'normal' way of coding isn't enough, that we should be striving towards an ideal. The format of the day is structured very specifically to allow for this experimentation. This is a reason we start early and I don't support having people 'drop by': we want time to get over the 'hacking away to finish' mentality that normally accompanies time pressure and brings with it the necessary corner-cutting. Focusing on improving our skills over 'getting it done' is one of the primary aspects that sets us apart from just being another hackfest: we are practicing to get better at the fundamentals. For example, we aren't there as a way to primarily practice or sell TDD, we aren't there to work on design patterns, we aren't there to finish the problem. We are there to work on learning better software design skills through exploration of the 4 rules of simple design. This is done through experimentation and exploration.

This past Sunday, Justin Searls recorded my introduction. This is how the day begins and sets the stage for the spirit and goals of the day. Feel free to embed this video into any blog posts you might write about coderetreat.

Enjoy!

Cleveland Code Retreat Introduction from Corey Haines on Vimeo.

'Taking it too far' v 'Taking too much time'

noreply@blogger.com (Corey Haines) — Thu, 09 Dec 2010 13:38:36 PST

Coderetreat is about spending the day writing perfect code. During our day-to-day programming tasks, whether they are for pay or our side-projects, we always have the end goal of getting something done. This inevitably causes us to cut corners, writing less-than-perfect code. Why do we do this? For one, it is because writing the code that we 'know we should write' will take too long. We have to weigh the value of merciless refactoring and ultimate clean code with the reality of the benefit we get from delivering something. At coderetreat, though, the pressure to finish goes away, deleting the code makes it so that you can't finish the problem. This allows us the freedom to act as though we have an infinite amount of time.

As I've traveled around and had the opportunity to work with people of widely varying experience and skill level, I've noticed that the big difference is which corners get cut. For people with less experience, say 1-5 years, the 'get it done' code is significantly different, less clean, than the code written by those with a lot more experience, say 15-20 years, yet written in the same amount of time. This makes sense and isn't a knock against beginners, it is just a good indication that there is always more to learn. The gap between what we actually write and what we think we would write given enough time is always there, just at a different level. As we gain more experience, that gap simply moves upward, so the code is cleaner given the same constraints.

I've facilitated a lot of coderetreats. I've watched people of widely varying skill levels work on the same problem. Some will write very readable code, others will write less readable code. My role as a facilitator is to ask the questions about the code, questioning the refactoring decisions, and, more often, helping people understand why they stopped refactoring.

Suppose you have this method, a very common one used to figure out whether a living cell will die in Conway's Game of Life:

Commonly a team arrives at this and moves to the next test. I'll ask if they aren't skimping a bit on the refactoring and get a response similar to "well, we don't want to go too far" or "this is very readable." I'll generally add a little code:

That is clearly more readable; most teams that see this small change agree. My question is "why did you stop?" The readability also exposes a few other problems, mostly around the method names, but that is a topic for a different blog post. So, the question remains "why is the first form 'good enough'?" After all, the extracted version is more readable, captures the domain better (underpopulated vs a cryptic number comparison) and is not much more work to extract, especially with basic refactoring support.

[Just a note here that this is not the absolute end state of the system, but an intermediate step along the way of evolving the design. If teams get that far, this usually ends up being extracted into another object that resolves some of the design issues inherent in it.]

One hypothesis is that we often mix up the idea of "going to far" with "taking too much time." After all, I would be surprised if someone would say that the extracted version truly is taking it too far. However, I do believe that some people would argue that it might take them too much time to do this all the time. I've worked with people who didn't have a good understanding of their toolsets, so this sort of extraction would take more time: manually extracting it doesn't take a lot of time, but it is definitely non-zero. So, creating code like this is time-consuming on a larger scale, so we don't do it. This, though, is really about "taking too much time."

Another hypothesis is that we aren't comfortable with more abstractions. For various reasons, most of us don't have a great familiarity and comfort with abstractions. One difference I've noticed between people with varying experience levels is a view on abstractions and how they handle them. I like to say that programming is based a lot on just being adept at abstraction wrangling, and my experiences with people has shown me that this has more than a hint of truth to it. As we encounter the creation and manipulation of abstractions, we get a better sense of where they are hiding in the system and how to be effective in drawing them out into the open. A common argument against heavy abstraction is that you then have to jump around the system to see what is 'really' going on. For people who are truly comfortable with it, though, you either don't need to see what is 'really' going on, relying on the names to truly reveal their intent. And, when you do need to see what a specific part of the system is doing, navigation can be a trivial act, due to a clear signpost guiding you to your destination.

These are just musings of mine. I don't have the answers; these thoughts are based on my experiences pairing with different people and watching people of various levels writing the same problem over and over at coderetreats. I'd love to hear any ideas that others have either in comments or as blog posts. I think this is an important topic that can help us understand ourselves better both as a means of accurate self-assessment and developing more effective training mechanisms.

Positivember

noreply@blogger.com (Corey Haines) — Tue, 01 Nov 2011 07:26:59 PDT

At the 2010 Software Craftsmanship North America conference (SCNA), I was given the honor of giving the closing talk, titled "The Long Road Ahead." (watch here) My goal was to focus on where we had come and where we are going as a movement, not only looking into the previous year's activity, but also what might stand in our way of spreading the ideas of craftsmanship to the general programming communities.

As I was preparing, several conference talks influenced my thoughts and the focus of my presentation.

At jRubyConf, Joe O'Brien gave a wonderful talk about how the people around us are not stupid and not worthy of the scorn often laid upon them. Instead, we should consider them experts in their domain helping us better build the software we are hired to make. At the same conference, Glen Vanderberg provided a informed view of the problems with the term "software engineering," and what we might do to establish ourselves as a true engineering discipline, all the while capturing and celebrating the artistic, creative bent on which we pride ourselves.

At SCNA, Doug Bradbury gave a great talk on our inclination to build, to make; we need to get back to our roots, back to our core qualities as makers. Deep down, we are all creators; we start with nothing but a blank screen, and we put our hearts and souls into the creation of something real, something that acts and solves problems. We write new creation myths every day, except ours reach up out of myth and into reality. Chad Fowler gave an inspiring talk on readdressing what we thought of as quality, putting forth the challenge to merge the realms of art and utility. Often, we hear the argument that the craftsmanship principles are unrealistic and potentially harmful to production; Chad's talk was a refreshing counter to these, showing that we can support both.

While there is no 'craftsmanship canon,' these talks, for me, cut to the core of the craftsmanship manifesto, highlighting the fundamentals of what we do and care about. They were wonderful examples of how the fundamentals have crystallized over the past two years. Looking forward, the question of spreading the ideas is moving into the spotlight. The ideals are sound, so what could stand in the way?

Considering the topic of what might hold us back, I watched the mailing lists, I read blog posts, and I paid attention to the twitter stream. I thought about what would set us apart as a movement, and, on a larger scale, what were some hurdles that the software industry as a whole faced. There were a lot of thoughts, but one thing really stood out: we are an overwhelmingly negative group. We complain about our hours, we complain about our jobs, we complain about our coworkers, we complain our toolsets. If we are going to become better, we need to change this.

I believe that a significant factor impeding us in the goal of selling to those around us the care and professionalism espoused by the craftsmanship movement is the negativity we propogate. So, in my SCNA talk, I challenged the audience to take part in what I am calling "positivember." That is, one month, just one month, where we guard ourselves from the trap of negativity, during which we filter ourselves from taking part in the easy trap of those little comments that we put on twitter, the offhand remarks that we make on our blogs, the complains we focus on when we spend time in person. One month where we put forward an air of positivity in all of our dealings. What would happen if we all did this? What would be the result if we took a minute before we complained, a moment to reflect on whether our dissatisfaction is because of our own choices, those decisions we have made about our tools, our coworkers, our entire work environment?

So, I ask each and every one of you to take part in this grand experiment: spend a single month portraying only positivity and happiness in what we do. After all, we have one of the greatest jobs there is. We get paid to do that which we gladly do for fun, for a hobby. I spent my teen years programming, relishing the thrill of creation, the thrill of making. Now, more than 20 years later, I get paid to do this. We all do.

Join with me this November to celebrate the beauty and happiness in what we do. Try to take a moment to filter every outward expression of yourself and look for the joy in what we do. We all get frustrated at times; the world isn't perfect. But, if we can take a second to reflect and focus on the positive, maybe that will actually have an effect on our industry, and on our world.

The hashtag for this is #positivember. This word captures the essence of the movement: 'positiv' stands for looking forward, appreciating the life of creation that we have built for ourselves, being proud of what we are doing; 'ember' is hungarian for 'person,' the simple link that this is about us as individuals. So, I ask you to help spread the word: tweet about it; blog about it; talk about it. Most of all, present yourself as a happy, positive person who cares about what they do. As people see that those of us who care are happy, they will want to know why. When they ask, we can proudly say, "I love what I do. I'm happy doing what I love."

And, in the end, I believe this to be the only way we can convince others to follow along. Will you join us?

Help support #positivember

Please vote for this on Digg, so we can get more people taking part.
Do you have a podcast? Please give us a shoutout. I'm also available for short interviews about the motivation behind it.

Learn To Type Week - Recap

noreply@blogger.com (Corey Haines) — Mon, 19 Jul 2010 10:19:02 PDT

(interested in what all the fuss is about? Read the original post)

Wow! It has been a great week of typing practices. Lots of people took up the challenge and began practicing home-row touch-typing. There were people who were starting from scratch, unlearning years of existing techniques, and some who took the opportunity for further refinement, perhaps getting those pesky numbers and symbols under control (something most people have trouble with). A bunch of people frequented typeracer.com for incredibly fun car-racing action. At Eden Labs, they even did a video of two employees racing (Aimee Daniells and Tom Crayford). Watch and see what it looks like when someone types 100+ wpm.

Rather than write a teary-eyed, looking-back account of the journey through the week, I'll end with a challenge: Keep It Up! This week was an intense series of 30-minute sessions every day, but it was just a start. If you continue to practice frequently, either while writing blog posts, coding or just doing focused transcription practices, you'll find your speed increasing and your errors decreasing. Transcription is an important way to learn and practice the techniques, but the real stuff comes when you are producing content. Write a blog post with a paper over your hands. How did it feel? When you get back to coding, are you looking at your hands when you hit the funky symbols, like ( or { or [? If so, why not do some practices to get those under control.

And remember, typing is a fundamental skill, not just in coding, but these days, in life. Is it the only skill you need as a developer? Not by a long shot. However, chipping away at impediments to getting your ideas out there is an important step towards improving your competency. Having a strong and fluid command of your keyboard is a valuable first step towards the goal of mastering your toolset.

Learn To Type Week - Day 4

noreply@blogger.com (Corey Haines) — Thu, 15 Jul 2010 05:38:32 PDT

(interested in what all the fuss is about? Read the original post)

So, Day 4! How quickly time flies when you are typing, eh?

This week has been amazing. I've talked to people who are taking the time to unlearning years-learned techniques in the effort to improve their typing skills. Others already type from home row, but they realized they don't have a good feel for the number/symbol row. More people are discovering "Learn To Type Week" and starting at the beginning. And, of course, there is the typeracer.com racing. It is a blast to sit and let my fingers fly around the keyboard, totally balls-out.

Speaking of typeracer.com, Eden Development realized a video of two of their people, Tom Crayford and Aimee Daniells racing. (@t_crayford and @sermoa) Hilarious! Go watch what 90-100+ wpm fingers look like.

So, my advice for today is about the same: continue the path you've started. Watch the #learn2typewk search on twitter, so you can keep up with the others who are doing it. As a community, we can keep ourselves motivated in our practice. A great way you could practice what you've learned so far is to write a halfway-mark blog post about your experiences. In our day-to-day lives, we rarely do transcription, instead we are typing while producing. Writing a blog post will allow you the opportunity to apply what you've done these past days to a more real-world situation. And, as a bonus, it will spread the word.

See you on the #learn2typewk racetrack! If you want to send the racetrack link to others, you can use the shortened url: http://vurl.me/TEL.

Learn To Type Week - Day 3

noreply@blogger.com (Corey Haines) — Tue, 13 Jul 2010 21:44:51 PDT

(interested in what all the fuss is about? Read the original post)

Wow! Another day has gone by in "Learn To Type" week. I've had a great time watching people mark their progress on twitter (hashtag: #learn2typewk): everything from home row stats to switching to dvorak. I'd highly recommend putting a persistent search into your twitter client for #learn2typewk, so you can see all the people who are working with you. Tomorrow is Day 3! Almost halfway done, so don't despair, we're almost there!

There are a lot of people putting their speeds and accuracy counts up; it is really neat to see the improvement. Now that 2 days have gone by, try to set a realistic goal for the end of the week. Speed isn't what it is about, though, perhaps you want to consistently type effectively for all the rows without looking.

What to do today?

As always, I recommend starting with a baseline: freetypinggame.net's 1-, 3- or 5-minute tests. Then, continue the practicing you started.

I've noticed that when I'm doing practices, I find it easy to stay on a single one until I've 'mastered' it. So, I might be practicing the home row keys and find that I have them down, but maybe I could do them faster. Don't worry about the speed, just move on to the next exercise. Remember, speed comes once the techniques are in place.

As always, don't forget to intersperse your practice with fun! Typeracer.com is a great way to reap the benefits of all that practice. I'm keeping the racetrack open at http://vurl.me/TEL, so feel free to post a challenge on twitter with the hashtag #learn2typewk. If you are registered on the site, you can create your own track too and put out a private challenge.

Just think, no matter what, if you participate, you will win! Huzzah! That's more than can be said for a lot of things.

Learn To Type Week - Day 2

noreply@blogger.com (Corey Haines) — Tue, 13 Jul 2010 07:23:39 PDT

(interested in what all the fuss is about? Read the original post)

Good morning, everyone! I meant to have this up last night, but I misjudged my timing. Sorry to the people in Europe, already being long into the afternoon and all.

Day 2! I've been excited to see how much the response and participation from people for "Learn To Type" week. There are people who are trying to learn to touch-type for the first time, people working hard to overcome years of bad technique, people who are moving from QWERTY to Dvorak, and loads and loads of racing on typeracer.com. But remember it isn't about your speed, it is about your technique. Speed will come, but technique and form is what we are practicing. Of course, everyone needs fun, so we meet on typeracer for some balls-out typing competition.

What to do today?

I would recommend starting with a baseline on freetypinggame.net's 1-, 3- or 5-minute tests. Then, continue with the lessons you started yesterday.

If you have started some lessons, continue them. How are you feeling on the home row? Move on to the lessons that include other parts of the keyboard. I would recommend you keep on the path you started yesterday, as those lessons are built for incremental learning.

If you already touch-type, but are working on your form, then I highly recommend doing a few 5-minute tests on freetypinggame.net; I like the fairy tales. My goal this week is to make it all the way through #26: the cobbler and the elves (not to be confused with the keebler elves).

Don't forget to intersperse it with some fun. If you want to take a break, then head on over to typeracer.com. I'll be keeping the coreyhaines track open, so you should be able to use that as a primary meeting point if you want to race other "Learn To Type Week" participants. If you want to call some people into a game, you can post the shortened url http://vurl.me/TEL on twitter with the hashtag #learn2typewk; people might be up for a race. Otherwise, go on the open tracks and race away.

And remember, it isn't about where you are today (no cries of 'I Suck!'), but about where you will be soon (only cries of 'I'm getting better!').

Keep it up today!

Learn To Type Week - Day 1

noreply@blogger.com (Corey Haines) — Mon, 12 Jul 2010 06:44:27 PDT

As I wrote in my last blog post, tomorrow starts "Learn To Type Week." What does this mean? I encourage you to read that post to understand the motivation. For now, though, let's talk about this week. We had a lot of fun over the past couple days with typeracer.com, and I hope to keep having fun with it, but now starts the work for the week.

I will be writing a blog post every night with some ideas and encouragement to keep you going through this week, spending 30 minutes a day working on your touch-typing. Are you already touch-typing? Maybe you want to spend the time improving your speed. Or, work on the top row (numbers/symbols).

On Day 1, first thing, here's my recommendation: go here and do either a 1-, 3- or 5-minute test. If you are just starting to touch-type, then do the 1-minute test; if you are an experienced touch-typist, do the 5-miute. But here's the catch: do it with a piece of paper over your hands: no peeking! The key for this is not to do it quickly, but to do it with 0 mistakes. This is your real touch-typing speed. So, do it a couple times, if you want, until you are satisfied. This is what you are going to measure yourself against over the course of the week. After you do that, mark it down. Why not put it on twitter or your blog? Let's do this together, and we will be more likely to keep it up and encourage each other.

Now, choose your typing lessons (I have some links on the original blog post, and you can always google for them) and start. Are you just learning to touch-type with home row? Then start going through the step-by-step tutorials. Are you an experienced home-row touch-typist wanting to get better? Maybe do the 5-minute typing test a couple times, interspersing a few trips to typeracer.com. Go to this site and play some games: what's your best score at Keyboard Revolution? Gotta Love The Duck!

Tomorrow, we'll reconvene and do some more.

And remember, this isn't about where you are now (no cries of 'I Suck!' only cries of 'I'm Getting Better!'), but where you are going to be, where you'll be in a week. So, try to make positive comments about your status. Believe me, it will help.

Hashtag: #learn2typewk

Learn To Type Week!

noreply@blogger.com (Corey Haines) — Mon, 19 Jul 2010 10:18:41 PDT

(posts for the week:

)

As I've traveled around and programmed with a lot of different people, I've noticed a really frightening thing: in general, programmers don't type correctly. I'm not sure why this is, but it makes me sad. Most of the people I meet that don't touch type still can bang away a lot of words a minute, but if you watch their heads, it is like a bobbing robin, constantly looking down to see where their hands are. What a waste of motion and context switching.

Typing is a fundamental skill for programmers. We spend our days manipulating text, so it makes sense that you should have it mastered. In a way, it would be like hiring a carpenter and seeing them flailing around with the screwdriver, missing the screw sometimes, maybe poking their finger. What would you think? That's how it looks when you are hunt-and-pecking. Embarrassing!

So, I thought I would put a challenge out there: Learn To Touch Type! For the most part, you know where the keys are, it is just a matter of quieting your hands down and learning the home row position. I wager that, for most people, it would take about a week of daily 30-minute practices. A Pomodoro! That's all.

In fact, why not do it next week, July 12th - July 18th. I declare next week to be "Learn To Type Correctly" week (hashtag: #learn2typewk)! If we do it as a community, supporting each other, then it is more likely that we'll shed the baggage of bad typing skills. Come on, you can do it! Blog about it, twitter about it, get the word out. Everyone will feel better, and imagine your pride when you sit down at a keyboard and don't ever have to look at your hands.

But, Corey, you say, I thought typing wasn't the bottleneck. No, it isn't, but ineffective typing can be. Having to look down at your hands disrupts your flow. When you can just let the words come out without thinking, you will be much more effective.

There are plenty of online typing courses that you can use. Here's a couple I checked out:

http://www.powertyping.com/qwerty/lessonsq.html

This one is very structured, using extreme repetition to push the positions into your head. Try it out.

http://www.freetypinggame.net/default.asp

This is one of my favorites. I'm not sure about the actual lessons, but the games are a lot of fun (I like Keyboard Revolution).

http://www.goodtyping.com/default.htm

This is a step-by-step lesson plan. You have to register, but it keeps rankings and lets you print out certificates.

http://www.typeracer.com

This is a fantastic site where you get into 'car races' against other online opponents. Think of the old horse-racing games at the carnival with the balls that you throw into holes to make your horse go. Now, instead of horses, think cars, instead of balls, think your keystrokes. (BTW: I'm Corey Haines or coreyhaines or coreyhaines@gmail.com on typeracer.com, if you want to friend me)

This is just a short list. If you don't like them, feel free to use another.

Interview with J.B. Rainsberger and me

noreply@blogger.com (Corey Haines) — Thu, 28 Oct 2010 05:32:45 PDT

When we were in Romania, teaching a TDD class and facilitating a coderetreat, Maria and Alex sat down and asked us some questions. The first part includes some of our thoughts on education and software craftsmanship.

[Update: The second part continues our discussion]
[Update: The third part rounds out our discussion]

My favorite phrase: "Every 20-person software development team is a 6-person team trying to get out."

Note: Okay, okay, perhaps 'scourge of the industry' was a rough turn of phrase that I used. :)

If you would like to get in touch with J.B., you can contact him from J.B. Rainsberger.

Enjoy!

Part I

Exclusive Interview in Bucharest with J.B. Rainsberger and Corey Haines - Part I from Maria Diaconu on Vimeo.
Part II

Exclusive Interview in Bucharest with J.B. Rainsberger and Corey Haines - Part II from Maria Diaconu on Vimeo.

Part III

Exclusive Interview in Bucharest with J.B. Rainsberger and Corey Haines - Part III from Maria Diaconu on Vimeo.

J.B. Rainsberger - On Coderetreat

noreply@blogger.com (Corey Haines) — Thu, 28 Oct 2010 05:37:47 PDT

Since these videos with J.B. Rainsberger were taken after facilitating the Bucharest coderetreat, I thought it appropriate that we spend some time talking about coderetreat. J.B. was a participant in the very first retreat in January of 2009 in Ann Arbor. Since then, we've both been at many of them, both participating and facilitating.

J.B. and I talk about the goals of coderetreat, how they've changed, what the future holds and what the benefits of them are. This is a great conversation about what is a fundamental technique for practicing basic software development principles.

If you would like to get in touch with J.B., you can contact him from his website.

Enjoy! And, as always, thoughtful comments are appreciated, blog posts are better! :)

CRT - JB Rainsberger - CodeRetreat from Corey Haines on Vimeo.

How to be a software craftsman

noreply@blogger.com (Corey Haines) — Sat, 20 Mar 2010 14:38:01 PDT

While in London, I gave a talk to the London Ruby Users Group (LRUG). This was a shortened version of the talk I did earlier in the day at QCon. It is about one of the essences of software craftsmanship: being a better developer and how that relates to the terms 'apprentice' and 'journeyman.' LRUG is hosted at Skills Matter, and they put the video of my talk online.

Plus, bonus: definitive answer to the question of how to be a software craftsman!

I had a great time talking to them, and it was very encouraging to see the number of hands that were raised when I asked how many people practiced test-driven development. Thanks to various influences, test-first and test-driven development are pretty common when you talk to people active in the ruby community.

After the talk, we went to a bar. Thanks to everyone for the great conversations and ideas.

Blaming your tools

noreply@blogger.com (Corey Haines) — Sat, 20 Mar 2010 11:04:51 PDT

This blog post "Human-tool intellectual partnership" made me think on our own field. Here's some thoughts of mine.

As long as I've been around, I've heard people bring up the phrase "a poor craftsman blames his tools." With the rise in the software craftsmanship movement and the associated (oft-misrepresented/misunderstood/misapplied) terminology, this happens even more often.

When someone talks about how you are more productive with Rails than with some other frameworks, out comes the 'a poor craftsman blames his tools.'

When you talk about how using a dynamic language offers affordances and design possibilities that a static language, such as C# or Java, doesn't you can hear the cries of 'a poor craftsman blames his tools.'

How often would you see a professional, custom-furniture maker use a saw to pound in a nail, or use an awl to attach a screw. Could they pound in a nail with a saw? Sure, I bet they could. But they don't. They choose the right tool for the job. And therein lies the rub, I think: 'the right tool for the job.' Everyone has their favorite tool, but, for everyday work, I'm sure the furniture maker tries to keep their general toolset up-to-date, replacing older, less-effective versions of a tool with more productive ones. Having a manual screw-driver is great and very important for certain situations, but having an electric one can help tremendously when trying to be productive. A professional tends to have a whole slew of tools, used effectively at the right time.

Why do we, as programmers, have a tendency to defend our possibly old, less-effective tools. Personally, in the past, I've fallen into the trap where I made judgements about a new tool before giving it a real shot, assuming I understand it before I've given myself a chance to become familiar with at least the rudimentary subtleties. Perhaps I held to the belief that 'all tools are equal, it is just a matter of how you use them.' Over time, with experience in different realms, it becomes abundantly clear that this is patently false. Can you do most anything with any tool? Sure. Should you? No.

Does this mean that there is only ever one 'best tool for the job?' No, I'm not saying that. But, there are certainly a whole slew of tools/languages that are average-at-best with their appropriateness. Here's a statement: the more 'general-purpose' a language is, the worse it is for the majority of the tasks we use it for. This is why you see an significant increase in productivity in languages built on top of Ruby, such as Rails. They are fine-tuned to be effective and productive in a constrained set of tasks. This is why you often see people writing the solution to a problem in the language they wish they had, then implementing it in their underlying, general-purpose language.

Snarky comment: ever notice how, in general, the people who like to chime in with 'a poor craftsman blames his tools' tend to be the ones who use crappy tools. :)

As always, thoughtful comments are appreciated. Blog posts are even better.

J.B. Rainsberger - Value Objects

noreply@blogger.com (Corey Haines) — Thu, 28 Oct 2010 05:41:19 PDT

As part 2 (part 1 was primitive obsession) in the 3-part series of interviews that I had the opportunity to do with J.B. Rainsberger recently in Romania, we talk about the idea of value objects and identity.

If you'd like to get in touch with J.B., you can contact him through his website.

Enjoy! And, as always, comments are welcome, but blog post responses are welcome even more!

JB Rainsberger - Value Objects from Corey Haines on Vimeo.

Conversation with Gary Bernhardt

noreply@blogger.com (Corey Haines) — Tue, 09 Mar 2010 05:01:28 PST

Gary Bernhardt has a unique perspective, having spent significant time in both python and ruby development, as well as taking part in both communities. He spends a lot of time talking and writing about testing and design and their intersection on his blog, Extra Cheese.

Gary did an incredible refactoring screecast, as well as his much-talked-about presentation at Northwest Python Day, called Python vs Ruby: A Battle to the Death.

Gary organized the Seattle stop on my coderetreat tour 2010, and I made sure to get a chance to sit down and record a conversation with him. In this video, we meander a little bit, but focus primarily on some of the differences between the ruby and python communities, especially as it relates to testing habits and ideas.

Enjoy! And please leave comments if you are so inclined. Blog post reactions on your own blog are also highly encouraged.

Gary Bernhardt from Corey Haines on Vimeo.

J.B. Rainsberger - Primitive Obsession

noreply@blogger.com (Corey Haines) — Tue, 02 Mar 2010 18:27:49 PST

Note: I am in the process of working with the 5by5 network to begin a regular video and audio podcast. This podcast will contain the bulk of the interviews and videos that I'll be doing while I travel around on the coreyhaines coderetreat tour 2010. Until the details have been sorted out, I will be posting them on this blog, similar to how I did last year. fI you are new to the interviews, please check the archives of this blog to see other great content.

While in Romania, facilitating the Bucharest Coderetreat, I had the opportunity to teach a Test-Driven Development class with J.B. Rainsberger. We've talked about teaching together for many years, and I'm honored to have finally had the opportunity. If you have watched the videos that I did last summer with J.B., you'll know that he has an amazing amount of experience and insight into the development process. He has an ongoing blog called 'The Code Whisperer,' which has consistently thought-provoking content on design, testing and other coding techniques. If you haven't watched them, I urge you to look through the archives for them, as his thoughts on test-driven development are enlightening.

Whenever I have time with J.B., I do my best to get some videos recorded with him covering whatever might be of interest to us at the time. This past opportunity was a goldmine, as, not only did I get 3 videos, but we also used ustream to live-stream the interviews. While I was copying onto my computer, J.B. was kind enough to do impromptu Q&A sessions with the people viewing.

This is the first of those video interviews, focusing on the often-mentioned, more-often-misunderstood topic of 'Primitive Obsession' in design.

Enjoy! As always, constructive feedback is welcomed in the comments. If you are so inclined, please write a blog post with your thoughts.

Coming next week: Gary Bernhardt discusses some of the differences between the ruby and python cultures.

JB Rainsberger - Primitive Obsession from Corey Haines on Vimeo.

Please Help - CodeRetreat Tour Videos

noreply@blogger.com (Corey Haines) — Mon, 15 Feb 2010 12:26:36 PST

THANKS:

Dan Benjamin of 5by5.tv is going to help me out. Thanks to everyone who has contacted me to see if they can help. It is really flattering when the community out there is interested in helping.

I'll let everyone know how it goes, and I'll be writing up a guide when I'm finished.

As I'm traveling around this year on the coreyhaines coderetreat tour 2010, I'll be doing video interviews with people I meet. These will be very similar to the videos that I did during the 2008/2009 pair-programming tour. Already, I have an interview with Gary Bernhardt about the testing cultures in Ruby and Python, as well as several videos with J.B. Rainsberger, talking about such topics as primitive obsession, why inheritance is bad, value types and other random things. And these are just during the first two code retreats!

During the previous tour, I simply put the videos up here on the blog, embedded via vimeo. Throughout the year, people were always asking for a podcast format, providing both an audio and a video component, so people could listen in the car, working out, while knitting, etc. I agree this is a great idea, but I haven't taken the time to really figure out how to do it. People tell me it is easy these days, but I'm currently at the ignorant end of 'everything is easy once you have someone show you how to do it.' As an example, the current 15-minute video that I'm trying to upload rendered out at 835M! That takes hours to upload. I don't know what compression I'm not setting that causes this. I'm a sad panda.

I'm putting out a request for help. I know there are a lot of people out there who have successful podcasts with audio and video parts. I'm hoping that someone will be willing to take a few hours over the next week, or so, to help me set up my environment to do this effectively. My video editing needs are small, as I intentionally leave the videos with little editing, focusing more on the impromptu, conversational aspects of the interview.

Here are the main things I don't know how to do effectively or at all:

Render a video (with iMovie or Quicktime) that is good quality and small enough to upload without taking what feels like a million hours;
Effectively strip out the audio from the movie;
Set up a podcast for the audio version;
Set up a podcast for the video version;
Get podcasts into iTunes;
Create a process for effectively updating the podcasts;
Anything else I should know how to do.

Wow, I sure don't ask for a lot.

I am looking for someone who would volunteer their time to help me do all this. Once I know how to do all these steps, I can do them going forward; I would rather have someone teach me how to do this, rather than continue to stumble around.

As a way to say thank you, I will do two things:

Credit you as a the person who helped me figure all this out;
Write a guide / do a screencast on how we did it, so others can have the step-by-step instructions.

Note: I'm on a mac, so experience on that platform/toolset would be necessary. I currently have iMovie, Quicktime Pro and Camtasia.

If you can help me, please email me at coreyhaines@gmail.com. I'd like to get all this done over the next week, so I can start pushing these videos up.

Thanks in advance.

Just a reminder

noreply@blogger.com (Corey Haines) — Thu, 11 Feb 2010 01:14:42 PST

Remember!

From Miscellaneous

Code Retreat Tour #1 - Seattle, WA

noreply@blogger.com (Corey Haines) — Tue, 09 Feb 2010 12:37:58 PST

The Seatle Code Retreat was the first retreat of my year-long tour, and I couldn't have asked for a better day. Gary Bernhardt was responsible for the organization, and Blue Box Group was the company sponsor. We had a fairly diverse group of backgrounds, ranging from ruby to python to .net; it appeared that a large group from the area's .net community came, which I'm always happy to see. Everyone seemed to have a great day, and there was even talk about when the next Seattle-based retreat would be. One of the goals of my tour this year is to spread the format that I've seen for a successful Code Retreat; hearing people talk about doing more retreats is very encouraging. Plus, seeing the format that I use in person can give people a foundation for facilitating their own retreats..

While the standard language for code retreat is Java, the community in Seattle decided on Ruby. This didn't seem to be a problem, as about half the attendees had a strong background in the language, and the other half had done some up-front preparation with the language. A lot of people spent some time before the retreat getting familiar with Ruby by going through the Edgecase Ruby Koans. The Ruby Koans are a set of ruby scripts that walk you through learning the language via making tests pass. I'd highly recommend checking them out.

How It Went

People started arriving around 8.30am; my goal was to begin the first session around 9.15 or 9.30. One unique aspect of this retreat was the simultaneous event happening in Grand Rapids, MI, hosted by Jeremy Anderson and sponsored by Atomic Object. Because it was the same day, Jeremy suggested we do a Skype call between the two retreats. What a great idea. So, at 9am PST, we reveled in the magic of technology by having a short video chat between Seatle and Grand Rapids.

As I like to do, the first 2 session were spent getting used to the problem domain, Conway's Game of Life. About half the participants had experience doing test-driven development, so we had a good mix of people pairing. As I wandered during the morning sessions, I saw basically two general approaches, either variations on a Cell class to hold the rules of evolution or variations of a World that contained a set of Cells. With only 45 minutes for a session, the announcement of 'Keyboards Down!' comes pretty quickly.

At the third session, I started broaching some ideas around letting the examples guide the design of your code. These ideas center around ideas gleaned from two areas: conversations with JB Rainsberger and Keith Braithwaite's TDD as if you mean it exercise. JB has fantastic ideas around test-driven development, and, based on the participants, I brought up his idea of moving specificity out to the test. This leads to interesting designs, as the injection of specific functionality and qualities leads to natural extension points appearing in the design.

For lunch, we had a local restaurant cater a taco bar; it was very well put together, complete with crunchy and soft shells and plain tortilla chips. I'm a firm believer that code retreat lunches should be a nice meal, and the taco bar that Blue Box Group ordered was definitely up to par. Coincidentally, the Grand Rapids team also had a taco bar; their food was from Qdoba (or Chipotle, I don't remember exactly), so I'm going to say ours was better on the basis that it was from a local establishment. :) During lunch, several conversations sprung up, and it was wonderful to see people discussing and sharing their thoughts on the different worlds of software development.

The afternoon was filled with intense practice, and, as I walked around, I saw people trying newer and more interesting approaches than they had in the morning. By the sixth session, most of the people were pretty wiped, so the majority of the people spent the time talking, discussing the day and explaining different approaches they had taken. At the end, we took a group picture. People were pretty exhausted, and only a few people went out for dinner and a beer.

Through the day, there were several teams who experimented with passing in functionality into the system, taking the idea of 'move specificity out to the tests' to heart. One team extracted the rules into a block that was passed into an evolve method. That allowed them to experiment with the evolution algorithm without being tied to a specific set of rules. It was interesting to see them implement variations on the standard rules. A couple other teams experimented with extracting the algorithms for determining the 'neighbors' of a cell. This could lead to watching he evolution of different systems from the same underlying system.

In the end, I think this was a very successful code retreat. The effect of removing the pressure to complete always leads to interesting developments, and it was exciting to see the attendees take it to heart during the day. Experimenting with different ways to implement a system is a valuable practice. The skill to be able to have an idea and let the code guide you to an implementation can be beneficial in the day-to-day tasks we normally face. Watching twitter for the next couple days, it also appeared that many people were expanding their horizons more by continuing to learn Ruby. If your general language is C# or Java, it is important to expand your mind to see what a dynamic language can offer. I know that my style in C# was significantly improved by studying Ruby. Stretching your mind into a new family of languages always leads to a better understanding of the fundamental conepts of software development.

I'd like to give a special thanks to Gary Bernhardt for organizing the event and for purchasing the morning bagels. I have a tremendous amount of respect for his ideas and his approach to development, and I would urge everyone to follow him on Twitter and also to read his blog, Extra Cheese. While in Seattle, I did a video interview with him, and I'll be posting that soon.

And we would not have been able to have this without the generous sponsorship of Blue Box Group. They provided both the space and the lunch. It is always exciting to see local companies willing to support community events and Code Retreat in particular.

If you would like to see more pictures, you can check out this picassa album.

Corporate Retreat Round-up

noreply@blogger.com (Corey Haines) — Thu, 04 Feb 2010 16:22:44 PST

In December, I had the pleasure of being invited to participate in Relevance Software's corporate retreat. It was a 2-day event, held outside the office, where they reflected on 2009 and discussed goals and specific plans for 2010. I'm not at liberty to discuss details of the discussions, but the format consisted of prepared presentations, breakout sessions, open-topic brainstorming and, of course, video games. I've spoken before about how impressed I am with Relevance on both the personal and professional level, and this was no exception. The transparency that was displayed at their corporate retreat, regarding both successes and failures was inspirational.

While at the retreat, I IM-ed Sarah and told her that I wanted to have my own corporate retreat. By the time I got back from Relevance, we were already discussing the details: what it would be like, what we could talk about, etc. Since I'm striking out on my own, and I have a lot of different projects and activities going on, it would be good to just take a look at where I've been, what I've done, and where I want to go, and, most importantly, how I'm going to get there. And thus was born:

The First Annual
coreyhaines LLC / fabled net
Combined Corporate Retreat 2010

There were a few things decided immediately:

it should be offsite; we can't do this sitting on the couch at home;
we should each have a full day for our own planning.

This led us to look for a hotel in downtown Chicago. After pricing out some possibilities, we found that we could get a night at the Intercontinental Hotel for around $115. The Intercontinental is a well-known, 5-star hotel right in the heart of the Magnificent Mile; it sounded like a great deal. At this point, Sarah made a fantastic point:

If we only stay Saturday night, then those sessions lose the morning hours. If we check out on Sunday, then those sessions will either lose the afternoon hours, or we'll be sitting there with all our bags.

Based on that, it made sense to get the whole weekend: check in on Friday night and leave on Monday morning. While this might seem a bit extravagant, it turned out to be such a successful decision that we found ourselves continually mentioning it and loving the fact that both days were relaxed and easily provided the necessary amount of time to really deep-dive into our sessions. The hotel had a second level that had open chairs and tables, including a nice table in a semi-private nook next to a window overlooking Michigan Avenue.

We decided to embrace the inherent humor of the situation, including taking advantage of Vista Print's free promotion offers to get swag for our retreat. We also took it seriously, though, planning and publishing agendas to each other with a layout of the day's topics.

It isn't my place to discuss what Sarah talked about at her retreat on Sunday, so this post is going to focus on the results of my sessions on Saturday. I had two major sections: a shorter morning focused on my personal history and goals; and, a longer afternoon focused on my professional path. When the day was over, we had spent around 7 intensely packed hours focused on my plans and goals.

Morning: Personal Goals

We spent the morning with two primary objectives: go over the path that has led me to where I am and discuss how to keep my professional traveling from negatively impacting my personal life, specifically my relationship with Sarah. I won't bore people with the stories from my past, but the brainstorming about techniques for a well-balanced life was very valuable. In any relationship, it is important that both people are involved, so it was important to spend some time discussing 2010 together.

Lunch - Big Bowl

Curry and fresh ginger ale is a great way to transition from personal to professional discussions. I'm just saying.

Afternoon: Professional Goals

The afternoon had a little over 5 hours of structured activities. I started with an overview of my professional career, adding more detail after 2004, when I was introduced to extreme programming. 2009 was covered as a foundation year; the exact nature of what is being built was considered, as well. Turning the discussion to 2010, I started to outline some of the projects that I had in the pipeline: the coreyhaines code retreat tour; partnering with Sarah on projects; the cluster summit; contracting; development of some day-long tutorials; "come code with me" classes; the coreyhaines community contribution fund; the "Software Journeyman" interviews; and, the "How I Got Started In Programming" interviews.

I am not a well-organized person; my detailed planning skills tend to be a bit on the meager side. I've found myself impressed with Sarah's skills in these areas, and I was looking for some advice and inspiration. So, I asked her to give a keynote at my retreat, focused on planning and organization. Rather than giving a talk, she decided to lead me in an interactive workshop to help determine a personalized, effective process for planning. We started working on developing a day-long rspec tutorial, and, while doing this, she extracted a set of steps that take advantage of my collaborative style. One interesting take-away she highlighted was that I work best with a small group of people, bouncing ideas around; it is ineffective and counter-productive for me to sit down and try to plan something out entirely by myself. She also led me in an exercise to help break through mental blocks when presented with certain tasks by rating each task simply on enjoyment and difficulty. Working through a specific planning session (a day-long RSpec tutorial) with focus on extracting a personalized process was incredibly valuable to me, as it will help keep me from being overwhelmed. Having a partner like Sarah is a constant source of happiness for me, and I especially am grateful for this part of the day.

Using our newly-developed process, we proceeded to approach some of the other plans that I had for 2010. Some were discussed explicitly, some were postponed to be flushed out at later 'focused planning sessions.' I intend to address these in detail in upcoming blog posts, but I want to give an overview of some of the projects for this year.

The coreyhaines code retreat tour 2010

My goal is to facilitate at least 10 code retreats around the country and the world. I believe that the code retreat is a significant event to help people become a better software developers. I have the schedule outlined through May, and I am in talks with places for the second half of the year. This is where planning skills are important. Sarah and I spent a considerable amount of time discussing what was an appropriate schedule, finally deciding that one location a month was the most appropriate.

Travel expenses are another aspect to consider; I will need to closely watch the balance of my income to expenses. The individual code retreats are sponsored by local companies, and I want to keep my costs separate from the site sponsorships. So, I hope to gain tour-level sponsors that will help cover some travel costs. I have a couple things in the works here, as well as some excellent help from Gustin Prudner and the gang at Entryway Software.

Partnering with Sarah on projects

January has been filled with sickness and other annoying interruptions, so the blog posts and screen casts about The Stickies Project have been on hold. We are still working on the application when we get a chance, though. Our schedules will become a little less crazy in the middle of February, and we intend to pick back up the active sharing. I will be writing a series of short, technical blog posts, followed by a longer series of blog posts on different aspects of writing an application in javascript.

One of the many reasons that I enjoy working with Sarah is her mind for application ideas. We have a couple more in the queue after The Stickies Project, and I'm looking forward to bring those to light. Working with Sarah is a pure joy, as our skillsets overlap, but there are definite places where her skills extend past mine. It is nice to have a partner who can really stretch your knowledge.

Along with the code retreat tour, this topic is highest priority for me.

Contracting

I need to balance my education-oriented projects with a healthy amount of contracting for two reasons: most of my projects don't generate income for me; and, it is important to periodically deliver software to keep my chops up. It is a challenge to keep my activities and projects from stepping on each other; if I try to do too much, then everything will suffer. I am currently working on a small (from a time-per-week perspective) contract to cover my base expenses, and I have a couple other opportunities coming up. Due to my schedule of travel, it is important to find contracts that are flexible.

Day-long tutorial development

I've been intending to develop several short topic-oriented classes that I can do in half-day or full-day sessions. Sarah and I started the planning process for creating an RSpec tutorial. We also brainstormed a bit on other topics that I feel qualified to teach: jquery, cucumber, ruby, rails, javascript testing, etc. Looking at my schedule over the next year, it became apparent that holding a class over the next couple months would not be feasible. So, starting in July, I will be doing once-a-month, day-long focused classes on specific topics, most likely on Saturdays or Sundays in Chicago.

The first one-day class in July will be "RSpec: from 0 to Rails."

The second one-day class in August will be "Testing Javascript: Too Easy Not To Do It."

"Come code with me" class

I had a great conversation with Paul Pagel the other day over beers, and he challenged me to put together a class for apprentice-level developers. This would be a series of hands-on, build-an-app-style sessions. I told Sarah about this, and we began discussing what form something like this could take. There were thoughts of a twice-monthly evening class, or even a weekly class. Then an idea came: what if it was an intense course, a few hours in the evening over the course of two weeks: like 3 hours a night, 4 nights a week, for 2 weeks. We would spend the 8 days building an application together, working as a team. I would try to find a co-instructor, so we could provide focused, hands-on mentoring while building a real-world application. I was explaining to Ray Hightower that I would probably find an app that I could build in 2 days, then stretch it into 8 days. This would allow us to really focus on showing how to do it right. Ray came up with a great tagline: 'a 2-day app squished into 2 weeks.' I love it!

One question is whether there should be a charge for this. I'll be charging for the day-long tutorials, but this probably would be expensive. Would that cause people to take their participation more seriously than if it was free? The other option is to make it invite-only; people would apply for it. If no explicit charge, then I would ask people to give an amount that represents how much value they feel they received.

This won't happen for a while, October at the earliest, so I still have time to think about this and get feedback from people.

The coreyhaines community contribution fund

This is an idea that I've been tossing around for a few months now. The basic idea is simple: create a code retreat/other event sponsorship fund that spreads the cost of sponsorship over many people contributing very small amounts. Code retreats and other practice-oriented events don't always have a local company to sponsor them and there are lots of people who would be willing to contribute $15 to support an event. For various reasons, events generally ask for sponsorships on the order of 100s of dollars, not $15. So, I want to start a fund that relies on the power of numbers to provide sponsorship for events. I'll be writing more on this later, as I begin to flush out the logistic details (non-profit, website, etc).

During our brainstorming session, Sarah had some great points and suggestions. In the end, we made some alterations to the original idea to include the following points:

Provide incentives to donate (for example: get publishers to donate books for drawings; develop blog badges for people to display; work with companies to get discounts);
Have a good website that highlights both people donating that month and the events that were sponsored;
Cap the donation to $15;
Cap the number of donations per month to 100 people;
Prevent people from donating two months in a row;
Provide some form of matching program with my own funds;
Be explicit that this would not go towards my own personal expenses;
Extreme transparency of input and output.

I'm planning on writing a more detailed blog post that will give more information on this and provide a forum for feedback. I'm planning on beginning the fund in April or May, so keep an eye out soon for the more formal announcement blog post.

The "Software Journeyman" interviews

During my travels in 2009, I had the unique opportunity to meet, work with and talk to a large number of people. I very quickly realized that there were a lot of people who had some great thoughts, but no real good way to share them. So, I began video-taping conversations with almost everyone I had the pleasure of pairing with. Most people I met had something they were very passionate about, and I was privileged to help them share their thoughts via my blog. Talking to so many people and spending so much time on the road, my head was normally filled with ideas. So, I also started a sub-series of videos called "Road Thoughts," in which I found a nice place to film myself sharing thoughts that were floating around. I received overwhelmingly positive feedback on all these videos, and I was proud to provide a platform for people to share their ideas.

Since I stopped actively traveling on the pair-programming tour and have spent a few months contracting and looking towards the future, I haven't done as many interviews. I still have a few that haven't been published, and the code retreat tour will provide me the opportunity to do more interviews.

In 2010, I would like to pick this series back up and continue to publish videos. My goal is to do at least one video at each location where I travel. Starting in March, I intend to publish at least one video per month.

The "How I Got Started in Programming" interviews

While the "Software Journeyman" interviews were generally focused on the craft of software development, I also found another source of inspiration and community: talking to people about their "origin stories." During the initial 3 weeks of travel, in December of 2008, I listened to a few people tell me how they got started in programming, including Uncle Bob Martin. In January of 2009, I realized that these are valuable stories that capture both the personal side of our field and important stories about our heritage. So, I started sitting people down in front of my camera and asking them to tell their story. These turned into the "How I Got Started in Programming" interviews.

While I have a lot of videos in the backlog, I haven't posted any in a long time. It takes a bit of time to prepare a video for publishing, and the number that are waiting to be edited is a bit intimidating. So, starting in March, I will be posting at least 2 interviews per month. Also, while traveling, I will begin to gather these stories again from people I meet.

Was it worth it?

Yes! Absolutely! Spending a day completely focused like this was invaluable. I don't believe it would have been nearly as effective at home, due to all the distractions. Having Sarah there, providing input and challenging my ideas, allowed me to make significant progress towards planning my year and keeping it from getting out of control.

Feel free to share your constructive thoughts and feedback in the comments below, or, better yet, write a post on your blog.

The Code Retreat Tour 2010

noreply@blogger.com (Corey Haines) — Wed, 27 Jan 2010 07:57:52 PST

www.coderetreat.com

I spent 2009 traveling around, pair-programming in exchange for room and board with a great opportunity to learn and share from a host of different people. Along the way, I met some fantastic people with fantastic ideas, capturing many of these thoughts in videos that I posted on my blog. At the beginning of the year, at the Codemash conference, Patrick Welsh and Nayan Hajratwala approached me with an idea for having a day-long event focused on practicing the fundamentals of software development. That is, get away from the day-to-day stresses associated with deadlines and trying to get things done. Over the course of several conversations, the concept of the code retreat crystallized. Through the year, the code retreat idea blossomed and spread around the world, from Romania to Iceland and, yes, even one in Canada. From the very first one in Ann Arbor, MI, in January, to the one in December in Cleveland, OH, I attended, hosted and facilitated many retreats. While the code retreat formula is still evolving and different facilitators have slightly different focuses, certain patterns and practices have emerged into an effective form of practice. Based on my experiences over 2009, I truly believe that code retreat is an important part of the software craftsmanship movement's focus on software developer development. :) So.....

I am announcing the coreyhaines code retreat tour 2010! For 2010, I have set the goal of facilitating 10 code retreats around the country and the world. I already have planned the first few, ranging from Seattle, WA, to Bucharest, Romania. I'll be in London for QCon and Sweden for Nordic Ruby Conference; I'm planning on working with the local companies there to host and facilitate code retreats there, as well.

There are two main goals for this tour. First, I want to spread the idea of code retreat and focused practice that has been established; Attendees to past code retreats have overwhelmingly been positive in their feedback. Second, I want to show and teach others how to facilitate a successful event. By spreading the techniques, the practical aspects of code retreat as a day-long practice session can really come to fruition.

One of the core code retreats of the tour is the one in April in Floyd, VA. Entryway Software is hosting a code retreat for the entire weekend. They have made a whole site dedicated to it, and it is something you won't want to miss. I've been to Floyd, and it is absolutely gorgeous! The weekend will be filled with practice sessions (standard code retreat style), plus some other activities, both social and technical. This is an event that you won't want to miss; go to the site and register now! Did I mention that it is free? Yup, free!

Speaking of free, code retreats are sponsor-driven. The location and the food at each event are provided by sponsors. A site sponsorship is generally a few hundred dollars, depending on how much catering costs in the city. However, we are also looking for tour-level sponsors, who will contribute money to support my travel, lodging, etc. What do you get for either of the sponsorships? Well, visibility in the community of developers who are passionate about their craft. If you are interested in sponsoring, please contact me.

A very special thanks to the efforts of Gustin Prudner and Katie Roberts from Entryway Software; their work has resulted in a fantastic tour website, where people can find out more information and keep abreast of any news. And, of course, my blog will be updated with more details.

Although I'll be attending and facilitating many code retreats this year, many more will be happening around the world. Perhaps there is one coming up in your neck of the woods. There is a ning site that is the central place for listing, registering and finding more information about all the other code retreats that are happening. If you don't see one coming up in your area, feel free to contact me, and I'll help you set one up.

And, of course, we have a twitter account that you can follow to find out information as it happens! Follow @coderetreat. If you are tweeting about, please use the hashtag #coderetreat.

Coming up in the next day, or so, will be another announcement related to code retreats that has the potential to see this idea get even larger.

Meetup in Chicago with Venkat Subramaniam

noreply@blogger.com (Corey Haines) — Sat, 14 Nov 2009 12:57:18 PST

Meetup In Chicago on 11/14/2009, 7pm at Penny's Noodle House

Come hang out with Venkat Subramaniam, me and anyone else that comes. Fun stuff!

We'll be meeting at Penny's Noodle House in Wicker Park (1542 N. Damen) between 6.30 and 7pm. We'll have great conversation over dinner, then, depending on the mood, head out to greener pastures for a night of geeking out.

Note: It is BYOB, so make sure to bring what you'd like to drink. Don't worry, after dinner we can hit some local bars.

If you are coming, feel free to send me an @ reply on twitter (@coreyhaines) or an email (coreyhaines@gmail.com). But, if you don't, that's cool, come anyway.

On Being A Journeyman Software Developer

Being honest vs Making excuses

My talk from SCNA2010

Turbulence, measuring the turbulent nature of your code

On the goals of Coderetreat

'Taking it too far' v 'Taking too much time'

Positivember

Learn To Type Week - Recap

Learn To Type Week - Day 4

Learn To Type Week - Day 3

Learn To Type Week - Day 2

Learn To Type Week - Day 1

Learn To Type Week!

Interview with J.B. Rainsberger and me

J.B. Rainsberger - On Coderetreat

How to be a software craftsman

Blaming your tools

J.B. Rainsberger - Value Objects

Conversation with Gary Bernhardt

J.B. Rainsberger - Primitive Obsession

Please Help - CodeRetreat Tour Videos

Just a reminder

Code Retreat Tour #1 - Seattle, WA

Corporate Retreat Round-up

The First Annualcoreyhaines LLC / fabled netCombined Corporate Retreat 2010

Morning: Personal Goals

Lunch - Big Bowl

Afternoon: Professional Goals

The coreyhaines code retreat tour 2010

Partnering with Sarah on projects

Contracting

Day-long tutorial development

"Come code with me" class

The coreyhaines community contribution fund

The "Software Journeyman" interviews

The "How I Got Started in Programming" interviews

Was it worth it?

The Code Retreat Tour 2010

Meetup in Chicago with Venkat Subramaniam

Meetup In Chicago on 11/14/2009, 7pm at Penny's Noodle House

The First Annual
coreyhaines LLC / fabled net
Combined Corporate Retreat 2010