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.

Commercialeering

Things you might hear in commercials/promotions for software and beer:

“The first 96-calorie Pilsner”
“Invented the smooth-pour top”
“Next-generation build system”
“The database that beats the CAP theorem”

American software and beer, much innovation, many hands waving. Solutioneering!

Sportsball Deciphered (II)

It’s Thursday. Sadly enough, this year, that means there’s football on. We’re far from peak football, but it’s getting closer. Prepare yourself, and tell your kids of the days when Sunday was a special day because no other day had real football. Now, on to more no-nonsense, jargon-free definitions of football jargon.


A Hail Mary is the most desperate offensive play. If you’re doing poorly, the end is near, and you need a miracle, your Hail Mary effort is the low-odds, high reward manuever to save the day.

You start executing your plan with the snap.

If someone inappropriately prevents someone else from doing their job, you could say they have committed pass interference.

If you’re not making progress forwards or backwards in your plan, and are instead moving laterally, you may have gone sideways.

If you want to commend a teammate for doing well, and you’re comfortable around them, you might give them an ass slap, but be careful; everyone watching will notice it and wonder things.

Coaching in the NFL is now sufficiently complicated that coaches often have a list of plays that resembles a laminated take-out menu in-hand at all times on the sideline. This is addition to the radio headset that makes them look like they’re working the drive-through at your local burger joint.

A strategy that involves taking medium-to-high reward, low probability chances all the time is not too dissimilar from always passing the ball. If you were instead going for lower reward but higher probability tactics, you’d be always running the ball.

If you run out of chances and don’t even succeed at a small incremental goal, you’ll have to punt. The other team will get a chance and hopefully you’ll get to try again, but your tactical progress will probably be reset.

A strategy that emphasizes protecting against big losses over smaller losses is not unlike a nickel defense.

If you fail to protect the leader, you have given up a sack.


For more, revisit Part I.

Put. The phone. Down.

Nick Quaranto has Too many streams:

There’s just too many things to pay attention to. I get questioned pretty frequently about this: how do you pay attention to nearly 1,500 people on your Twitter timeline? Here’s an easy answer:

I don’t.

Nick’s conclusion, in short, is to put the phone down. There will always be too many things seeking your attention. You can never Read the Whole Internet. You can only hope to mark it as unread and go on with your life. Hence, just put the phone down.

I came across this little trick where you get all the stuff you tinker with off your phone’s home screen. All functional apps, no social networks, no web, no mail, nothing that’s going to grab your attention. Software calmness, per se. I’ve done it for a week and love it so far. I highly recommend it, if you have the means.

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!