The Benefits of Throwaway Code

Last week I showed an example of a decision doc that I had written up to help decide the data structure for my unnamed modeling tool. I was planning to write up an implementation spec this week, but I found myself struggling to get started. I decided to try a spike instead.

For those of you who haven’t heard that term before, a spike is a way to explore a technical idea before committing to it. It’s a way to discover how this idea will interact within the rest of the application and uncover any dragons that may be lurking in the distance. It can involve research, design or prototyping. A key thing to keep in mind with any code that you write during a spike is that it should be throw away code. Don’t get attached to it! I have a hard time following this rule, but trying to get better…

This week I did a spike to test out the changes I wanted to make to the data structure for my tool and I’m pretty happy with the outcome. The output of the spike is a few commits that test the new structure. I also got some great feedback from fellow engineer and cousin, Daniel Larner as well as accountability buddy André Terron. They both tested out the app at different stages and exposed some bugs as well as confusing UX that I fixed this week.

New Version of the Modeling Tool

Speaking of that… here’s the newest version

Next Week

Next week I will be looking into re-implementing the build / migration system. I’d like the build and migration buttons to help onboard users to use Contexts and allow them to specify where files get built to, depening on their Context. For example, you could build your client files into a create-react-app and your database files into your API repository.

I’m also hoping to do a few more user interviews to see if the changes from this week have improved the onboarding experience and made things easier for first time users.