2014 Year in Review

Year-in-review posts are a particular kind of exercise. They force you to be honest about what actually happened versus what you planned, and they create a record that your future self can learn from—assuming you write down the real numbers and not the flattering version. This one covers 2014: a year of Ruby engineering work, side projects that shipped, side projects that did not, writing about software as both craft and business, and the practical realities of maintaining a technical publication alongside client work. For context on how Ruby and Rails engineering has evolved since then, the topics section covers the current state of deployment, internals, performance and debugging.

The engineering work

The core of 2014 was Rails consulting. Multiple client projects, mostly in the upgrade-and-stabilise category: applications that had been built quickly, shipped successfully and then accumulated enough technical debt that changes had become risky. The pattern was consistent across projects:

• An application running on an older Rails version (usually 3.2 or 4.0)
• A test suite that covered some features well and others not at all
• A deployment process that depended on one person's knowledge
• A growing backlog of features that nobody wanted to touch because the risk of breaking something was too high

The work itself was satisfying in the way that maintenance work often is: you take something fragile and make it robust. You add tests where there are none. You upgrade dependencies carefully. You replace the deployment process with something repeatable. And at the end, the team can make changes without holding their breath.

What I underestimated was how long the dependency upgrade phase takes on a real production application. Upgrading Rails from 3.2 to 4.1 on an application with 80 gems is not a weekend project. It is a multi-week project with careful testing at each step, and the testing itself reveals bugs that have been hiding behind the old behavior.

The writing

2014 was the year I got serious about writing about software as a regular practice rather than an occasional impulse. The output was uneven—some months produced several pieces, others produced nothing—but the total volume was higher than any previous year.

What worked: writing about problems I had just solved. The deployment friction points, the Rails internals discoveries, the debugging techniques that saved hours on client work. Writing immediately after solving a problem captures the specificity that makes technical writing useful. A week later, you have already forgotten which error message led you to the solution.

What did not work: attempting to write comprehensive tutorials without a recent, concrete experience to anchor them. Those pieces felt generic even to me, and they performed accordingly. Nobody needs another "Getting Started with Rails" post. People need "Here is the specific thing that broke when I tried to do X, and here is why."

The business model for technical writing in 2014 was essentially: build an audience through useful free content, and then sell something (books, courses, consulting leads) to a fraction of that audience. The audience-building part worked. The monetisation part was inconsistent.

The side projects

Every developer has side projects. The honest accounting of mine in 2014:

Shipped and maintained: A small Rails performance measurement tool that grew out of client work. It tracked request times, memory usage and database query counts across deploys. Not a commercial product—more of an internal tool that I open-sourced because other people had the same problem. Usage was modest but steady.

Shipped and abandoned: Two smaller tools that solved problems I had exactly once. Built them, used them, realised the problem was not common enough to justify maintenance, archived them. The honest conclusion: not every solution needs to be a project.

Started and not finished: A structured courseware system for Ruby learning—topics made of ordered steps, with progress tracking and suggested reading order. The idea was sound. The implementation was ambitious. I built the data model, the step sequencing logic and the basic UI, but never got the content to a level where it felt ready to share. The courseware concept kept evolving in my head faster than I could implement it, which is a reliable sign that the scope needs trimming.

The numbers

Honest numbers, not vanity metrics:

Revenue from consulting: Enough to cover living expenses and some savings. Consulting rates for senior Rails work were healthy in 2014, and the demand was steady. The constraint was not finding work—it was finding blocks of time between projects to do everything else.

Revenue from writing and products: Small. Enough to notice, not enough to depend on. The gap between "people read your stuff" and "people pay for your stuff" is wide, and crossing it requires either a compelling product or a lot of patience. I had patience. The compelling product was still being designed.

Website traffic: Growth was real but modest. Technical content has a long tail—posts from six months ago still brought in consistent traffic from search. New posts spiked on publication day and then settled into a steady baseline. The posts that performed best over time were the ones that addressed specific, searchable problems rather than the ones with clever titles.

Email subscribers: A few hundred. Engaged, technical, largely senior developers. Small list, high quality. The open rates and click rates were well above the benchmarks for tech newsletters, which reinforced the lesson that a small, engaged audience is worth more than a large, passive one.

The lessons

Lesson 1: Maintenance work is undervalued and undersold. Clients pay for new features willingly. They pay for maintenance reluctantly, even when maintenance is what their application actually needs. Learning to explain the business value of maintenance—reduced risk, faster future development, fewer production incidents—was as important as learning to do the work itself.

Lesson 2: Write about what you just did. The best technical content comes from recent experience, while the details are still sharp. Scheduled content creation without a recent problem to write about produces generic content.

Lesson 3: Scope side projects ruthlessly. Every side project I finished had a narrow scope. Every side project I abandoned had an expansive scope that kept growing. The courseware project was the clearest example: great idea, too much surface area, not enough willingness to ship a minimal version.

Lesson 4: The audience is the asset. Revenue from writing was small, but the audience it built led directly to consulting opportunities. The relationship between content and revenue was indirect but real. People read the posts, trusted the expertise, and then hired for the consulting work.

Lesson 5: Keep honest records. It is easy to remember 2014 as either better or worse than it actually was. Writing down the real numbers—revenue, traffic, output, completion rates—creates a reference point that future plans can be measured against.

What carried forward

The courseware concept—topics made of ordered steps—stayed in the back of my mind long after 2014. The structured approach to teaching deployment, internals and debugging that runs through this site today has roots in that unfinished project. Sometimes the right idea needs a few years of additional experience before the execution catches up to the ambition.

The consulting pattern—taking fragile Rails applications and making them robust—also proved durable. It turned out that there is a permanent demand for developers who can take an existing codebase, understand its problems quickly and improve it incrementally without breaking what already works. That skill set has only become more valuable as the average age of Rails applications increases.

Related reading

• Debugging and Maintenance — the topic that grew from this kind of work
• Make an Old Rails App Safer to Change — the structured approach to inherited codebases
• Posts — all editorial content