Jacob Landry's Blog
Limit Your Tools. Enhance Your Mind.
So I have this problem, and I'm sure I'm not alone. I love development. Taking on a new project can be so exciting that you're just bursting to get started. Planning out your database schema, mapping out what classes you need, planning out the best way to approach some of the more complicated problems you know you'll face...it's all so exciting. Normally I just can't wait to get started but therein lies the problem. I have a tendency to start a project so quickly, my mind racing on all the fun features I'm about to develop, that I bounce around from file to file or topic to topic, never fully finishing what I started. I always intend to circle back and complete things, in fact I have to for the product to be finished, but by the time I do I've worn out that excitement and I just piece things together as needed and move on. By allowing my excitement to take over I actively doom my projects to a rough ending. While developing this blog, however, I think I've finally found a solution that works for me.

I'm certain I'm not alone here. Any developer who truly loves what they do must face a similar crisis, at least sometimes. The same can be said for many other industries as well. I'm sure there are countless stories of sports injuries caused by someone unwilling to take a break, books that jump from topic to topic when published, or games released with a plethora of promises but very few actual features. As a species, we love to produce results. While results are important, this desire to constantly be delivering output causes us to rush through things instead of taking the much needed time to plan them out.

Let me talk about a specific example from my own experience. I recently built a Laravel site geared towards allowing users to organize their video game library so that it is easier to decide what game, out of the dozens you own, you would like to play next. That's a pretty simple goal. The only need for that is to be able to have a library of games, mark which ones you haven't played yet, and maybe add the ability to sort them by priority or current interest. Easy right? Well I found that when I started my project and booted up PHPStorm, I had in front of me the entire world. I built my Game model, migration, controller, etc. Proud of myself, I took a step back and admired the beginning of something that I thought would be really helpful. So I started on the UI. First I needed to make a search for any game in ththe database. Easy. Suddenly, in front of my eyes I see a list of game titles. Well, that's boring isn't it? Let's add some pictures, maybe a link to a review of the game, how about a rating? Oh, can I rate it myself? Ok now if I want to say I own it, what platform do I own it on? Should I own platforms too? Sure let's add a model, controller, and some views around consoles now. Should on be able to rate those? What if I sell one? OK, I'm rambling now but you get the picture. At this point I'm a few hours into development and I've started to build this massive tool that doesn't complete the original goal I set out to achieve! Granted, some of these added features were neat additions, but ultimately they were a distraction from my goal for version 1.0 of my project. Not good!

Now, before I detail out the solution that has worked for me, I'm sure a lot of you are thinking "why not just slow down and take things one step at a time?" Things aren't really that simple, though, are they? If everyone could just slow down and take things simply there'd be no car accidents, no one with eating disorders, no one addicted to cigarettes. We can't simply force ourselves to behave logically, we're an illogical species. Instead, adapt your environments and habits to try to force yourself into a healthier situation. Habit changing isn't a new topic and I'm not trying to claim I have stumbled upon some amazing revelation here. Like every self-help book in the world, this is largely common sense. But I found I had to stumble through it myself to really hammer it home.

My solution was to simply limit my ability to work quickly in one easy step. In the early stages of the project, don't use an IDE, or at least not a good one. For this very blog, I started out in the terminal with vim. Being a Laravel project, the Artisan command provides you with more than enough power to begin work. PHPStorm just added so much fluff that I thought I could tackle the entire project at once. By forcing myself to use something that is a little less feature-rich I had to really focus on what I was doing because any mistake would be very costly and annoying to fix.

Now, I'm fully aware that a vim expert can probably do nearly, if not completely, the same things that a developer using PHPStorm can do in the same amount of time. I, however, am not one of those gods. I know how to navigate a single file in vim quite quickly. I have a vimrc file that I really like and it creates a formatted file that can be opened in an IDE later, without too many problems. I never bothered to learn how to use multiple tabs or anything like that, so while using vim I'm pretty much forced to only work on one file at a time, per terminal tab.

