Sam Stephenson, understated and excellent

I’ve enjoyed Sam Stephenson’s work for a long time. Even before “sheesh”, the most polite dismantling of an over-privileged open source user, Sam’s work has been top notch. Prototype is the library that made JavaScript palatable and learnable for me. pow and rbenv, in concert with ruby-build, are a lovely simplification of the weird problem of maintaining Ruby development environments.

The thing that pulls it all together, I think, is how well suited his solutions to diverse problems are. There aren’t a bunch of moving parts. Prototype was very much a library, and not a framework. His code is very much of the tool, playing well in the environment, be it Ruby, CoffeeScript, or even shell scripts. rbenv, ruby-build, and pow all play to the strength of bash and Node rather than trying to extend them to become something they’re not.

I was tempted to say his work is minimalistic. On second thought, I think it’s understated. Look at his website or photostream. The quality of just enough, but not too much, isn’t luck. It’s Sam Stephenson’s calling card. I love it.

How to succeed at Rails by trying

I think most teams, probably 90% of them, should start and stick with Rails conventions. Intelligently apply design principles, watch out for coupling that’s not worthwhile, carefully add dependencies when you must, sure. But don’t worry too much about erecting a wall between your app and Rails, building microservices, or whatever fashion dictates when you run rails new.

That said, I don’t think strict adherence to Rails’ opinions is the only way to succeed when using Ruby to build for the web. You can adopt the principles of Rails’ opinions, e.g. use code over configuration to fight boilerplate or reduce the number of choices developers need to make by curating some libraries. You could document those principles and invest in new teammates by mentoring them up on your framework and tools.

Actually, you should do that anyway! But there are reasons you may not be able to do that: the team is too junior, time is tight, you need to explore new technical ground in other areas of the project. If that sounds like your team, you will benefit a lot from letting Rails do much of the tool-building, principle-seeking, and training for you.

The wolf moves fast…

The Wolf:

The Wolf moves fast because he or she is able to avoid the encumbering necessities of a group of people building at scale. This avoidance of most things process related combined with exceptional engineering ability allows them to move at speed which makes them unusually productive. It’s this productivity that the rest of the team can… smell. It’s this scent of pure productivity that allows them to further skirt documentation, meetings, and annual reviews.

See also, The Grinder.

Well-tuned judgement

Lessons From A Lifetime Of Being A Programmer:

Never stop learning, the technology steamroller is right behind you waiting for you to stop.

I’ve taken this one seriously in the past, almost aways tinkering with languages, databases, frameworks, etc. I think it’s served me up to a point, expanding my mind and learning different ways to do to things.

The problem is I’ve reached the point of diminishing returns. I could go learn a stack-based language like Factor, or bend my brain around a oddly shaped database like Datomic. I’m not sure it would make me much better as a developer and leader of software teams.

Instead, the steamroller I think I need to keep ahead of is practice. Given a problem, what are three different solutions? What are their tradeoffs? Which approaches seem nice on paper, or in a blog post, but don’t work out a few hours down the road?

To wit:

This isn’t obvious to everyone, but the ability to see something new, or see what others are doing, or to compare multiple ways of doing something and then pick the best option for you, your team, your project or even your company is incredibly valuable. Most people I’ve seen are not very good at this. Most leaders are really terrible at this. It’s easy to just do what someone tells you you should do or something you read in a blog or just do what everyone else is doing. It’s much more difficult to look at things from all sides and your needs and pick something that seems to be best at that point. Of course you have to make some decision, people are often paralyzed by having to evaluate which often leads to picking something random or following the herd.

Well-tuned judgement is where I’m hoping to go next. Part of that is experience, knowing the forces and tradeoffs that apply to the possible solutions. Part of that is the ability to communicate it with teammates, sometimes face-to-face and sometimes asychronously. The really challenging part is letting your teammates run with the result of that judgement and collaboration.

A good developer makes good decisions for their own implementation; a great developer helps the whole team implement good decisions.

Conservation of complexity

You can’t fight the Law of conservation of complexity:

The law of conservation of complexity in human–computer interaction states that every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.

Turns out one of my criticisms of microservices and microlibraries is a law. A LAW PEOPLE, YOUR ARGUMENT IS INVALID. Hilarious narcissism aside, keep an eye out for practices whose tradeoffs don't fit inside the depth of reasoning a blog post (like this one!) afford. Turning monoliths into services begets operational challenges. Microlibraries beget choices and wiring things up. Maybe the former is your thing, maybe it's the latter. Tradeoffs happen!

Executables deciphered

What's inside a compiled Hello, World program? Julia Evans is on that. How to read an executable:

Executable file formats are regular file formats that you can understand. I’ll explain some simple tools to start! We’ll working on Linux, with ELF binaries. (binaries are kind of the definition of platform-specific, so this is all platform-specific.)

I thought I had a rough grasp of how executables worked, and I still learned things. I love this format too. Julia Evans writes these fearless, curious posts about the deeply mysterious underpinnings of our computers and I learn a lot every time. More like this, please!

Microservices for grumpy old men and women

Microservices? I’m not entirely sure what they are. The term seems to exist on all parts of the hype cycle simultaneously. It’s on the ascent of excitement, the descent of disillusionment, and the plateau of productivity for different people, simultaneously. Some folks know exactly what it means, others know entirely nothing about what it means. Weirdness ensues. People talk past each other.

It’s a mess. Grumpy old man mode is in full force. (FWIW, I am the grumpy old man in this metaphor. I can not speak to the stature of Fowler or Feathers at this time.)

