I spent a good part of last year living in Berlin, encountering large, Cold War era constructions on my morning walk. This style of architecture, distinguished by exposed concrete cast in hard lines, with little paint or ornamentation, is part of an architectural school known as Brutalism, and was very popular through the mid 20th century, especially in Eastern Europe.

The term has since been transposed to the online realm with brutalistwebsites.com, a site put together in 2016 by Pascal Deville (now Creative Director at the Freundliche Grüsse). I wanted to pay tribute to the tongue in cheek term by recognizing some of my own favorite Brutalist websites.

In 2009 I got my first Mac laptop. I had been running Mandriva Linux on a beat up HP Pavillion through the first two years of my computer science program, and the week it finally died on me a Gizmodo “Dealzmodo” post advertised a liquidation of last-generation 15 inch Macbook Pros by a reseller. I got my Mac and promptly discovered the unprecedented ecosystem of fantastic, passionately-crafted desktop software built for the platform by small, independent software houses. In retrospect I’ve come to believe that the period from around 2005 to perhaps 2010 was truly the golden era of desktop Mac applications.

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: