Chipy Mentorship — Learning the hard way

Sometimes learning the hard way is better, sometimes it’s just harder.

I’ve written tests before. They are simple, mostly simple tests to make sure functions return what they are meant to return and that objects are the correct type. I’ve written simple apps before, mostly dashboards and data tools. But, I don’t think I’ve every “shipped” software. Not really.

The gap between “hacking something together”, the methods and classes I’ve written before and actually deploying software is on an exponential scale. I didn’t know that until that past few weeks as I’ve worked though a Test Driven Development Process for the first few pieces of my app and started working on deployment. There are a few contributing factors to the difference in difficulty.

  1. This is the first web app I have built that is meant to be used by people other than myself or other developers.
  2. This is the first web app I have built that is meant to last beyond the first development cycle.
  3. This is the first web app I have built that will be scrutinized by others.

Considering the User

Everything I’ve built so far hasn’t had to consider a variety of user interactions that this app is planning. For a lot of what I’ve built the user has been me with a single use case. Planning for users is the first reason to use test driven development. Functional tests are very useful to frame and plan user interactions. It’s also a great way to have both technical and non-technical people to agree on the scope of the app. I’ve worked through that exercise here.

Planning for the Future

I’ve only ever expanded on an app I previously built once. It was a piece of software built for scraping baseball data. I didn’t write it with tests, I didn’t create much documentation. It was a massive pain to expand/upgrade. This app is just the start of what will likely be many cycles of development. Tests both unit and functional will make incremental and evolutionary development on the site better. This seems to me to be the real value of test driven development.

It is harder, but . . .

Test driven development is harder. It requires the developer to make more deliberate, thoughtful decisions. However, the process means less tech debt, easier deployment and self documentation. It is better.

Sometimes I make it harder that it needs to be

I think it is natural to be self conscious about code. It can feel like the quality of code is a reflection of my intelligence, value as a developer and sometimes worth as a human. It doesn’t help that 80% of my code is seen by at most 1–2 other people. This project is public. It is on display. As a result I’ve been really careful. The balance between writing something cool, smart, clever and writing something that works is a little off.

I’m not saying you shouldn’t try to write good clean code. But if you are spending hours trying to figure out how to one-line something what the 2–3 lines you have is working then I think it’s gone a little far.

I’m a little behind — I’ve had a few other things get in the way. But I’ve got some open time coming up and I’m looking forward to pushing this thing forward.

Like what you read? Give David Matsumura a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.