12 Lessons I learned from Unit Tests/TDD is a great article for practically adding TDD to your teams rhythm. I can’t stress enough how much point 8 makes a difference: Pair programming helps the team to adopt TDD. When we are trying TDD for the first time or when our deadline is tight, we will have the will to forget the tests and write only production code. Pair programming will prevent the team to cut corners and will keep it writing tests. ...
Today I got to pair with Peter Vanderabeele, who is a programmer from Belgium with a highly methodical bent. He has clearly had a lot of experience and it was neat to get to work on his project since it isn’t every day you get to work on a high performance fact storage system. Peter is creating a data store meant to store semantic facts that have relationships to each other. It’s a very different project with a goal, he stated, to have data in this format and extractable for the next 50 years. To try to view code with that lens is very different from how most other Rubyists think. We tend to see our code dying in the next 5 years… max. So we make decisions with that timeline in mind. Thinking of a timeline longer than my own life has very different implications. ...
Last night’s pair session was with @stuartrexking - a very experienced developer and technologist currently working at a really neat company called Antipodean Labs. It seems like he’s got a great handle on solving problems and staying maintainable. We started off by trying to decide what to do. I’m increasingly convinced this is the possibly the hardest part of remote pairing with people who aren’t part of your company. You don’t have a predefined complex project you both find interest in, so the most likely shared interests are either meta problems or highly common ones. Highly common ones are very visible and difficult to find low hanging fruit for. The meta problems are good to solve, but somehow feel like they are less valuable than the “real” problems. Maybe this is just a feeling I have. ...
Ruby is not Rails. Learn Ruby first. Get rbenv (preferred) or rvm installed with Ruby 1.8.7, 1.9.3 and 2.0 Write Hello World and run it puts "Hello World" Go through the Ruby Koans (simplest with 1.8.7) Go through some TDD exercises Code a simple ruby script that solves a problem you have, like… Add a TODO to a file Print out the date in another time zone Tell you how many days until… Perform some repetative task related to your environment Display something silly for your kids Ruby is not Rails. You do not need to learn all the “magic” of Rails to learn the awesome of Ruby. Spend some time and get where you can really drive a script and solve a simple problem. Doing this will get you far beyond a beginning Rails developer. You simply have to learn the magic incantations of Rails to be able to develop web apps after that. And those incantations won’t be nearly as scary.
I had a great #pairwithme session with @_zph. Always a pleasure to talk to him and solve a problem together. Setup TMUX + VIM on a slice github-auth gem Experience We wanted to add the feature to gh-auth so you could pass a –path or –user argument to it. Because we’re good developers, we started off by coding the acceptance test. We discussed the merits of how to write good tests and whether to follow convetions within a gem authored by someone else or do things ’the right way’ – according to whatever coding religion you follow. Eventually we decided on sticking to the conventions of the gem while trying to improve–but not radically change–the tests/testing that we touched. From there, we dove down into the implementation and unit tests and drove through until we had the –path argument working. Along the way we did a little refactoring to use the OptionParser instead of requiring a specific ordering of options. ...
Last night I had a great pairing with @Shicholas working on the String Calculator kata. Setup We again used TMUX + VIM, even though Nick wasn’t very familiar with VIM. Based on his experience, I think this might be the best way to learn VIM since you have someone guiding you through. You won’t pick up on everything, but you’ll learn a handful of new things each time. Exercise We went through each of the different rules and ping ponged back and forth. It was a struggle to do the simplest possible thing every time, and really let the tests DRIVE your development. Your developer brain wants to generalize the solution to a problem, but the strength of TDD is keeping your actual solution as simple as possible. Developers are notorious for over complicating things and over desigining. ...
The easiest things to pair on are little tasks that you both understand and can be easily “completed” within a 1-2 hour pairing session. Unfortunately, Tic Tac Toe, Conway’s Game of Life and Bowling become stale quickly. It’s not that they don’t have valuable things to teach you, but you can’t pair with the same people over and over again just doing those problems. Eventually you need to dive into a real project. ...
I had my first pairing session with @willpragnell today. He’s a smart guy and my first European pair partner. It was a pleasure to talk to him about his iOS and Ruby experience and I picked up on a lot of little things from our pairing session together. Setup TMUX and VIM - (I got to use my newly revised pairing script to set up everything in seconds) TicTacToe - RSpec The Session We set a couple of goals out for the beginning. We both wanted to learn more of RSpec’s new syntax and we wanted to really adhear to the TDD principle of doing the most simple thing next. ...
I’ve now been pairing with several people a week for the last few weeks. Even over that short period of time, I’ve seen a pattern emerge: If you watch someone else (of any skill level) and pay attention, you will learn. When I’m watching others, I tend to be thinking of what I’d do in their situation, but sometimes just observing very simple things a user does – a VIM action, a command line script, an obscure API call, a rare tool – these are the details that change you in the small over time. This same principle is why counselors tell you to actively listen to your spouse – hear what they’re saying instead of just thinking of what you’re about to say. Sometimes you pick up on things they might not be able to vocalize themselves. Sometimes you pick up on emotions you would be too busy to notice otherwise. Actively listening in any relationship involves shutting up and noticing the details–it just happens to be true when you’re pair programming as well. ...
Today I paired with @mattr_ and got quite a bit of good input regarding how to attack a problem and write tests. Matt is a super smart guy who has really absorbed some of the fundamentals of TDD and it shows through his ability to break down a problem. Setup TMUX & VIM on my box Conway’s Game of Life as an exercise Process When implementing the game of life, we started off looking at the problem on Wikipedia and found the 4 rules. I immediately started writing the first test when Matt noted that he liked to write all the specs he knows of as pending specs right at the beginning. Then he can really plow forward and know what’s next. He also noted that he likes to be able to write the assertion first, based on the test, and then build the test up from there. I felt the lightbulb go off when he pointed these two things out. When I’ve struggled to find the test or figure out how to test something, usually it’s because I can’t figure out how to get to the assertion, and that really comes down to not testing the right thing. ...