Traversing the Internets

Web Development in NYC

Flatiron School Day Eighteen - Suck It Up, Break Your Code.

| Comments

I was going to write another small technical post today but that is going to have to wait until tomorrow. Today I wanted to remind myself and anybody who reads this about the mental blocks with regard to refactoring your code. Here at Flatiron we follow the (I think Kent Beck) motto of “Make it work, make it right, make it fast.” Sometimes this leads to the first working piece of code being pretty ugly. If you’ve just spent hours in a team working through pitfalls to get the code working, it may be overwhelming to go ahead and start refactoring the code once its running and/or all your tests are green.

The big thing I wanted to focus on is that provided you’re not living in an alternate dimension where there is no Git, you can feel free to burn your working code to the ground and swim in its ashes. You still have that working code in version control, there is nothing intimidating about altering it to where it starts failing tests or stops functioning. Even if you never find a better solution on a given project, you never will if you don’t start smashing your code and trying to rebuild them.

In Office Space they took the printer out into a field after one too many “pc load letter” errors and smashed it to pieces. Unfortunately with hardware, its pretty difficult to put back together. Count yourself lucky that with code that is not the case, you can destroy your project over and over again and roll it back if you aren’t making useful progress.

Get over the fear of the red results and break your code, it’s liberating.