Go Workflow

My web development workflow in Go is not much different than how I used to work with PHP, but it is slowly shifting in subtle ways.

When I first started learning how to program, using PHP years ago, I would work in short feedback loops. I would hit F5 to refresh my work all the time. Often with the smallest change I would refresh just to see what would happen. Such a short feedback loop helped me learn specifically what each little change would do and how it would affect my website. As I progressed in learning I would code longer between F5 refreshes.

Feedback loop

In PHP I work in a short feedback loop. I look at the outcome requirements and I plan a way to get there. What code will I have to update, what new code will I have to write, and how will they interact. For larger blocks of code I plan how to modularize them, what are the inputs and outputs, then I code up a working example as fast as possible.

Once any new business logic code has been completed I wire it into the front end. I code, tweak and adjust, then F5 to see my website updates. I love seeing how my application shifts and morphs as I refresh and refresh as I update code. The short feedback cycle helps guide me. The positive and negative emotions I feel as things start to work or fail to act nudges me ever so slightly in the right direction.

With Go my feedback loop isn't too different. I develop using vim and tmux. I keep my compile and run command in window 0 and edit code in the rest. I have apache setup to proxy non-existing requests to localhost, where my Go binary is listening. DEV listens on a different port than LIVE.

With Go I have the same requirements process as with PHP. I start coding on the core functionality that is changing the most. Then I move onto wiring it into the existing functionality.

I don't refresh in Go as often as I do with PHP, but it's just about as easy. I switch to tmux window 0, ^C to kill my running process, then go install, and run the new binary. Then F5 in my browser and I'm looking at my updated changes.

Most of the time Go is done compiling by the time I switch to my browser and before I even have a chance to refresh.

Easy transition

The feedback loop is not much longer than when using PHP. There is the extra step to kill and recompile the binary, but doesn't slow me down. Which is then why I find it curious that I find myself using this refresh/feedback loop less and less. With Go I find that I plan more and wait longer between feedback refreshes. There are also times when all the feedback I want is to see if the binary will compile.

The similarities in feedback loop between Go and PHP helped me become comfortable with learning Go. I was able to see my changes as fast as I had before, which helped me learn the eccentricities of Go. Without having to greatly modify my development process I was able to learn Go.