It’s been one week since you looked at me, cocked your head to the side and said “How’s school going?”
Now that pre-work is over, and we’re getting to the meat and potatoes of this bootcamp, I’d like to take a moment to reflect on where we’re headed, and acknowledge how far each of us has come.
Transitioning away from work, and back to school has been an interesting ride. Remembering how to study is one thing, but at the heart of this is the reason that we’re here : learning how to code. Over the course of the last week alone, we’ve worked through one programming language, abstracted away redundancies, and learned how to build databases and tables — Ruby, and OO, and SQL — oh my!
How have we been able to cover so much ground, so quickly? While the Flatiron curriculum and our instructor and coach play large roles in shaping that progress, one key aspect is TDD — test driven development.
A number of common teaching methods emphasize wrote memorization, and learning to test well. While this may please team Scantron, memorizing facts and being able to rattle off a list of them doesn’t show us what insights we can gather from those facts, and having to manipulate the data we “know” in a different environment becomes a nearly insurmountable task.
Test Driven Development however, builds forward from simply “learning by doing” and helps developers learn directly FROM the code we are writing. If I know what answer I expect to return, and I think I have built a method that will get me there, the only way to know if it works is to try it out. No more waiting on the sidelines, we have to launch keyboards first into the unknown.
“But what if I fail? What if my code is broken?” Good! That’s the point! We want to play around with our code in a safe, controlled environment of our test specs to ensure that what we are building works. And if it doesn’t? By reading the errors, and comparing the output to what we expected, we can try again. Even better, we are now armed with additional insight into what we can adjust, how we can refactor, and what new ideas are sparked for the next test.
Embracing failure here is so much more than taking the stigma away from not seeing your tests pass. Every error message points to where the hiccup occurred, and what the computer anticipated seeing at that point. What’s more, going from one error message to a different error message after refactoring helps us understand exactly how we changed our code. If only real life was that clear!
Test Driven Development is not only exciting for me as a developer, but for me as a person. By reframing and re-defining what “failure” means here, I’ve been able to reignite my curiosity in a way that I haven’t allowed myself to experience in a long time. If just over a week can do that, what new adventures will I discover by the end of these fifteen weeks? Who knows — and I can’t wait to see what discoveries my next “failure” will bring!
