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!

Sportsball deciphered

It’s September and football season is upon us. Thus, I will soon annoy the snot out of people who say “sportsball” and generally ignore sports. Some will be able to mute me on Twitter and avoid most of the annoyance. Others, however, work with me on teams and will have to put up with the times when I slip and work a football metaphor in to the process of software development.

What follows is a glossary of things I may say that are football and/or sports related and a simple explanation of what they are. I’ve omitted what the term means in football so you don’t have to learn any sportsball if you don’t want to!

Move the goalposts is when you change the rules so it’s easier for you to achieve your goal. It’s like how Captain Kirk solves the Kobayashi Maru test. (Ed. David Romerstein pointed out that moving the goal posts often means someone constantly changing the parameters of success such that it’s impossible to succeed. Beware!)

A lead blocker is someone who precedes a person trying to get something done and removes impediments to their goal.

If you start doing something before the official start time, or you start doing it and then have to stop and start over almost immediately, it’s a false start.

If you fully succeed in the task at hand, you have scored a touchdown.

A penalty flag, or just flag, is thrown when you break the rules.

If you force so many mistakes on your adversary that they run out of room to retreat, you have scored a safety.

If you’re doing really well, and you don’t mind giving up a few small victories to get closer to winning the overall game, you are running a prevent defense.

You might attempt to run out the clock if you’re winning and want to use a strategically conservative plan until the game is over and won.

A blitz is an aggressive plan to overwhelm by speed and force. Just like the blitzkrieg, but with less actual war.

The draw is about the simplest tactic you can apply on offense. You rely on one person to get the job done and everyone else supports them.

A read option is one of the most complicated offensive tactics where you prepare multiple different strategies and the leader choses which one to execute at the last possible moment depending on what they see in the situation they face.

More definitions coming soon! Leave a comment if there’s a sportsball term you’ve always wondered about and want a no-nonsense answer.

Make systems from goals

Use systems to get where you’re going, not goals:

My problem with goals is that they are limiting. Granted, if you focus on one particular goal, your odds of achieving it are better than if you have no goal. But you also miss out on opportunities that might have been far better than your goal. Systems, however, simply move you from a game with low odds to a game with better odds. With a system you are less likely to miss one opportunity because you were too focused on another. With a system, you are always scanning for any opportunity.

Applies to personal life, biz, programming, hobby, whatever. Use goals to figure out what systems you need in place, then get habits and systems going to make those goals, or something better, happen.

Yet another way you can use your skills as a developer to construct a system that really solves the problem, and not a symptom of the problem!

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.

Jerry Jones: slightly human, mostly Faustian

The best thing you will read about Jerry Jones this year. Slightly humanizing, even. What Jerry Jones wants, he cannot have:

I’ve never wanted anything as much as I want to win the next Super Bowl.

The owner of the Dallas Cowboys is his own worst enemy. His general manager, Jerry Jones, is able to make decisions good enough to prevent the team from sinking too far. He is not, however, able to make the decisions needed to return the team to legitimate contender status.

If you somehow made it this far without knowing much about football, let me clarify. Jerry Jones is Jerry Jones. Owner and general manager. Everyone who has watched football for more than a few years knows that Jones’ ego is what prevents him from separating the wildly successful owner Jones from the wildly sub-par manager Jones. And yet: it never happens.

That said, it does sound like somewhat Faustian fun to hang out with Jones, as the ESPN reporter who wrote this piece did. On the one hand, it’s obvious that a billionaire is using his considerable resources to come off as a reasonable, alright dude. On the other hand, he stands on the side of not renaming the Washington football team, so you know that Jones is subtly awful in ways he can’t even begin to wrap his brain around.

Thought + Quality

Oliver Reichenstein, Putting Thought Into Things:

Quality — as in “fitness for purpose” — lives in the structure of a product. A lack of quality is a lack of structure, and a lack of structure is, ultimately, a lack of thought. One does not find a solid structure by following some simple method. We deepen the structure by deepening our thought on the product. Our role as designers is to put thought into things.

I’ve noticed I do the worst, as a developer, when I’m using tools and methodology to avoid thinking. Not entirely sure how to solve this problem, write some tests and commit whatever makes them green. Troubleshoot by tinkering with commenting code out, trying different incantations, pasting snippets found on the internet.

Each advance in how I build software is lead by finding some way I defer or avoid thinking and correcting that shortcoming. In doing so, I find myself a little more opinionated, a little more specific about what really matters in making software and what is dressing.

Put more thought into what I build. Always think about what constitutes The Quality for the kind of software I want to build. Seek to avoid the tech vogue in search of deeper quality and thought. I’m far from mastering any of these disciplines, but the results so far are promising.

Get thee to thy hammock!

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.