Here at Aptera, we strive to build a culture of professional growth and mentorship. A part of that is our internship program. This past summer we had the pleasure of working with two software interns. One of them, Joel Stauffer, has written a retrospective on his summer working here with us and what he learned using test-driven development. Take it away, Joel.
No, retrospectivious is not a word. Use it only if you have a sparky flavor of imagination and a thick skin. But this is a retrospective on an internship that pushed the practice of TDD (test-driven development).
SO, did I survive? Was it dogmatic and did the experience taint my ability to ever write a successful program again? The first answer is clear given this is a retrospective. The second, I can answer with a resounding “no” followed by another “no.” I can safely say that TDD has done nothing but enhance my ability to write clean and maintainable code.
Joel (background) works collaboratively with fellow intern, Isaac Smith.
To be fair, though, my instruction on TDD was delivered by two seasoned developers who knew the “whys” and “hows” that make the practice useful. For their credit, these developers are Jon Fazzaro (currently) of Aptera, and Bob Martin (affectionately known as Uncle Bob by many of his fans). I received the grand tour of the three steps, the most valuable targets of testing, some pairing on a couple of katas, the practicality of using mocks, and instruction on the use of language to illustrate the purpose of a program.
Of course, my first impression of TDD was, “Okay, this is what ‘they’ do ‘here’ and if I expect this internship to go well, I have to learn it.” It started with a couple videos, a FizzBuzz kata, some Q&A, and then eventually some shiny new production code. I’m not sure when it happened, but now I like TDD. Honestly, what hooked me on the practice wasn’t the tests at all. It was what the tests allowed me to do that locked me in.
I spent the first week of my internship watching Bob Martin showcase the height of clean code. A demonstration of short functions, descriptive names, proper boundaries, extensive extractions, dependency inversions, and others I’ll omit for brevity, had my programmer’s mind itching for that clean code. But it’s all a gimmick, the minute a programmer’s finger hits a key the code becomes dirty. No surprise here—humans naturally write imperfect code on their first attempt. The only way the code can be restored to a clean state is through constant refactoring and that isn’t practical without tests.
“Wait, can an intern say that? He’s got no idea what the professional world is like!” Well, yes, if that’s you screaming into your device: you’re not wrong. Coming on with 6 years of programming practice doesn’t make an expert in anything. But I’ve watched projects small and large descend into chaos and I know that isn’t sustainable for an individual or a company. TDD is the only solution I can see that gives me the confidence to instill my organizational mindset into the code I write. Without a suite of fast tests, I can’t make any change to working software and have an adequate confidence it is going to work in any end user application.
But this is hardly the end of my TDD story, but rather a barely manifested beginning.
Time will tell whether I continue the practice. I am not immune to the troubles that have routed the practice from other developers. Ridiculous deadlines, frustration, poorly designed tests, and other unknown obstacles stand in my way that will either derail my TDD practice or temper it. I hope to look back on this experience as the beginning of my professional career, and not with the regret of having dropped a practice that solves a host of naturally occurring problems.