Suddenly, my initial development process came to a screeching slowdown. My goal was to create a clean and simple blog, devoid of the heaps of features that makes Wordpress so difficult to trudge through. I wanted my block to have a singular purpose: to provide easy-to-read content for a user. So, naturally, I use Artisan to create all of the models and controllers I will need. Once those are done, I would normally open them all up in my IDE and start work. This time, however, sticking with a single terminal instance, I opened one file at a time and worked on it until I felt that it was complete.

Sure, this led to a lot of moments where I was typing slower or perhaps spending a lot of time thinking about how one particular model needs to connect to other models, or what type of setup or relationships I had already established on previous models that I needed to wrap-in. Things like that are far easier when you can quickly jump to the other file to review your work, but thinking it through more fully allowed me to write cleaner, more concise code on the first pass. As with every project, once I had a working version of my code, I did a second pass to clean things up and make it look a little nicer, easier to read, and easier to maintain. I noticed instantly that this pass was far quicker and easier than usual. While I may have taken a bit longer in the initial development phases, the rest of the project zipped together at the end much more smoothly than usual.

The next phase of the project, as always, is bug-fixing and feature-creep. I bucket these two together because I always feel like I start to add features as I fix bugs that I didn't really plan on adding. Things that will make work easier, maybe, or interactions easier as I'm trying to debug problems. Again, forcing myself into Vim for this process forced me to change the way I usually work. Normally, I would have all pages open in PHPStorm that are affected by any particular bug, or may be affected. Then I'll start adding debug lines to the files (or breakpoints if I'm using the debugger like a good buy) in an effort to find where the issue is really occurring. Of course, this leads to a lot of cleanup at the end and, as mentioned before, a lot of jumping around and half-complete code. I might start fixing a function in Model A, only to find that it requires a change in Model B before I finish it. Instead of finishing the change in A, I jump to B and work on the change there, then return to A and hopefully remember to finish what I was doing. Slowing myself down and making file-switching a little more cumbersome pushed me to fully complete each phase/fix before moving on to the second task. This resulted in more complete code changes, fewer newly-introduced bugs, and a more solid understanding of the changes I was making and how they impact the greater system.

For the final phase of the project I allowed myself to finally open PHPStorm. I find that I really enjoy having an IDE for adding all of my block comments on functions and making sure the documentation is up-to-date. I added comments into the code when I was working with vim, but I do appreciate how quick and easy PHPStorm makes that process so I deferred a lot of that work to the end. I will say that this is a very dangerous practice. In this instance it worked out for me just fine, but I can definitely see a case where I might be rushing to finish a project for a deadline and never bother to go back and make these comments more robust. So definitely be aware of that situation if you are like me and would rather work with this stuff in your editor. There were also a few, more minor, cleanup tasks that I held off on for PHPStorm. As any developer, I am always learning new things. I did find that before I ended the project I had learned a series of new things about validation and error-reporting that I wanted to wrap into my project. This, of course, meant editing several controllers and views with just a few lines of changes (usually something I could just copy/paste). This work was much faster and less dangerous to do in PHPStorm than it would have been in Vim. I also modified some of the file-structure for my views in PHPStorm as it is easier to move files and quickly update any references to those files in the editor.

In the end, forcing myself into a situation where I had to work slower and more thoughtfully really pushed me to build something more concise, streamlined, and elegant. Being a lover of Laravel, I do consider myself a PHP Artisan and it felt good to really commit to that role and write a beautiful piece of code that is functional, easy to read and maintain, and something I can be proud of. I found that there were certain tasks, as mentioned, that worked better in my chosen IDE, but taking the time to really separate those tasks out and understand what can be developed in what tool (and why) gave me a solid base for development and a lot of confidence in the end product. I plan to push this forward in future projects and will provide updates as I hone in on this process more and more.