Throughout the year 2017 I found myself working in a half dozen spots across 3 continents and many more timezones. This experience led me to develop an increasingly lucid conviction about the profound benefits that remote workforces can bring to a business and have a workplace betterment also with new technologies to improve the workflow.

I recently read a wonderful profile of a young Larry Ellison by serial entrepreneur and teacher Steve Blank. One passage leapt out at me for its relevance to many recent experiences of my own:

Larry ascribed to the adage, “We don’t do things right, we do the right things.”

I was reminded of another aphorism I’d once heard – a bicycling metaphor:

It’s not how fast you pedal, it’s what gear you’re in.

One of the tremendous benefits of building with a high-level framework like Ruby on Rails is that you are afforded both mental space and an abundance of tools to optimize your application with a thoughtful caching strategy. Caching can be done at several levels in the stack and I wanted to provide an overview of the most common caching strategies for Rails applications and the tradeoffs inherent in each.

In our work as software developers we regularly have to evaluate architectural tradeoffs. We have voices, either external or internal, telling us to think about, for example:

• Going API first
• Building to accommodate horizontal scaling
• Building with the most modern tools
• Building with tools and frameworks that let us hire the best (or sometimes “Building with tools and frameworks that let us hire the cheapest”)

There is often a tension in these matters between practical and “correct”. It may be most correct, for example, to build up your styling and javascript components from scratch, such that you only introduce precisely the code you need to realize desired functionality. There may be something intuitively less correct about bringing in styles and components that you never actually end up utilizing, such as happens in some degree when you build atop, for example, a UI framework like Bootstrap.

Marshall McLuhan once said “Our Age of Anxiety is, in great part, the result of trying to do today’s jobs with yesterday’s tools”. There’s not a lot of technology that we interact with on a day-to-day basis that’s stayed in continuous operation for 230 years. The faculties by which we interact, gather, and exchange ideas in social and professional realms have dramatically evolved in this span of time. Our systems of government, at both philosophical and practical levels, largely have not.

I noticed something curious when I booted my first project atop Rails 5 in development mode: that when the development server was idling, the title bar on Terminal.app would read “fsevent_watch”.

On further investigation I found this pull request and this posting to the official Rails blog. With this pull request, Rails got a new event-based filesystem monitor. Whereas previously, both class reloading and asset recompilation were governed by a walk of the project tree reading the mtime off of files, with Rails 5 we finally have a more enlightened, push-like model based upon file system events.

One of the things I am most proud of, and that I am most surprised to find distinguishes me when I look around at other people in my professional circles, is how often I finish things. To me, finishing is credibility, and a person’s record not just of starting or working on projects, but of finishing them, should be a factor in the weight you give to their opinions or the degree of leadership you entrust them with.

There is a trope that is ubiquitous in our community. New tools or frameworks hit the scene, people are enamored of the new tools, they convince their organizations to tear down some stable and mature but “crufty” application and rewrite it with the hot new thing, rather than look for simple, pragmatic, high-leverage/high-ROI optimizations in the existing app.

A good friend sent me Jason Kester’s article Happiness is a Boring Stack a few weeks ago. The friend knows me well and knew the words of the piece would resonate strongly. The piece is worth a read. Its essential point is that while Hacker News, Medium, or certain of your colleagues may give you the impression that you have woefully mis-stepped if you aren’t building your application atop the latest and greatest JavaScript framework and containerization solution, from a perspective of pragmatism and quality of life this is often not at all the case:

I recently read Chad Fowler’s The Passionate Programmer, a book broadly concerned with finding fulfillment through work in software development. The book had an unexpectedly strong impact on me. Many of Fowler’s key points aligned uncannily with recent experiences and observations of my own. One section that leapt out in particular to me concerned practice.

I did never know so full a voice issue from so empty a heart. But the saying is true: “The empty vessel makes the greatest sound.”

A decade living in New York has conditioned me to have an instinctive skepticism of the loudest voice in the room. The loud people, the pushy people, the bullies, those who take up the most space, whether in the workplace or hooting on the sidewalks at night on the weekend – these are almost always also the people of least consequence, but its a fact that is tragically lost on most.