My Apprenticeship - Friday, June 11, 2004

I just wanted to point out that I'm not editing my original posts except where explicitly noted so all of this is really what I typed up after a day of coding. In this installment, I talk about my first day at Object Mentor as an apprentice. It's interesting to note that the "David" I refer to is actually David Chelimsky -- lead developer of RSpec. Of course Micah Martin is Bob Martin's (Uncle Bob) son and the guy who took a chance on me for the summer.

Friday, June 11, 2004

Today was my first day at Object Mentor. It took about 90 minutes to fight through traffic in the morning, so I think I'll be looking into some sort of mass transit.

Micah is on vacation in Branson, MO (he's been really nice to me, so I probably shouldn't make fun of Branson... much) so I walked in not really knowing what I would be doing. I was introduced to Susan and Telisha (secretaries), Lowell (seems like someone who's been with the company for awhile) and David. David will be working with me until Micah gets back, but David was only hired a week ago and he has been attending one of OM's classes for that week. So although he's an experienced software developer, he doesn't know a lot about the internal working of the company. I guess we'll be learning together.

We got me logged into the network and David started to explain what my project was going to be. Apparently there is this testing program called Fitness which has a wiki (a community run, although moderated, website which can quickly be updated) which is written in Java (a programming language). But there is also an OM wiki which is written in Python (another programming language). So I'm to translate the Pyhton stuff into Java stuff. I think. Since this isn't David's project he wasn't super clear on the details.

But I have only heard of Test Driven Design (which is what the Fitness program is all about) so we had to back up at this point and give me a little intro. The Bowling score intro. So if your goal is to write a program to score a bowling game based on the pins knocked down during all the rolls, you could just start coding. But that would be silly. According to TDD, you should first write a simple test of the program, which will of course fail because there no code yet. Then you should write the simplest possible code that will enable your program to pass the test. So we started with a test for all gutter balls: The score should be zero. So I wrote some code that would enable the scoring program to pass that test. Then we moved on to a test for always knocking down 1 pin, the score should be 20. Fine, I got the code to pass that test. Then I ran into some trouble.

Before I go into that, I should explain why TDD is good. Or at least the short version 'cause there's whole books on this subject. Simply put: TDD forces you to write simple working code. Simple is good because you want your code to be readable after you walk away from it (the maintainability thing). Working is good for obvious reasons. As your code gets more complex, you'll need to go back and change things which will inevitably cause something unexpected to break. If, after every change, you run the tests you will find out about problems sooner (before they get buried in all sorts of other changes all of which could potentially be the problem) and the test will tell you exactly what's not working which is a tremendous help in debugging. Cool huh?

But I have no idea how bowling is scored. Which is a bit of a problem. Strikes and spares are weird. And that last frame... So I ran into difficulty. David went back to his class while I struggled with the strike and spare thing. And it was hard not to start worrying that I was in over my head. I found myself thinking "Look, this isn't that hard so why can't you do it? Hmm? Maybe you don't have a future as a programmer. Maybe they'll realize their mistake in taking me on and get rid of me. Or worse, they'll be polite and assign me inordinately simple work so as not to tax my feeble brain." Yes, I know this all seems silly. But it was my first day and, frankly, I have a lot riding on being able to become a developer so it was hard not to feel a little panic. After a while David came back, saw I was struggling and gave me a hint. After that I got it.

Somewhere in there Lance (salesman) came in with his niece. In between making plans for the Agile/XP universe conference he mocked his niece for not being able to manage a turnstile on the 'L'. She ignored him. I ignored both of them as I was wound up in my impending failure as a developer.

But I worked through that, as previously discussed, and we moved on to the "so you don't know Python" part of my day. David showed me how to download Python and set me to work figuring out a Python tutorial. This took up the rest of the day. Python is weird. Yes I know everybody loves it, but those "for" statements and their use of "lists" are intelligible but strange. I think I might try re-doing my TicTacToe program in Python as a learning exercise. But that depends on how ambitions I am this weekend. My wife's play is opening Friday (more on that elsewhere in this site) and then there's all those videogames I just bought (T.H.U.G., Pandora Tomorrow, and True Crime: the Streets of L.A.). Tough choices.

Wow. I forgot that this was the first time I was seriously introduced to TDD -- and from David Chelimsky no less. What's funny is that TDD was still pretty new to him. Also, I started on a Friday because finals had wrapped up on Thursday (and I had graded them in a rush). I didn't even take a day of summer vacation -- that's kinda crazy now that I think back on it.

Also, also, I really did freak out of my mind when David gave me that bowling problem (which, btw I now know is a classic example of TDD) because I totally had no idea how to score a bowling game. And I was way too scared to ask. And later I was ashamed that I hadn't asked earlier. Eventually I had to just suck it up and confess that I had no idea. David was really nice about it.