Sometimes

  1. Sometimes you go on a writing slump. Usually, just throwing something at the wall is how you undo that.
  2. Sometimes you notice that a lot of your writing can end up in platitudes and that deepens your slump. We regret the error, those responsible have been sacked.
  3. Sometimes you get kinda caught up in learning, tinkering, and enjoying things and forget to write. That's ok!

18 months is a smelly interval

18 months is a dangerous window, when it comes to building a product. It’s far enough in the future that it seems like you could deliver an ambitious idea within a year and a half. But it’s a long enough timeline that one is tempted to skip the necessary contemplation, dividing-and-conquering, and hypothetical thinking that the planning process forces on you.

As it happens, 18 months is 540 days. 540 degrees is one and a half revolutions. As in, you started a revolution, but ended up regressing.

Saddest trombone. Be wary of anything that promises to happen in 18 months. It’s the “epic handwaving” of project management.


Dining at the source code buffet

Let me start with a quote from wonderful person James Edward Gray II:

One of my favorite techniques for really learning a new language is to read the core API like a good novel. I’m a hit at parties!

I’ve had great success with this approach as well. I probably read the majority of Rails, the source of every RubyGem I used, and chunks of Ruby’s standard library in my first few years of working with Ruby. I picked up new tricks, figured out how things worked, and got myself out of a lot of tricky corners by reading code.

That we can do this is, to me, the real wonder of working with an open source stack. If I’m curious, I can dig into the framework, language, database, compiler, and operating system I’m using. If something goes weird, I can dig into it. I probably won’t end up changing or fixing anything below my app in the stack, but the ability to peel back the layers is a huge deal.

Given the choice of digging into why software sometimes goes weird and complaining or giving up, always chose digging into the source to see what’s going on.

When you work with open source software, you can always chose to figure out what’s going on around your app. Eating at the source code buffet is awesome!


Megaprojects: megacool

Megaproject. It’s a cool word. It’s an even cooler list-of-pages on Wikipedia. I’ve only worked on projects limited to tens or dozens of people. The human and geographical scale of some of these endeavors just blows my mind. The coordination and planning required for something like the Boeing 747 or Apollo program is beyond my comprehension. (OK, maybe I’m still really into aerospace; I did go to Space Camp. Twice.)

I would love to be a fly on the wall of the meeting where it’s decided to go ahead with a project that will be visible from quite some height above the earth like Denver International Airport or Walt Disney World. That’s a pretty huge commitment. I waffle for weeks when I decide I’m going to buy a new car!

If those don’t whet your appetite, perhaps speculative megastructures are more your speed? Trans-global highways! And of course, Dyson spheres, ringworlds, et cetera.

It’s good to remind myself that occasionally, human kind is capable of building really great stuff.


Is SNL trending up?

Has SNL been getting worse? Viewer ratings say, nope. If anything, it’s becoming more consistent and slightly better. Previously: how to understand SNL. Always: nostalgia bias.

(BTW, know how yes/no question headlines are always answered no? But this one is yes? LOL.)


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.


Vacation, disposable, and calm computing

1

Let me talk about vacation computing. The prime directive of vacation computing is that you should compute on vacation as little as possible. Neglect your email, abandon your social mediums. Don’t do the things you normally do, regardless of how computery your regular work is.

From there, it follows that your vacation computer should basically not be a computer. That means smartphones, tablets, and book readers are the only options. But smartphones are pretty much synonymous with social media, so they aren’t really viable as a vacation computer (though you probably want it anyway because they’re a superpower). Tablets are nearly computers now, so that’s not viable either.

It follows that a book reader is the only acceptable vacation computer.

2

Let me talk about disposable computing now. We put a lot of important stuff on our computers these days. Important passwords, legal documents, email, family pictures, private pictures, computer games, purchased and bespoke music, Hollywood and home video, etc. Sometimes those computers are in our pockets, sometimes they’re on our laps and coffee tables, and occasionally you might still find them on our desks!

