Pairing Tour Day 1: I Should Delete More
Nothing kicks off a pairing tour like spending the day with the CEO. Paul was first on my list and we spent the entire day writing and refactoring- but rather than working with code we were working with text. As the CEO Paul is constantly working-on and iterating-over ways to help the company, so I was able to work with him while he wrote some thoughts down and then see how he organized them. I used the word “refactoring” because Paul approaches his writing in what feels like a very TDD way.
He starts out by writing down sections and blocks of sentences of what he wants to say. This builds momentum and he doesn’t have to spend time thinking about form. Then he shifts that block of writing towards the bottom of the page (or screen) and takes a shot at rewriting those thoughts into new sentences— or if he’s happy with how he said something the first time then he’ll pull it to the top.
He rapidly moves through this process of rewriting and moving sentences around until he’s satisfied- but there’s one other step to his workflow that I need to be better at: he fearlessly deletes sentences and even entire sections. If he’s rewriting a sentence and doesn’t feel the words are clearly stating what he wants- he’ll delete it before spending too much time on it. If he rewrites a new concise sentence that get his point across- he’ll immediately delete all of his brainstorming text at the bottom of the page. If the delete was a mistake there’s always the undo-key, but otherwise he knows that his next run at the thought will probably be better anyway.
I’ve definitely been feeling like I need to delete a lot more code. When starting out with JavaScript and Java on the last two projects I was so nervous that I’d forget how I did something that I ended up leaving in code that in hindsight almost feels like a spike (I say almost because I did write tests first). Now when I go back and look at the code I wrote a couple of months ago I know that it would be trivial to rewrite most of the methods- especially if I already have a test in place.
The past few weeks the phrase that’s been bouncing around my head is Uncle Bob’s saying: “the only way to go fast is to go well”, but with the addendum “ …and fearlessly”. We can all go faster by going well and being confident that each refactoring, each revision, or even a complete rewrite will most likely be better than our previous attempt.