A co-worker of mine recently attended Strange Loop in St. Louis and directed me to a presentation by Felienne Hermans about spreadsheets and their potential as a tool for developers. Although I’ve lost some of my Excel skill since my finance days, I find that the thought process underlying software applications and spreadsheets are remarkably similar.

At any large conference like RailsConf, there’s bound to be a mix of presentations. There’s only so many talks you can listen to about service-oriented architecture (or TDD?) before it becomes a catchphrase, devoid of all practical meaning. Thankfully, Ruby Central, the RailsConf organizers, tried to organize the talks around certain themes within four tracks in order to both group together and spread out the related talks. These themes had titles like “Beyond ERB” (how to set up front-end views without ERB), “Play Nicely” (how to work in a team environment and contribute to open-source) and “Big Rails” (how to manage and refactor a monolithic Rails app).

This past week, I had the great privilege to visit Chicago and attend RailsConf 2014. Before RailsConf, I had been to two conferences - GORUCO 2013 and Windy City Rails 2013 - both of which had enough attendees to fill only a single track of talks. RailsConf, on the other hand, had four tracks (even five, at times) that were roughly grouped by focus area, like around domain design, careers or refactoring. Needless to say, RailsConf 2014 was the largest conference I’ve attended in my short career as a developer.

I’ve found that as you progress in your code career, you start to discover more patterns in how to structure code and how to address common questions. In the same vein, you also learn what not to do and your sense for code smells improves. Your methods might get smaller, your logic better encapsulated and your classes more singularly responsible. Thinking more strategically about how to implement features with an eye to code maintainability, complexity and readability is a career-long endeavor. There’s no single set of tools that will make you a better developer, but I’ve recently come across several gems that have helped me develop a better sense for code quality and development standards.

The turning of the calendar to a new year tends to beget nostalgia and recollection for both the good and bad from the previous year. I like to set goals for myself and check in periodically on my progress, and the start of 2013 was no different. I recently looked back on what I set as my New Year’s resolutions, and I’m happy to say that I accomplished the top priority goal: learn to code.

I still feel humbled and grateful for the opportunity to transition seamlessly from finance to technology that I jumped on around this time last year. 2013 was a year of much change for me; the year I traded Excel models for web applications and committed to learning a new, complex skill set. Overall, I’m very happy with my decision - I enjoy my job, I believe in the mission of my company and I get to cultivate a valuable skillset. With last year introducing such considerable (and positive) changes in my life, I’m eagerly looking forward to what 2014 has in store for me. Here are a few of my more technical / professional goals that I hope to strive for in the new year.

In software development, the Single Responsibility Principle is a bedrock principle that transcends language or framework. The SRP states that each function / method, class and module should perform a single responsibility. This enables your code to be flexible, extensible and less prone to bugs since software components that are only loosely coupled to their peer components are simpler and easier to maintain.

As I’ve grown as a developer, I often find myself using a set of useful commands, tips and tricks both within Rails applications and more broadly. If you find yourself regularly coming across a pretty generic problem or pattern when coding, the development community has probably found a way to address it. I find this especially true in Rails, where there seems to be a slew of methods geared especially toward humans (e.g., Rails text formatters).

In my experience using Rails to build web apps, I’ve come to realize that the framework has a very powerful flow of convention and patterns that you swim against at your own peril. One good example of this that I’ve been using recently is the accepts_nested_attributes_for helper in Rails.

I came across this post today that seems to be making the rounds on the Internet’s great assembly places: Twitter and Hacker News. As someone who graduated from one of the developer bootcamps that the writer talks about, I felt compelled to chime in and offer my two cents. I’m not writing this as an explicit statement in opposition to or in support of bootcamps, but rather hope it will contribute to the necessary and vital discussion about their value to students, companies and society as a whole. And just so there’s no confusion, “Dev Bootcamp” in the title refers to the generic term, not the dev bootcamp actually called Dev Bootcamp (of which I have no specific opinion).

Lately, I’ve been interested in branching beyond the traditional Rails web stack. Node has always seemed interesting to me - not only is it fast and built for concurrency, the notion of using Javascript to structure the back-end seems like a natural next step to me given the language’s ubiquity in web browsers (check out this great Stack Overflow post on why you might want to consider Node). Last Friday was the second 100% day at the NYT since I started back in July, so I figured that it would be a good opportunity to explore the Node stack and get myself out of always approaching the web from a Ruby/Rails perspective.