Thursday, December 9, 2010
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.
Monday, November 1, 2010
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.
Monday, July 19, 2010
Thursday, July 15, 2010
Wednesday, July 14, 2010
Tuesday, July 13, 2010
Sunday, July 11, 2010
Wednesday, July 7, 2010
Friday, April 2, 2010
[Update: The second part continues our discussion]
[Update: The third part rounds out our discussion]
If you would like to get in touch with J.B., you can contact him from J.B. Rainsberger.
Exclusive Interview in Bucharest with J.B. Rainsberger and Corey Haines - Part I from Maria Diaconu on Vimeo.
Exclusive Interview in Bucharest with J.B. Rainsberger and Corey Haines - Part II from Maria Diaconu on Vimeo.
Wednesday, March 24, 2010
Saturday, March 20, 2010
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.
Tuesday, March 16, 2010
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.
Tuesday, March 9, 2010
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.
Tuesday, March 2, 2010
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.
Monday, February 15, 2010
- 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.
- 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.
Thursday, February 11, 2010
Tuesday, February 9, 2010
Wednesday, February 3, 2010
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 Annualcoreyhaines LLC / fabled netCombined 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.
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
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.
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
The first one-day class in July will be "RSpec: from 0 to Rails."
"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.
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.
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.
Tuesday, January 26, 2010
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.