I know how to Panic & you should too
Almost exactly one year ago, I quit my job after 9 years and two months with the same company. I packed what I could fit of my belongings into my little Honda, gave a whole bunch of things away to my friends, put the remainder in storage, and drove across the country to learn how to be a software developer.
My seven-month coding school was intense. I spent close to 80 hours each week in class, studying, or working on projects, doing my best to learn the ins and outs of object-oriented programming and test-driven development with Ruby on Rails. Fortunately, I had some amazing classmates who were there to help with questions, celebrate successes, or have a good cry in the “crying hallway” as we lovingly deemed it.
Interestingly enough, I never realized how much I valued learning until I was in the throes of school. I surprised myself on more than one occasion with my own personal reaction to writing code that finally passes. Have you ever hugged someone because a line of code you wrote didn’t break something else? I have.
I also didn’t realize how much not understanding something could bother me until I was back in school. Have you ever cried because it seemed as though everyone else understood something and you just didn’t? I’ve done that too.
Long story short though, I learned enough to graduate and landed a job with an awesome team. I was so excited for day one at the new gig that I completely forgot to focus on why I should be terrified: my new team doesn’t write Ruby.
A significant portion of our codebase is in Go, which is a statically typed language. Ruby is dynamically typed, and since Ruby was my only experience, learning Go was (and continues to be) a brand new adventure.
I’ve done several tutorials and am slowly tackling tickets for my company’s codebase; however, because a lot of the learning I’m doing now is gradual and often by exposure (my manager termed “learning by osmosis”), it’s harder to discern a particular win for myself. I can get pretty close on a lot of things, but I often (read: hourly) need to reach out to my teammates for help to finish up a particular challenge, and that’s okay. I know I’m learning; it’s just harder to quantify for myself. That is…until today!
Since I started learning Go, I’ve come across the log.Panic(err) function and I just assumed it was another way to record errors. I didn’t understand the use cases or really why Go had it, since it seems to be such an efficient language otherwise.
For the last few days, I’ve been working on trying to build a Command Line Interface tool in Go (a Ruby challenge that made me cry in school!). We need our user to input specific information in order to make the tool operate. If the user doesn’t input the appropriate information, an error will occur.
The original error was panic: runtime error: index out of range, which means that the user didn’t provide any input, but the error message doesn’t clearly state that, and that’s not helpful. I tried several different alternatives to get around this: taking the length of the input and measuring it against 0, logging that particular runtime error and returning a different message as a case statement, and several other things that just didn’t pan out.
Because the original error was a panic, the thought occurred to me to try to record my own. A panic will cause the currently running program to exit, so it made sense to me that this could potentially override the existing panic, and it worked!
I was working remotely today when I figured that out, so I didn’t have anyone to hug or high five, but I did share several extremely excited Slack messages.
Learning to panic is an extremely small win; however, it’s one of those little victories that I hope will be repeatable in different ways throughout my career as a software developer. I hope you’re able to take some time to celebrate one of your own little wins today, and I’m sure there will be more where that came from tomorrow.
