Week 4 at 8th Light

Week 4, 19 Sep 2011

I'm sitting on a giant inflatable ball as I write this!

So every week here seems a little better than the week before it. This week I read Extreme Programming Explained I like it quite a bit, Kent Beck is a pragmatist, which means he's reasonable about his positions. I like that approach, I find it stimulates thought and engagement as opposed to the more dogmatic ways some present these topics that leaves me a bit uneasy.

Most of his positions seem to be based on his experiences, which makes them anecdotal. On the whole I find them compelling, but in some places they disagree with findings in books like Peopleware, which is much more empirical about it's assertions. One of the things I like about this book that I felt Peopleware was lacking, is that it prescribes what it thinks you should do, while Peopleware identifies what it thinks you shouldn't do. That makes Peopleware a bit paralyzing while making XP Explained empowering. (Note that I really like Peopleware, and if anyone wants to borrow it, they're welcome to.)

My conclusion of late has been that many things depend on the individual. A practice can work for some and not for others. I have a friend who is an aural learner. She explained to me that to learn something, she just reads it out loud, or to figure out how she feels about something, she just talks about it for a while. I tried that with a section of my chemsistry, and when I got done, I'd retained none of it. I tried very hard to recall the information and found it physically painful (I tried so hard it literaly hurt). Some tools are effective for some people, and others are effective for others. Some people like very short very focused test loops, but I find big overarching acceptance tests work significantly better for me. A lot of what Kent Beck says I like quite a bit, and I appreciate his pragmatic approach to finding the techniques that work for you. On the whole, that's the direction that many of my life philosophies have moved, so I find myself particularly appreciative of this.

My summary of the book (and Kent Beck would probably diagree with me) is that XP is a process oriented around feedback. The majority of their values and principles and practices can be phrased within this perspective. I think the general idea is that you can know very little in advance when programming. Requirements are constantly in flux, expectations in flux, goals in flux. So prioritize your decision making around your current, not your future needs. When the feedback comes in, you'll know where to go from there. Get in the game as fast as possible so that you can get feedback on where you're at now and adjust accordingly.

I find this resonates with me, when I get quick feedback on whatever I'm doing, I can quickly get a feel for it and zero in on effective ways to do it. XP wants quick feedback from the system, from the customer, from the users, from your coworkers. Get in the game as soon as possible so that you can get feedback as early as possible. Postpone decisions until they need to be made so that you can incororate feedback into that decision making process. Have the courage to do what the feedback implies. Enhance communication so you can receive feedback. Do the simplest thing that could possibly work so that you make the fewest assumptions, and so that when the feedback comes in, it will be easier to respond to the change that it necessitates. Pair programming gives you instant feedback from another developer resulting in finding many bugs immediately and homogenizing knowledge of the system. Automated testing gives you feedback of whether you're breaking something elsewhere in the system, and of whether your code is doing what you think it is.

Monday

I started working on an engine for Refinery CMS. Refinery is a Content Management System for Ruby on Rails. My engine will add the ability to hold elections and have members vote on them. I mostly just went through a walkthrough and looked at how it works. Then I tried to start on my project. It turned out to be a lot harder than I anticipated, the testing environment made it very difficult. It was taking several minutes to run their tests alone, and the environment's startup time was taking over half a minute. This made the feedback loop very long. I'd go do something while the tests were running, come back, and they still wouldn't be done. When they finally finished, I'd forgotten where I was. If they failed, I could end up in a 30 minute loop fixing even the simplest things.

Tuesday

Tuesday was better than Monday, I didn't get as far as I wanted, but I figured out how to scope RSpec and Cucumber to only run my tests, and I started to get my stories completed.

Wednesday

I got some more work done, focusing on features I knew I could complete, and leaving the feature that was giving me difficulty. My mentor Doug and I had an iteration meeting, where I demo'd what I'd done, and what we'd talked about. He played the part of the customer and made some changes and tweeks and set me up for the next iteration. I didn't complete one of the features I was supposed to for this iteration, so it found its way to the next iteration instead. I suppose there is a lesson to learn there about estimating, the possibility of really unexpected setbacks. I was pretty sure I could do all the things that were necessary, but I didn't anticipate that the environment would be like trying to jog in three feet of water.

Thursday

I was at 8th Light, which I always enjoy. I finished XP Explained this day, which meant I had the weekend to enjoy finally! Also got to work with two of the other apprentices, helping them debug a test that would fail or pass depending on the order in which the tests were run A blog about that issue is here.

That evening I went to the Chicago Ruby Hack Night. I had a lot of fun there, paired with a guy who is new to Ruby, but has been developing for a while. We solved a problem where you have to read in circuit diagrams and then determine whether or not a light turns on. I was pretty happy with our solution, but have to admit I made a mistake starting with the logic of the circuits rather than the parsing. I should know better, I was just concerned about working on something I wasn't sure I could do with someone new to the language, so I started with the easier part. Turns out, in the end, I realize I could completely omit all of that code by just treating the circuits like boolean values, which is already built into Ruby.

While I was there, I also chatted with Gregg Pollack and Jacob Swanner, who were in town to teach Rails for Zombies at Windy City Rails. I chatted with them for a while, but not long enough . I'd actually been talking to Jacob on IRC, in the Radiant channel, he'd given me some help with issues I was having. And Gregg has been puting together a screencasting channel that I might submit to intermittently, after my residency.

Steve Klabnik was also there. He took the time in the past to help me with several Shoes projects, and helped me with my first real F/OSS commit. We went out and had some drinks and food and had a great conversation about philosophy and politics.

Friday

On Friday I worked more on my refinery engine. Then we had one of the apprentices present a kata. It turned out to be the Prime Factorization Kata, which is the same one I did. He did it in Ruby (I did it in Java). Based on the feedback, I think that different people have different things they want a Kata to be, and when you present to all of them at once, then you'll simply have accept that their expectations aren't necessarily congruent, so someone will be dissatisfied regardless of your approach. This implies you should select the presentation style that fits you best, because you'll be most comfortable with it, and most satisfied with your work. Anyway, I really enjoyed watching this one, he didn't talk during it, but I found it engaging. There were subtle things he did to interact with the audience, including naming one of the tests "A precariously large number", which I'm pretty sure was an allusion to my use of the word "precarious" earlier in the day.

After that, we had another 8th Light University, this one was presented by Eric Smith, and covered making games with HTML 5 and JavaScript. I enjoyed and found the homework fairly compelling, it was to add functionality to a game that he started (an asteroids clone around the theme of killing bugs). I've added a counter to track how many bugs were killed, though need to do a little bit more work with it so it looks nice.

After that we had Waza, our open development time. I polished my code from Thursday's Hack Night and put it on Github. Then I added a feature to RSpec to allow its its keyword to take parameters. It wasn't accepted as they're intending to remove the its keyword in the next iteration. In my defense, I did ask before I worked on it, but didn't get a response.

After that I worked with Mike on a state machine for one of our internal projects. I've been enjoying all of my pairing so far, things like this get me excited about my pair programming tour that should be starting in early October.

Weekend

On Saturday I went out with some of the 8th Lighters to a coffee shop in Wicker Park. We worked some more on the internal project, and I wound up pairing on some of the same code, though it was taken in a bit of a different direction that day.

While going for more coffee, I noticed a guy sitting near us was doing Rails, and using Pry for his console. I struck up a conversation with him, and he recognized me from my video, and we'd even both been at the Chicago Ruby talk about Mongo DB a few weeks prior. I thought that sort of thing only happened in the valley!

I also figured out how to start a DRB server, which allowed me to cut off about 20 seconds from my tests' startup time.

---

Alright, so that's my fourth week in Chicago as an 8th Light resident apprentice. See everyone next week.