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!


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!


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!


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.


Team superpowers: invest early, reap often

Startup Engineering Team Super Powers. You want all of these. Well-considered investments in tooling and conventions can pay out handsomely, and daily, if you put it in place sooner than later.


Database rivalry in the Valley

A couple years ago, Google released an embeddedable key-value database called LevelDB. There was much rejoicing. Recently, Facebook released their fork of LevelDB, RocksDB. There’s a slide deck comparing the two, but the amusing part is the “our way is better!” subtext. A little bit of Valley rivalry there. You can also learn a lot of interesting tidbits about the design of modern, high-performance database systems from the Architecture Guide and Table Format documentation of RocksDB.

Say what you will about tiny, highly-targeted ads. To some extent they are subsidizing a lot of interesting technology development and the open sourcing thereof.


Object-oriented relativism

When a Method Can Do Nothing, Michael Feathers:

If polymorphism means anything at all, it means that the object is in charge. We send it a message and it is up to it to decide what to do. That's core to OO and part of Alan Kay's original view of objects - that they are all about messaging. That said, it is not the dominant view today.
The majority of this article is on working with/around conditionals using intention-revealing method names or null objects. Yet, this paragraph smacked me in the face with "oh, yeah, obviously!". Lots of people view the moving parts in object-oriented languages as ways to group and share functionality. But to people who talk about OO a lot, read the history books, read the pattern books, know what SOLID is, etc. it's an entirely different thing.

Here’s a sports metaphor: the Dallas Cowboys are a widely disliked sports team, for various reasons. If I was from anywhere but Dallas, it would be “not cool” to count myself one a fan. But being from Dallas, I have an entirely different view on the Cowboys and can safely watch their mostly mediocre performances with occasional memories of greatness, safe from scorn.

I find that holding that tension in my head is important when talking to sports fans. It’s the same with OO: you haven’t read the books, watched the presentations, or worked the exercises I have. We’re on different pages, but we need to talk about the same code and how to structure it. There’s a tension between my understanding of OO and the next person, but it’s not a barrier. We have to get our language straight before we can talk about language!

In short, we have to establish what city in OO-land we’re from before we can effectively talk about OO.


Designing technological empowerment

Applied Discovery:

What future are we building, given that we play a role in such an important process?
On the role designers play, what they do as careers progress, and how design can positively enhance the world.

Reminder: if you tilt your head just so, developers do a lot of design activities too.


Currently intriguing me

A channel, a sewer, Alabama, and a sunset walk into a bar:

What’s intriguing you, dear reader?

Peyton Manning, boringly awesome or awesomely boring?

The best thing you’ll read about football today. Peyton Manning is what happens when a guy with the attention to detail of an accountant is also proficient at throwing a football and making snap decisions. Manning also looks like he could give you excellent tips on cutting your hedge or fixing that one toilet.

This is why Peyton is my favorite Manning.


Draw your software

Better Code Design through Pictures:

Looking at a picture like this reveals so much that is missing when only looking at Emacs or Vim. Classes that violate the Single Responsibility Principle may become obvious because they’re related to too many other classes. Cyclical dependencies might be identified. Even class names may be brought into question. These discoveries are not very obvious when writing code, but they were remarkably obvious once we threw the structure up on the whiteboard.
I almost always have some kind of notebook and pen by my side so that I can doodle words and shapes. Having a whiteboard nearby is even better.

Find the classes lurking in your ActiveRecord models

This advice is going on a year old, but it’s still some of the best around. If you’ve got ungainly ActiveRecord objects that are doing way more than abstracting your data model, you are missing classes in the design of your application. Chances are, one of the objects Bryan describes here is what you might want to extract.


Confidence despite evolving systems

Facing risk by instrumenting the hell out of it:

Software development is a complex system existing as it does at the intersection of people, systems, good intentions, confused and changing goals, and overly literal state machines. Past behavior isn’t always an indication of future behavior, and humans are terrible at reasoning about complex systems. As such we’re unlikely to know or have good visibility into whether we’ve reached a steady state and our hypotheses are likely to be wrong. In this uncertain and complex environment we initiate change only when the cost of not making a change overcomes the fear of making it.
First in a series on how Etsy writes, deploys, and operates changing software without The Fear. Thanks for writing this stuff down, Kellan!

Problems as ever-changing mazes

Problems, puzzles, startups as dynamic mazes:

just running to the entrance of (say) the “movies/music/filesharing/P2P” maze or the “photosharing” maze without any sense for the history of the industry, the players in the maze, the casualties of the past, and the technologies that are likely to move walls and change assumptions
I love this idea about thinking of solving systems as though they were an ever-changing maze, with history (fallen players) embedded within the system. Doubly so when you extend the metaphor to solutions that route around one problem to brazenly take on another problem. If this had a further extension to football playcalling, it would be perfect.

Refactor for value over cleanliness

Practice Responsible Refactoring:

When cleaning up the code enables you to work faster for a task you aren’t dreaming up but actually have at hand, refactoring is the way to go.
Dave Copeland makes the point that refactoring without a value-added change (feature, improvement, bug fix, optimization, etc.) is a losing proposition. By the numbers, he's absolutely right. Further, I've found that probably half of the refactorings I'm convinced are necessary aren't as simple or useful as I thought once I get an hour into them. Despite all that, keep doing therapeutic refactorings for practice and to keep your spirits up.

Technology that's not a startup

Here’s a nice story on technology that isn’t startups: Unhappy truckers and other algorithmic problems. Logistic networks are a technology, just like smartphones. They make our world way better, but they do so invisibly and at a slower pace than the churn of mobile apps, web frameworks, and startups. But they’re still solving problems, moving the needle. They’re just, possibly, less obsessed with technology tribalism and fashion. Some days, that seems like a pretty useful space to find oneself in.


Overtime means your business is hurting

Overtime is Morphine, Ernie Miller:

A developer who is truly concerned about the health of his or her company also must be careful to ensure the "patient" isn't developing an unhealthy dependency on their heroics, allowing the company to limp along without experiencing the pain that should accompany unwise choices. Pain is how we learn to avoid repeating mistakes.
I've seen too many developers put in a heroic effort, only to repeat it the next day, sometimes without sleeping in. That's "killing the patient", to extend Ernie's metaphor. It's not the natural state of a business to notice the human cost it might have. The people inside the business have to assess that cost and do something about controlling it.

If your business, or the one you work at, requires regular heroics, consider that it is a broken system. Luckily, software developers are well equipped with mental routines for diagnosing and patching broken systems. Time to hack the organization.