A little over a year ago, I started to get serious about learning Ruby on Rails. As a kid, my father had schooled me on the fundamentals of QBasic, and I’d more or less taught myself intermediate-level Visual Basic as a teenager. But as other interests took priority in the following years, my coding hobby fell off and I almost completely abandoned it until 2013 or so.

Even once I slowly began to reenter the world of code, I hardly knew where to start and frequently fell off the wagon (by which I mean I’d completely forget about it for weeks or months at a time). It really wasn’t until last April, when I started focusing on a real project, SCOTUS Search, that I began to find enough inspiration to spend many consecutive hours immersing myself deeply in coding heaven/hell.

Here are a few things I’ve taken away from my experiences in the past year or so:

• Be nice to developers. I never truly understood what a misnomer an “alpha” or “beta” release really is: end consumers tend to think of this as the shaky, rough first (or second) pass of a new product. In reality, it’s likely the culmination of months or years of painstaking work. Yes, it’s rough and buggy as hell in comparison to commercially available software, and this is a perfectly valid way of looking at it as a consumer. But from the point of view of the developer, even an initial release represents an extremely gratifying endpoint to untold hours spent staring at color-coded lines in Sublime Text and researching arcane error messages on Stack Overflow. So, what I’ve learned? Be nice, even when you’re criticizing. That mobile-unresponsive, typo-ridden monstrosity of a web site is still someone’s baby.
• Nothing feels as good as overcoming a major coding obstacle, or as bad as being stuck trying to figure one out. There was a point recently where all my work on SCOTUS Search ground to a halt because I couldn’t figure out a relatively simple problem: how to implement an AJAX-powered comment box and make it appear on the page when a user clicked a message icon. For some reason the problem got into my head and I began to see it as this massive unconquerable thing. Once I’d finally discovered how to make it work, I felt like dancing around my living room.
• If you’re a new developer, your code is almost definitely terrible and embarrassing. I shudder to think what any real developer would think if they saw the way I’ve built SCOTUS Search. And I’ve been telling myself for months now that, once I find a good stopping point, I’m going to go back through all my existing code and clean it all up: use more partials, strip out complicated logic from my embedded Ruby files, optimize my ActiveRecord queries, etc. Yeah, I still haven’t found a good stopping point. And my code keeps getting more and more complex, making any eventual housecleaning even more difficult later on.
• Version control is an incredible thing. Git is possibly one of the best gifts ever given to developers. Personally, I use Bitbucket for SCOTUS Search (unlike GitHub, Bitbucket allows users to create private repositories for free), but the underlying service is still Git, and it’s crazy useful. If you don’t use it on your project, change that as soon as possible.
• If you’re in a non-technical position at a company and your engineers tell you your request can’t be done, they’re probably bullshitting you. This is somewhat bipolar of me, given my first bullet point, but there’s rarely something that literally “cannot be done” in coding. Much more frequently it’s simply a) extremely difficult, b) extremely complex, c) extremely inefficient, or d) extremely uninteresting to the developer. But that doesn’t necessarily mean it shouldn’t be implemented, and if you don’t understand a damn thing about coding, your engineering team is likely using that ignorance to their advantage by making your request sound as impossible as they can.

I’m sure I’ll have more thoughts later on, but those were some of the initial things I’ve come to realize over the past year or so. Let me know of others in the comments!