Writing code is easy. Writing clean, maintainable, scalable, well-tested code can take decades to do well. Design patterns compare to programming as poetry compares to writing. Being thoughtful about the code you write in the beginning of a project is essential as it builds the foundation of your software’s future. Some developers rush the planning process for many reasons, such as limited time to work on the project, improper training of new programmers or even just plain laziness. Myself along with two others worked on a project for the Hawaii Annual Code Challenge for a four-week time period. We were very eager to get started as soon as the challenges were revealed which caused us to rush the planning phase a little bit. As you may have guessed, as we started to expand our app and add new features, things got a bit messy. With a lot of “hacky” solutions and repeated code we got our first prototype completed. We celebrated as we got a working prototype however, we quickly realized that this type of programming is not sustainable. About a week into our project, we noticed that it was taking much longer to add new features than it did at the start. This is when I decided that it would be best to refactor large chunks of our code base. After about a day of refactoring and no new features added, it felt like a waste of time. The next day was our most productive day so far. My code was starting to become more readable and finding bugs was very easy. That single day of refactoring code saved days of development time throughout the next three weeks.
Refactoring code almost became an addiction. I started refactoring code into functions everywhere I could. It was at this moment that I realized that there are diminishing returns to refactoring code. I had to find a balance that allowed myself to be the most productive. I noticed that some of my javascript files served more than one purpose. This made it difficult to find where code resided in my project. Once I separated these large files into smaller, more focused files, I had an easier time locating possible sources for bugs. Even without a proper education of designed patterns, just being thoughtful about the code I wrote helped me stay on the right track. Thinking about the future of the project and not just the next milestone helped us to write cleaner code. The Hawaii Annual Code Challenge taught me many things. If I participate in the hackathon next year, the one thing I would do differently is to have a plan of action from the start, draw some diagrams, have discussions, and listen to outside feedback before getting to the code. I hope that one day my code will be more like poetry and not just writing.