I Like Slow and Steady

We had a bathroom remodel done last year. The tile guy's name was Adolfo. He was super cool. He was always up for a visit about whatever. He worked at a slow, steady, meticulous pace. There was a lot of wiggle room inside his work pace for him to have a nice conversation with someone, but he was always working, nice and steady.

Adolfo would take some measurements for the next tile he was going to lay. He would grab a suitable tile, take it out to his saw, stare at it for a few seconds, measure, measure again, take a breath, hum his favorite song a little, then make the cut. He would walk back into the bathroom and check the fit. Then he would likely come back out and adjust it a little. In a lot of cases, he would throw out a tile if he was not happy with the exact fit.

Adolfo was laying like a hundred or so tiles in our bathroom. Each tile got this slow and methodical treatment. I watched him get to a really tricky part around these built-in cubbies for shampoo and soap and junk. He was really careful here. He tried a number of different configurations with cardboard cutouts and stuff. He kept tinkering and trying things and taking little baby steps in his experiment. Finally he had something he could show me for which he wanted approval before he really committed. Somewhere around this time it dawned on me that Adolfo's tile laying method is a lot like my coding method.

I don't always think I need to see the big picture in the beginning. I am satisfied with seeing some small amount of the picture, enough to know the direction I need to go in. Then I look for some baby steps I can take to move myself into a greater and greater awareness of the whole thing. I think this is what Adolfo does. He knows we want the big tiles on the floor and the smaller ones on the wall. He knows we want some cubbies for shampoo and soap and he knows we want the edges to have a certain shape. Beyond that he's willing to discover the rest of the details along the way as he works. I don't think he trusts master plans and neither do I. Too much stuff can change along the way and the human mind is too limited to grok large and complex things very well. That's where craft comes in.

My friend Adolfo's craft, his years of experience working on tile projects, has given him the confidence to offload complexity into a system, a system specific to him. He has a method within his craftsmanship and the method's job is to do a lot of his thinking for him. I think this frees him up to feel his work more than think it. I'm not totally sure.

I do a lot of work with APIs. I really like it. It tends to be super complex, but also super powerful. My clients derive a great deal of value from tying two or more systems together and causing them to share data, business rules and process. When I code for these projects, I move methodically tile by tile very much the way Adolfo does.

For example, when I first start an API integration project, I create a CRUD script. It stands for Create, Read, Update and Delete. It's the simplest, dumbest script I can write. I find a way to write it and test it in as little time possible, whether this means using a bunch of libraries or no libraries at all. Cool libraries are not the goal. 'Time until CRUD' is the key. The sooner I can show that I can get one system to talk to another and create records, read records, update records and delete them, the sooner I can uncover the next part of the bigger system picture. In fact, even within the CRUD exercise, I am testing code before I even attempt to do a read from a system. I test hello world almost every single time. Is the server running? Hello world. Is the API recognizing my credentials? Hello world. Can I read anything at all? Hello world. Can I read a specific record? Hello world!

I have colleagues who deride my approach to incrementally developing complex systems. They claim that I will build garbage if I do not build for the big picture from the very beginning. Some of these detractors have never really built and maintained a complex system. I've built and supported many over the years.

So I move step by step and chip away at my development. As I code, I look for feedback from the system as frequently as possible. I also organize projects with frequent client contact and feedback as a priority. I trust incremental steps. I trust steady, demonstrable progress. This approach that feels so natural to me is one that seems to warm to the TDD approach to coding. In test driven development you write a series of incremental component tests that when put together, capture the whole of a system. On the other hand, there's something about TDD that makes me worry about being able to establish the same sort of intuitive connection to my code as my current method allows. And I think that's the key. Whatever coding method you gravitate to, if it taps into and elevates your intuition so that you can feel your work instead of think it...then it's worthwhile.

"Now how does this method result in speed? It sounds really slow actually."

What I have found is that my method allows me to get into the thick of the problem and activate my intuition early. Since I am not obsessing about comprehending the master plan and am instead moving steadily toward completion, I get to proof of life sooner. I get to trust in my process and this turns into higher quality, thoroughly tested code which in the long run gets me to completion faster than other methods I've tried. I don't wait until the end of a project to flip a switch and hope all the lights turn on. I instead test each light as I go, feeling for the next one when the time is right.

Adolfo never laid out his whole tile pattern before starting to set it. And I think as a consequence, I never saw him tear down an entire project and have to rebuild. He saved all that time by measuring, cutting and setting one tile, nice and steady, at a time until the big picture emerged.