Free Trial
Learning

Taking a vacation from writing code to write more code

Amelia Aronsohn's profile picture Amelia Aronsohn on

I think we can all agree that taking vacations from work is super important. Even conventions and summits, while offering a big boost of energy, are still work; you are fighting over the same problems and trying to overcome the same challenges you take on forty plus hours every week. Sometimes you need a break.

Recently I took a break from writing all this code and took a short vacation to write more code. It was awesome. Let me explain…

Taking time for personal projects

Personal projects: Most everyone who writes software has a big pile of personal projects and code on their github or squirreled away in a ~/Code folder somewhere. Some of that code I use more than other. One program I use frequently is a command line MUD client (go ahead look it up, I'll wait). Yes I still play on MUDs over MMORPGs. Anyway, this client is something I wrote a few years ago in Python 2 and it's proven to be very stable (if not a bit of a resource hog) for what it does. However porting it to Python 3 has been a challenge because it depends on libraries that have fallen behind.

Taking time to learn something new and exciting

I spent most of my days writing in interpreted languages, Ruby and Python. However there are so many amazing languages and systems out there—every language has a strength and weakness—it's much better to take the right tool for the job than to use a single language as your "everything hammer". It's not often, if ever, that you can spend your work days devoting the time and energy required for learning one of these languages or trying out new stuff. Fixing what you have and adding value for customers is top priority.

I have a big love for compiled code. C, while a pain to debug, is both a fun and fulfilling language to get something working in. I even know and have written a few small things in ASM. Working on the low level for something highly optimized is just fun. To be honest though, I've never taken the time to get exceptionally good at it.

After finding a fun tutorial on how to write your own shell in C and write a system call I was thinking about re-writing my MUD program in C to make it more efficient and portable without all the Python dependencies. @weppos then recommended leaning Golang while I was talking about the trouble of debugging C bugs as I was working on those two projects above during some downtime.

Where was I going to find the time to not only learn a new language…but also re-write an entire program?

The code-cation

Needing a bit of a break from the project and bugs deluge, I took a Monday and Tuesday as code-cation to make a plan. I started going through the awesome Tour of Go and started fiddling with some test code and a framework.

Starting Sunday I put all my other things aside and silenced Slack. I wrote, read, got confused, and wrote a lot more. I made mistakes and fixed them…just working on this personal project for three days straight. Reading Tour of Go got me far and wide, lost somewhere around how methods are handled, and then the concurrency/channels were just… what? Through writing my own code and reading a lot of the code in the in the standard packages (which is helpfully linked in all the docs) I was able to figure out far more far faster than if I had sat around and banged my head against a book until it magically made sense. Through debugging I was able to discover tons of new stuff. Fun fact: don't end your program with two go routines that run the body of your processing. The main will fall through and kill the whole thing fast—you will be very confused for a while.

By Monday night I was struggling out the last bugs to get a 0.9 release that worked, while missing a few features I wanted. By Tuesday night I had read up on go styles so as to refactor some parts of my code to be more idiomatic, tested it out on a few machines to tweak out minor bugs, and stamped out a 1.0. Later that evening I was testing out cross compiling and uploading release binaries to GitHub.

Conclusion and Takeaways

Now this wasn't the biggest project I could have picked; I was able to chunk it out in about 310 lines of code all said and done. However in three days I was able to implement most of the major features of the language to put together a readable and useful program that I will hopefully be able to use for years to come. That feels amazing. While three days at home and at coffee shops for someone who works from home and coffee shops doesn't sound amazing; the feeling of doing the compiles and uploading those releases to GitHub was superb (not to mention uploading the program to my FreeBSD server and logging in).

After all was said and done, it was an awesome experience. It also gave me the experience and knowledge to move forward professionally as well. If you have a project laying around that needs work or something you want to learn maybe a code-cation is for you. Also don't forget the power of learning by doing.

Oh and since you read this far, here is my program. If you have comments or critiques I'm very interested since it was my first real Golang program.

Share on Twitter and Facebook

Amelia Aronsohn's profile picture

Amelia Aronsohn

Kaizen junkie, list enthusiast, automation obsessor, unrepentant otaku, constantly impressed by how amazing technology is.

We think domain management should be easy.
That's why we continue building DNSimple.

Try us free for 30 days
4.5 stars

4.3 out of 5 stars.

Based on Trustpilot.com and G2.com reviews.