This post originated from an RSS feed registered with Ruby Buzz
by Eric Hodel.
Original Post: Mechanics of Programming
Feed Title: Segment7
Feed URL: http://blog.segment7.net/articles.rss
Feed Description: Posts about and around Ruby, MetaRuby, ruby2c, ZenTest and work at The Robot Co-op.
I sat down with Elise Worthy at RailsConf to pair with her on a Rails application that used the Wunderground API to retrieve the weather for multiple cities. If you don't know Elise, she's a Hungry Academy student formerly of Seattle. You can read about how she built her app on the Hungry Academy Blog. Since Elise is new to programming, pairing with her made me think about how I work on small tasks when implementing a larger feature.
When I first sat down, Elise had a class to retrieve the weather for Washington D.C., a controller and a view to display it. Our task was to add a search box so you could show the weather for any ZIP code in addition to Washington D.C.
By implementing weather for a fixed city first Elise had followed the most difficult lesson for me to learn, only implement one idea, or story, at a time. When I try to add too much I can't fit all the details in my head. By making the weather work for one fixed city she had a solid base of work she could revert to to try again if she got stuck.
I mostly helped her with the question of "what should I do next?" Elise knew which steps she needed to perform but didn't know what the best order was. I've found that working on the easiest task first is best. By picking the easiest task you have time to think about the hard tasks in the back of your mind. By the time you get around to them you may have made them easier or you may have come up with an easier way to implement them.
In the course of doing the easiest thing next we switched back and forth between the API wrapper, the controller and the view. Each change we made was very small. For example, first add the search form, next extract the ZIP code from params, then replace showing Washington D.C. with the user's choice.
Each step only changed a couple lines that we verified in the browser so we didn't get ahead of ourselves. By first changing from a fixed city to an arbitrary city we advanced towards our goal without confusing ourselves with extra details. While this broke one feature of the app, it was obvious that it would be easy to restore in the future when we were ready to address it.
I also find it useful to add TODO comments when I know I need to change or fix something but don't want to do it yet. The TODO item may be a distraction at this time or something difficult that a future step will make easier. I find it easy to forget some necessary cleanup without them. We added a few when Elise would think of something she needed to change but I didn't want to get us distracted.
There was one other tip I had for Elise, as she was adding support for both Washington D.C. and the user's ZIP her first idea was to use two instance variables to provide the data to the view, one for Washington D.C. and the other for the user's city. She also asked if I thought this was the best way.
I told her that it is easier for me to think of handling just one item or handling many items, but not just two items. By having only these two categories of items to display it makes it easier to maintain your code by preventing duplication.
The best thing that came out of pairing with Elise was that I got to think about how I program at the lowest level. While I got to show Elise some tips I've learned over the years, she showed me the details of my own internal process that I barely think about anymore.
Previous Topic
