The following are thoughts regarding Test Driven Development and the problem-solving process. I finished a coding kata last week that was also a TDD Challenge for an Apprenticeship. TDD is a Software Craftsman/Artisan practice, and there’s a good reason why it’s used.

First TDD Session

My first exposure to TDD, years ago, was in a pairing session during an interview. I was told ahead of time that I’d be pairing with a developer on an exercise. Pairing was something I had experience with, but TDD was not. I can’t remember the exact problem, but that day, what really stood out was how the tests and steps were methodical or incremental (how I currently describe it to be). It was an easy going kind of session, and the process chipped away at the problem and inched toward the goal. Write a test, write code to make it pass, refactor, then repeat. The most interesting thing: as the final line of code was written, it felt like a revelation.

I recall saying something like, “Wait, we just finished. That’s it?”

I remember my pair responding, “Yes.” No further tests were needed. I was surprised it was done. That remained with me until now because that’s how I’ve come to know code. Good tests yield good code, as far as I know. Refactor, and make it better. It reminded me of Proofs from Geometry class. Identify what you can, and the rest will eventually take care of itself. I relished those challenges, and loved solving Proofs.

Adopting a Test Driven Mindset

As a Rails Intern at Hearken, Corey emphasized the need to think incrementally. And I understand why there’s a need to do that. Bit by bit leads you down the path, and reading your errors will lead you to the right code. It ultimately translates to a similar practice as done through Test Driven Development, but with writing tests first.

The Challenge

At first glance, the kata itself made perfect sense but could foresee future problems. I couldn’t necessarily map out the solution in my mind or even write it out, though realize this should not be a point of emphasis with future coding exercises of any sort. That adds unnecessary worry. As I started to break down the exercise, it seemed to be more and more doable. That’s the beauty of TDD in that it forces you into the habit of thinking step by step. I wrote assertions, then wrote code. Refactored, then repeated.

As I was progressing, I noticed code smells to address as best as I could. DRY and SOLID, namely the Single Responsibility Principle, came to mind. There was a point where my code drastically took a turn for the better, and that was when things started to click. Code went from clunky to tighter, more succinct and readable. Even if “how do I get from Point A to Point B?” was unclear, refactoring showed the way.

After submission, I realize I could’ve gone one step further and perplexed why I didn’t see obvious oversights. Kinda kicking myself, but I suppose that’s something that comes with more practice and exposure. All I know, at this point, is to be aware of that and continue learning.

Aside: A Parallel to Mixing

The oversights I just mentioned are similar to when I finish a megamix. Before notifying my audience, I often go over my pieces with a “fine-tooth comb.” I’m not sure how many times I re-listen (it’s a lot), but am always magnifying any errors and things that seem like they could’ve been done differently. If I stumble on something that bothers me, I make the adjustments and correct them. I should mention that many of my older mixes have segments that probably shoud’ve been done differently, but again, that is part of the maturing process. I learned from those oversights, and make sure I correct those errors for the next time. It’s cool when others notice my progress.

In the grand scheme of things, I’m this way with everything.

Wishing I could find a related story/quote I once read, but will append when found again. To paraphrase: During reviews, this manager essentially asked if what they presented was their best. And reminded them, when finished, their work would have their name associated. What this would do is encourage perfectionism and something more memorable put into the end result. Following those interactions, these people would take this feedback and push their work even further.

It’s something I like to keep in mind when working on something that I’m very much involved in, and a natural reflection of what my work ethic has been. And still is.

The Software Craftsmanship Movement

I understand the term is changing because of inclusion (very commendable), and I’m not sure what the official decision is. Pillar is calling practitioners Artisans, a Slack group has renamed themselves to Software Crafters, but the software practice and principles remain. In more recent exposure to other practitioners, it’s clear that these are all in place to uphold standards and be conscientious of future maintenance among other things. I’m convinced Test Driven Development makes you a stronger programmer, and other benefits are invaluable whether for the programmer or organization.

Should I get an opportunity to practice professionally, provided I reach an Artisan’s level, I would encourage others/wouldn’t hesitate to pair with others to further the movement’s reach. I perceive becoming an Artisan similar to getting a black belt in karate, a hard-earned and well-respected accomplishment. It symbolically represents “internal growth and discipline than it is about fighting prowess (or in this case, being a programmer).”

In finishing the kata, it reinforces how much I’d like to follow this path. There is care for code as a craft and a specific purpose in making the decisions you do. It seems to be a natural fit, considering my previous practice in visual design, and blends the technical side with aspects of collaborative creativity.

Approached this way, code is developed in a culture that keeps me going and fully engaged until it no longer needs its development team. That is, after it is completely handed over to the client or owner (for the most part). My understanding, not just as a teammate but also as a Developer, is the need to be committed to the process, the product and ultimately, the end result. It becomes the most ideal situation when the product aligns with personal goals and makes a difference. And ironically, it echoes the design process I’ve learned long ago.

To say that I’d “like” to have that black belt doesn’t fully convey my wish. I should say, “That black belt is mine!” similar to when my child self would see that shiny and cool new bike he wished to have.

Image from https://www.keepcalm-o-matic.co.uk/p/red-green-and-refactor