For the drama and heartbreak that can occur when we lose these computers, we take astoundingly bad care of them. We don’t back them up, we reuse passwords. A moment without wireless networking is the worst and yet we don’t take steps to prevent even more dramatic losses due to password breaches and storage failure.

Given all of this, a computer is made better by making it a disposable object. Backup your data, and backup your backups. Practice good password habits as much as possible so your accounts are isolated and somewhat disposable. Know your gameplan and what happens to your stuff if your computer or backups fall into a lava pit.

3

Knowing about vacation and disposable computing, I’m led to an odd and dissonant conclusion: an e-ink Kindle is the perfect computer. It does not do work, it does not social media. You can take it through airport security without any extra steps, which feels a little perverse and seems a bit surreal. It does not interrupt, it does not beep or blorp, it just barely displays text. As modern computers go, it’s basically useless.

But. You can read on it. And reading is so wonderful. And you can put stress aside. A Kindle gets wet? Not a big deal. Drop a Kindle? Not a big deal. Try to use it by the pool, out in nature, out in weather, out where the internet does not go? Not a big deal. Lose your Kindle? Buy another one, it costs a fraction of all your other computers.

The one scenario where you will find yourself absolutely screwed with a Kindle is when you have to enter text. Logging into Amazon or a wireless network for the first time? That’s a bad time.

In every other respect, the Kindle is a computer that does nothing to increase your stress level. That’s pretty remarkable today. Let’s make more calm computing devices, ok?


Apple, Disney, and obsession

People in technology disproportionately like to comment on Apple’s products and business. Outside of technology, there are just as many folks who love to obsess over Disney’s theme parks. Based on my friend networks, I’d wager that for every person who obsesses over Apple’s keynotes, there’s a Disney enthusiast keeping up on special events and the best way to enjoy the theme parks.

The connection that strikes me is that both of these companies pay more attention to details than their competitors. Apple’s competitors throw software and hardware at the wall like spaghetti, hoping it will stick. Disney’s competitors rename their rides to match the blockbusters of summer. By comparison, Apple makes a big deal about the fit and finish of their hardware (let’s not talk about that camera though!) and has a coherent story about how all their products fit together into a useful landscape. Disney carefully arranges their parks to keep the guests in a cohesive movie world and pays attention to the little details that enhance or optimize the experience.

I could make some value judgement here about how attention to detail is more profitable, better design, better engineering, or whatever. I suspect all of those are true, but it’s not what excites me about Apple or Disney. When I read about changes to Disney’s theme parks or Apple’s keynotes, I’m excited that there are companies, quite large and successful ones, that are connecting lot of dots in an intriguing way. They’re extracting delight from large scale complexity. Megaprojects are nifty and often enhance humanity, but they’re mostly out of touch or sight. It’s nice that some of us can experience and enjoy these commercial projects of vast scale and quality execution.


Multiplication over management

When a developer becomes a manager, It’s not a promotion, it’s a career change:

If you want to do your leadership job effectively, you will be exercising a vastly different set of skills on a daily basis to what you are exercising as an engineer. Skills you likely haven't developed and are unaware of.

Your job is not to be an engineer. Your job is not to be a manager. Your job is to be a multiplier.

Don’t miss the section on how we undervalue non-technical skills. It’s not unlike developing software, it’s just that your levers are people and processes instead of software and data centers. See also, Managing Humans.


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.


How waterparks became a thing

The Men Who Built the Great American Waterpark, a roaring tale about the fellows who created the notion of a park for water attractions, from Wet and Wild to my personal favorite place on earth, Schlitterbahn. Told as is typical of the slightly nerdy, slightly narrative Grantland form.


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.


Vegas, America/Starbuck's playground

I’m going to Vegas this weekend with my wife on a real vacation where we’re going to do as little as possible. Not run around Disney World all day, not drive up and down the southern California coast. Based on this little bit of research, I can’t wait.

Three Starbucks facing each other

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.