Programmer’s Paradox

The title of this post is taken verbatim from a post of the same name by Jay Fields.

Jay’s point is that it isn’t enough to go through the motions of being a developer. Part of being a developer is understanding the point of the motions you’re going through.  If you don’t understand why, you can’t understand the good or the harm you’re causing.

Recently on a project, I checked in some Python code that used several try except finally blocks, looking similar to this stub code:

try:
    session.open()
    do stuff
except:
     handleException()
finally:
    session.close()

The code acquired a database connection and I used the finally block to ensure the connection was closed, preventing any leaks.

When working on the code I had inserted some tabs instead of spaces. When another developer opened the same code in his editor, it complained about the tabs vs. spaces, but didn’t offer an explanation for the error it was reporting, only reporting an error. The developer failed to ask why the error was being reported and also failed to ask why I had written the code as I had.

The result was that the code was rewritten as this:

try:
    session.open()
    do stuff
    session.close()
except:
    session.close()
    handleException()

There is now duplicate code in the form of the session.close() call and the finally block has been removed. The code is less explicit and more repetitive (although it happens to end up being the same number of lines).

Muddling of code and an unneeded rewrite occurred all because of a failure to ask why. Listen to Jay. Ask yourself why before you code and before you start changing code others have written. It will lead to better code.

I’ve often read about paired programming, having heard its benefits extolled from Bob Martin when he gave my coworkers and I training, to reading about it at Hashrocket, where they “pair all the fucking time“.

It’s easy to find naysayers and it’s easy to rationalize why it might not work, the biggest reason being that it slows you down.

Guess what?  It does slow you down.

That isn’t a bad thing.

Recently I sat down and paired with a coworker of mine, as we worked to polish a project that is coming to a close.  The experience convinced me that I should pair more often than I currently do.

Why was it helpful?

It kept me focused and on task.  I had someone looking over my shoulder, so I couldn’t let my mind wander and wonder what the blogs were saying today, just because I reached a small breaking point.  What is normally a disjointed coding process for me became a smooth, continuous experience.

Having another set of eyes catches a lot.  Typos and mistakes in logic that normally aren’t discovered until the testing phase get caught immediately, because while one person types the other is checking behind them, in a way that only a human currently can.

Pairing forces you to address problems sooner.  Someone else now knows about that small flaw you introduced, so there is outside accountability.  The longer you leave the mistake, the worse you look.

Pairing uncovers mistakes that normally aren’t caught until the eleventh hour.  How often have you had a logic bug in some code that makes complete sense to you every time you look at it, but once another person sees it, they remind you of the vital piece of information you forgot that changes everything?  Mistakes like that usually avoid detection until formal acceptance testing.  With pairing, acceptance testing is always occurring.

Like I’ve mentioned, pairing slows you down.  This feels infuriating at first, as you sit there typing, feeling like an ogre who only knows how to type ten words per minute, while your coworker sits behind you mentally tallying all of your flaws.  However, while pairing slows you down in the quantity of the work you create, it speeds up the quality of the work you create.  This leads to less bugs and more time for development as the project progresses.  As an added bonus, I know of no other way that more quickly transfers information between two people than pairing.

Give it a try.  Like Test Driven Development, I was sceptical of Paired Programming, but I’m convinced of it’s benefits now that I’ve tried it.  While every sitation might not call for paired programming, I’m going to be doing more of it in the future and I challenge you to do the same.

Last year Bob Martin gave my coworkers and me some training on how to implement Test Driven Development.  Bob advocated for very small methods - even suggesting that methods often only have one or two lines of code.  If they started approaching five to ten, they could probably be broken down into separate methods.

Yesterday, while performing the activity of brushing my teeth, I started thinking about some Erlang code I was writing in my spare time.  Also, previously at work, some of my coworkers had been looking at Fitnesse, which is contributed to by Bob Martin, and commented on how short the methods were.

With both of these thoughts fresh in mind, it hit me:

Small methods are the object oriented equivalent of side effect free programming in functional programming.

A small method is in effect an immutable variable that gets passed around.  At the very least, it minimizes and isolates side effects, while enabling easy refactoring and testing.  It’s the closest to side effect free programming you can get in OO.

I’ve mentioned before that I think programming languages should have a REPL (Read-Eval-Print-Loop).

Unfortunately, PHP does not have one natively.  However, I just discovered that Facebook has opened sourced a REPL for PHP - so now you can test out your PHP code without needing to write and run a script.

Working in Python, I’ve found Python’s REPL highly convenient, so I’m going to start using Facebook’s PHP REPL for when I have to work in PHP.

Ironically, Facebook’s PHP REPL is implement in Python. I can commiserate: given the choice between Python and PHP, I’d go with Python.

What is the purpose of restructuring in an organization (not in code)?

My answer is this:

To put the right people in place with the necessary resources to lead the company.

If a restructuring takes place and that doesn’t happen, all you’ve done is make a feel good move.  If after a restructuring the same people are still leading the same people but with slightly different department names, then the chance for long term change is not great.  After a short time, the good feelings will wear off, and since nothing fundamentally changed, the status quo will continue.

It’s akin to holding lots of meetings to feel like you’re making progress.

While a restructuring might make sense, it isn’t the answer.  The answer is going to come from people and their willingness to carry out change.