If I’m pessimistic, I nod along with Michael Feathers. He’s on to something when he observes the use of microservices as a blunt weapon against failures of encapsulation. Microservices become SOLID principles using units of deployment and even teams as a barrier between concerns. I feel that’s rather draconian.

If I’m optimistic, I cite Martin Fowler. To his credit, Fowler is doing the best work sifting through the noise and sensibly organizing what microservices might, in fact, be about. They’re probably not distributed objects, if you do it right. But you should understand the details, lest you get swallowed by the novelty and forget to realize the benefits. Make sure you’re tall enough for the ride your operations team is about to endure.

I get the feeling that radical approaches to working with Rails and microservices are tilting at the same windmill. You won’t fix the human tendency to build complicated structures with more software. Employing more buckets, or smaller buckets, in which to put your software doesn’t solve it either. You need a human factor to jump in and say “Hey, this is complicated! It might even be essentially complex. Let’s manage that complexity.” If you’re actively managing complexity, microservices or monoliths, Rails way or your own way, microservices and decoupling are a lot more of a detail than a foundational principle.

When Developers Design

I see lots of “should designers code?” articles and introductions to coding for designers. I see far less interest in the converse. So what’s a designer think? Cap Watkins, a designer; Should Engineers Design?:

If you think design is 100% about creating “design artifacts”, I’d say your scope is too narrow and has the potential to stunt your personal and professional growth.

There’s so much to designing that isn’t about choosing colors, fonts, producing icons, or drawing. Developers can, and should, get involved in how the applications works, how copy guides the user through workflows, when to prompt about invalid data and when to fix it automatically, and how to help users through interactions. That’s design!

To wit:

Throughout my entire career I’ve had engineering partners deep in the design process with me. I show them sketches, bounce ideas off of them, have whiteboarding sessions to figure out what we’re going to do. I trust engineers I work with to let me know when something seems confusing, when there’s an edge case I haven’t thought of and to push on my ideas to find where they break and help me make them even better.

Developers often don’t even realize they’re designing when they’re building libraries and tools for other developers. Writing a good README so developers know why your project is awesome and how to use it? That’s design. Sweating the details of an OO or REST API? That’s design. Opting to remove a feature or solve two problems with one feature? That’s design!

The design was in us the whole time, and we didn’t even know it!

I leave you with this excellent wisdom:

When you look at design as a process and not an artifact, everyone on your team becomes a designer. We have different areas of expertise and skill, no doubt, but the product experience belongs to every member of the team. The more familiar you are with each other’s responsibilities, the more you’re able to participate with and help each other out when needed.

Here’s a fun thing I do that you should try: when you read articles about design, squint a little bit and pretend it’s about designing programs. You might find something you want to try the next time you sit down to work on some code.

How Rails fits into the front-end

Is Rails well positioned for where the web (on all devices) is going? Pal Dave Copeland asked that on Twitter. Turns out I had plenty of opinions!

  • I buy into the notion that the majority of applications don’t need much special in the way of browser-side functionality. SJR, a little bit of CoffeeScript, and SCSS will do you fine.
  • For the rare team building ambitious applications, an opinionated framework like Rails is probably the last thing you want. Ambitious applications, perhaps by definition, are going to cut against the grain in one or more places. An opinionated framework is only going to get in the way of the opinions that make the application ambitious in the first place.
  • The web is in a weird place. I think it’s a somewhat risky environment to build for browsers right now. The combinatorial explosion of devices and browsers means that you’re almost certainly giving some non-trivial class of user a suboptimal or buggy experience. Choosing where to spend your effort seems like a non-fun process.
  • There isn’t a high-quality, well supported, well conceived ecosystem that currently exists for browsers. Rails and iOS both succeeded with a combination of smart conception, (mostly) excellent execution, and supportive communities or vendors. Front-end technologies are deeply splintered right now.
  • I suspect there’s no opportunity for Rails to crown a winner in this space until the Cambrian explosion of JavaScript and CSS practice coalesce into something coherent that most developers can relate to and execute.
  • But, if I had to wager, my money is on Rails choosing Ember as a default choice. This would happen on the trailing edge of fashion though, in the same way that jQuery didn’t become the default for Rails until long after jQuery became the go-to choice for most front-end developers.
  • Even if the Rails core team could pick a winner on the leading edge of fashion, I don’t think it would work out. The Rails core team has much less experience with the front-end than the back-end. Historically, the choices have been OK (CoffeeScript turned out well, Prototype+Scriptaculous was an excellent early choice) with a recent trend towards provoking wild disagreement (e.g. CoffeeScript and Turbolinks).
  • I think a lot of this comes down to Sprockets’ ability to gracefully grow to support front-end practice. It already does a pretty good job. Adding better support for browser components (e.g. Bower) would be good, as well as keeping up with SVG, web fonts and other somewhat special asset types.

If, tomorrow, I did have to build a Rails app whose web experience was crucial, I’d be as conservative as possible with my library choices. I’d stick with the oldest, boring-est, best-tested JS and CSS tools until it wasn’t feasible anymore.

A Ruby hash, Luxury Touring Edition

map.rb, quality software by Ara T. Howard:

the awesome ruby container you’ve always wanted: a string/symbol indifferent ordered hash that works in all rubies

m = Map.new

m[:a] = 0
m[:b] = 1
m[:c] = 2

p m.keys #=> ['a','b','c'] ### always ordered!
p m.values #=> [0,1,2] ### always ordered!

m = Map(:foo => {:bar => 42})
s = m.struct # maps can give back clever little struct objects
p s.foo.bar #=> 42

I like little tactical improvements to the Ruby standard library that give it a slightly more modern feel.