Following on from Steve’s excellent post covering everything from microservices to special forces via some dark patterns, in part 2 I’m going a little more “old skool” with my two favourite talks of the conference (and subjects close to our hearts at Tyro): refactoring and pair programming.

Refactoring by the guy who wrote the book 

mfowler

Refactoring isn’t a new topic by a long stretch. It’s an even older topic for Martin Fowler, and he showed his mastery of the subject by captivating the audience with a truly engaging talk. I took away five points that I hope I can use to help improve my own and others’ approach to refactoring:

1. Red → Green → Refactor 

Yes, we all know this, but how many of us either forget the last step or mix it in with the getting-to-green part? Going back to Kent Beck’s bible of TDD, getting to green should involve making the test work “as quickly as possible, committing whatever sins [are] necessary in the process.” Then we refactor. The reason for this is similar to why we avoid context-switching; we apply a different mindset to implementing functionality compared to when we are improving code, so switching back and forth between these mindsets is likely to yield inferior results in both areas.

Thinking of different hats helps me; which hat do you have on, your implementing hat or your refactoring hat? (Or, like me, do you avoid hats because you look like a bit of a tool wearing them?)

 2. Don’t refactor code to death 

We wouldn’t know perfection if it smacked us in the face. Buddha even said so (though in a much more eloquent manner). Trying to refactor something until it’s ‘done’ is at best indeterminate and at worst never-ending. When we start refactoring that pandora’s box of nasty code, do we really know where we will end up? Instead, pick up your litter and simply leave the code better than you found it. Eventually we’ll reach nirvana… one day.

 3. Avoid planned refactoring 

We’ve all been there. Corners were cut, technical debt was accrued… it feels terrible. Better make sure we plan to come back and do a big tidy up, right? STOP! Refactoring appearing on a project plan is far too easy for your non-technical seniors to cut. Revert to point 2 and make incremental improvements.

4. There is an economic benefit to refactoring 

Reasons like “they’ve used a strategy pattern when they should have used composite” or “the code makes my eyes bleed” aren’t true reasons for refactoring, and we know it. The real reason is that we want to leave the code in such a way that we will preserve or increase the speed at which we can add future functionality. An obvious but important point to remember.

5. We are the guardians of the code 

We get to say when the code is done. That makes us the gatekeepers of code quality. Remembering this helps us avoid point 3 while point 2 prevents us from taking things too far.

Nice Pairing by Adele Smee (Lonely Planet)

nicepairing

Here at Tyro, we do pair programming (and sometimes bear programming) every day. Pair programming requires a certain type of developer and one of the mantras we live by is “leave your ego at the door.” That doesn’t mean pair programming is always easy, and you have to be able to work well with and understand a variety of personality types from one day to the next.

One of the best talks of the conference was by Adel Smee at Lonely Planet. Her and her team defined a set of pair programming archetypes in an excellent blog. It’s a great read and I heartily recommend it for anyone pair programming, whether casually or all the time.

It’s a familiar story; for some reason today’s pairing session just isn’t flowing as well as you’d like. It’s tempting to look at any negative aspects your pair is bringing to the table and pull out the finger of blame, but you also need to check yourself. Even if you’re a saint (yeah, right) and you’re convinced it’s not you, remember every personality type has something positive to bring to the pairing experience. Knowing your own pairing shortcomings and appreciating all the great things your partner brings to the session is the first step towards improving your pairing experience.

The guys at Lonely Planet defined some great tips for checking yourself, either as the driver or navigator in your pair. For example, I know I’m exactly the person who, when faced with a partner who likes some quiet time to think, will wonder why they’ve gone quiet. Maybe I’ll give them a few seconds of (for me) awkward silence and then butt in with some random distracting thoughts of my own. I cringe when I think of the number of polite people I’ve paired with who must have been reeling inside praying for me to shut up! If I do that to you, tell me you need time to think and to go and grab a coffee or something. Although thinking about it, maybe a coffee won’t exactly help…

Of course, this isn’t about pigeon-holing; you’ll see yourself and others across many of the archetypes presented, and it may be different from one day to the next. Remember that, as Adel put it, people are consistent only in their inconsistencies 🙂