Ruby's roots in AWK

AWK-ward Ruby. One man Unix wrecking squad Ryan Tomayko reflects on aspects of Ruby that arguably grew from AWK more than Perl. Great archaeology, but also a good gateway drug to understanding how awk is a useful tool. Only recently have I started to really grok awk, but it’s super handy for ad-hoc data munging in the shell.

Humankind's genius turned upon itself

When We Tested Nuclear Bombs. An absolutely fantastic collection of photos from the nuclear test program. Beautiful to look at, terrifying to contemplate the ramifications in context. It’s harrowing to think that one of science’s greatest achievements could undo so much of science’s achievement.

Burpess and other intense workouts

What’s the Best Exercise?

But when pressed, he suggested one of the foundations of old-fashioned calisthenics: the burpee, in which you drop to the ground, kick your feet out behind you, pull your feet back in and leap up as high as you can. “It builds muscles. It builds endurance.” He paused. “But it’s hard to imagine most people enjoying” an all-burpees program, “or sticking with it for long.”
I'm having trouble deciding whether I should say good things about burpees. I only do a handful at a time, usually as part of a series of movements. They're not so bad if you start with just a few and work up from there.

Burpees aside, it’s interesting to see opinions on what the most useful exercise movements are. I’m really glad I don’t need to start doing butterflies though.

Post-hoc career advice for twenty-something Adam

No program was ever made better by one developer scoffing at another. Computer science does not move forward with condescending attitudes. Success in software isn’t the result of looking down your nose or wagging your finger at others.

And yet, if you observe from the outside, you’d think that we all live in a wacky world of wonks, one where it’s not the facts, but how violently you repeat your talking points that matters the most. The Javascript guys do this in 2011, the Ruby guys did it in 2005, the .NET people before that in 2002, and on down the line.

Civility isn’t always what gets you noticed, but if you don’t have an outsized ability to focus on technical problems for tens of hours, it sure helps. You’re not the most brilliant developer on the planet, but you like to make people laugh, and you like to hang around those who are smarter than me. That’s not the recipe for a solid career in programming, but it’s a good bridge to get you from the journeyman side of the river over to the side where people think you might know what you’re doing.

Once you reach the other side, its a matter of putting in the hours, doing the practice, learning things, and always challenging yourself. Work with the smartest people you can, push yourself to make something better every day. Grind on that enough and you’ll get to the point where you really know what you’re doing.

Then, you close the loop. You were civil, you didn’t piss too many people off. They are eager to hear about the awesome and exciting things you did. So tell them. Even if you don’t think it’s all that awesome, some will know that you’ve got the awesome in you and that it will come out eventually. Some of them aren’t your mom!

This is what some call a successful career. It’s not so bad, but it’s not exactly the extravagant lifestyle you imagined when you were twenty. On the plus side, you do roughly the same things on a daily basis as you did back then, which isn’t so bad. Being an adult turns out to be pretty alright.

At some point, you write this advice to yourself on your weblog, except in the second person. Hopefully someone younger, perhaps on the precipice of idolizing a brilliant asshole, will read it and take a more civil path. Maybe you’ll get to work with them someday. Let’s hope it’s not too awkward.

Don't complain, make things better

notes on “an empathetic plan”:

Worse is when the the people doing the complaining also make software or web sites or iPhone applications themselves. As visible leaders of the web, I think there are a lot of folks who could do a favor to younger, less experienced people by setting an example of critiquing to raise up rather than critiquing to tear down.

If you’re a well known web or app developer who complains a lot on Twitter about other people’s projects, I am very likely talking about you. You and I both know that there are many reasons why something works a certain way or why something in the backend would affect the way something works on the front-end.

Set agreement to maximum. If you’re complaining on Twitter just to make yourself feel better, keep in mind that some of us are keeping score.

Don’t waste your time griping and bringing other people down. Spend your time making better things.

Perfection isn't sustainable

Perfect vs. interesting:

When an interesting person is momentarily not-interesting, I wait patiently. When a perfect organization, the boring one that's constantly using its policies to dumb things down, is imperfect, I get annoyed. Because perfect has to be perfect all the time.
More and more, I think perfection is the biggest enemy of those who want to ship awesome things. Iteration can lead to moments of perfection, but perfection is not sustainable over time.

Using Conway's Law for the power of good

Michael Feathers isn’t so quick to place negative connotations on Conway’s Law. Perhaps it’s not so much that organizations don’t communicate well, the traditional reading of Conway’s Law. Maybe as organizations grow, people tend to only communicate frequently with a few people and those interactions end up defining the API layers.

I’ve been thinking about this a bit lately. It’s possible there’s something to be said about using Conway’s Law to your advantage when building service-based shearing layers. Some parts of your application should evolve quickly, others require more stability. Some iterate based on user and conversion testing, others iterate as TDD or BDD projects. You can discover these layers by observing team interactions and using Conway’s Law to define where the APIs belong.

Hell is other people's concurrency

The first rule of evented programming is, don’t block the event loop! Mathias Meyer’s great intro to Ruby’s EventMachine library. Non-blocking IO is so hot right now. But remember, it’s just a tool on your concurrency utili-belt. Remember to reach for coroutines, threads, actors, and STMs too.

Bloom, a language with time travel

Bloom, a language for disordered (whut!) distributed programming with powerful consistency analysis and concise, familiar syntax (the prototype is built on Ruby):

Traditional languages like Java and C are based on the von Neumann model, where a program counter steps through individual instructions in order. Distributed systems don’t work like that. Much of the pain in traditional distributed programming comes from this mismatch:  programmers are expected to bridge from an ordered programming model into a disordered reality that executes their code.  Bloom was designed to match–and exploit–the disorderly reality of distributed systems.  Bloom programmers write programs made up of unordered collections of statements, and are given constructs to impose order when needed.
Interested to see how languages will push the assumption that time proceeds from earlier to later as one reads down a source file.

The rules of the yak shave

Yak shaves. They’re great fun. Like most things, yak shaving is more fun when you have some rules to guide you away from the un-fun parts:

  • always have a goal, know when you’re done
  • timebox it
  • work on a branch so you can switch to real work if you need to
  • make smaller commits than usual so you can unwind if you should go awry
  • don’t worry about writing tests if you don’t know what you’re doing
  • if you aren’t sure where you are going, write a test harness and iterate on that
  • have a pair or buddy to talk through what you’re trying to do and how to get there
  • bail out if you are starting to burn out, face diminishing returns, or think of a better way to shave they yak
Fun fact: this post is in fact a yak shave extracted from a post on yak shaving.

Linux screenshot nostalgia

Anyone else remember uploading screenshots of their super awesome, tweaked out Linux hacker desktops?

Screenshot whilst hacking
Sorry, I'm not running WindowMaker, Enlightenment, or Sawmill anymore. Besides that, I think I have all the cliches: terminal, editor, MP3 player, system monitors, blinkenlights, etc. I am missing an IRC session, though.

The next step and the cleared canvas

Knowing the next step is a pretty good feeling. The uncertainty of where you should next place your foot is somewhere between unnerving and terrifying. But if you’ve got an idea of how to proceed, you can learn something. Maybe you’re right, maybe you’re wrong. It’s the step that counts, not so much where you end up.

I just finished reading the RSpec book. It’s a really nicely done book. It does a great job striking a balance between conveying the philosophy of BDD and outside-in development with teaching the tools that Cucumber, RSpec, and Webrat give you when applying that approach to building, delivering, and iterating on software.

What I’m finding most useful about applying those approaches is that I know what the next step is. There’s always a missing piece right in front of me. Sometimes its a big thing, a feature-sized piece. Other times it’s smaller, a pending spec or a refactoring calling out to me. I’m never in the dark, which is important and useful to me.

On a whim, I decided to start doing the “always keep your email inbox empty” thing. I have always been aggressive about making sure everything is read, and I got pretty strict about deleting stuff I’ll never need to look at ever again. But now, I file things away (mostly into a shovebox) once I’m done with some email.

This is a big deal. It’s easy for me to look at my emails and figure out if there is something I’ve let slide. If there isn’t, I can proceed to doing more interesting things. It’s pretty great.

This week, I made a point to “clear the decks” regularly. If I haven’t listened to a podcast, read something in Instapaper, or scanned feeds after a few days, I shove it away. So I can my check email and OmniFocus lists to make sure I didn’t miss anything I wanted or need to do. Then I make awesome things. In the evening, I clear out my reading lists in Instapaper and Reeder. I don’t feel like I’m always behind. This, too, is pretty great.

It’s really easy to let all the reverse chronologically sorted lists we allow into our lives dominate our routines. Clearing those lists makes it easy to see what the next step is and get on with learning interesting things and making awesome stuff.

The joy of logs

Logs Are Streams, Not Files:

But a better conceptual model is to treat logs as time-ordered streams: there is no beginning or end, but rather an ongoing, collated collection of events which we may wish to view in realtime as they happen (e.g. via tail -f or heroku logs --tail) or which we may wish to search in some time window (e.g. via grep or Splunk).
Work on an app with a couple dozen servers, a handful of databases, and several moving parts and you start to realize that logs are one of your best friends. They're useful for troubleshooting, performance monitoring, and just knowing how your application works in reality, under real traffic.

I’ve tinkered with building deeper APIs for logging within applications and services, but I think Adam Wiggins is on the right path here (not the first time either). Logging should be as simple as possible in applications. All the smarts for aggregating, searching, and extracting interesting information should happen after the data is collected. Using standard out instead of files is a fantastic idea too.

I'm Corgi-internet famous

Me + Kitty

OCD: Obsessive Corgi Disorder, Kitty putting the moves on my man. Also on Men and their dogs. I’m corgi-internet famous! Photo by Courtney.

Noel Rappin's Advice on TDD

Testing Advice in Eleven Steps. My favorite:

At any given moment, the next test has some chance of costing you time in the short term. The problem is it’s nearly impossible to tell which tests will cost the time. Play the odds, write the test. Over the long haul, the chance that the tests are really the bottleneck are, in my experience, quite small.

All eleven are pretty handy for those like myself who still feel like they have a lot to learn about TDD, BDD, et. al.

Organizing and decoding problems

My favorite sort of problem involves the interactions between individuals, groups of people, and mechanical rules generated by individuals and groups. Speculating on how the rules were shaped by the experiences of the individuals and groups is a fun game to play when presented with a curious set of circumstances. Conversely, my least favorite problems are those generated by the institutional brain damage of certain kinds of groups. Software and systems shaped by regulations and the particulars of monetary exchange are tedious at best.

I find it quite amusing when answers aren’t “clean” and technological systems aren’t the best solution. Often, no amount of analysis and brilliant coding can make an improvement. What is needed is to understand what people do, why they do it, and persuade them to do otherwise.

This brings me to economics, specifically behavioral economics. If you take away all the math, economics is largely about how people behave in aggregate. It’s a useful tool in understanding how to work with systems that involve people. But there’s more to economics than explaining how people interact in markets.

Russ Roberts, in the process of explaining how economics is not useful as a mechanism for answering questions like “did the stimulus work?” or “when will the housing market recover?”, gets to what really interests me about economics and finance:

"Is economics a science because it is like Darwinian biology? Darwinian biology is very different from the physical sciences. Like economics it is a very useful way to organize your thinking about complex phenomena. But it is not a predictive or very precise science or whatever you want to call it."

The crux of the biscuit, for me, is right in the middle. Economics is a useful way to organize an intricate and interconnected problem and figure out how to reason about it. In casually studying economics and finance over the couple years, I’ve come to form a better mental model about how the world works.

Its possible that this mental modeling is what I do when I’m coding. I’m poking how some code works, looking at its inner workings, trying to understand how it interacts with the code around it. I sift through revision logs to see how it got to where it is today, talk to others on the team about the code and why it ended up one way and not another. I’m organizing and modeling the code in my head, building up a model that describes .

Lately, I’ve been describing my work as tinkering with lines of code until numbers appear on the screen in the right order. This is invariably greeted with a comforting-to-me response like “I could never do that”. But I really enjoy this. I’m not just debugging my code; I’m sharpening the way the program is organized in my head. Once I’ve got my head around it, I decode that organization into words, code, drawings, etc.

With programs, there is some system of rules, forces, and interactions which describe how the code works or doesn’t. Economics, too, describes a system of rules, forces, and interactions that predicts how a puzzle of human beings operate. Organizing and decoding these technical and social puzzles is great fun.

Workouts make focus and discipline

It is probably obvious I have something of a crush on working out. I am proud I have reached a point where being fit is part of my lifestyle and that I see more and more results. But my crush with exercise goes beyond what I see in the mirror.

As important as the physical aspects are, I get the most out of the mental aspects. Working out mirrors what I do in coding in a couple ways. Both require staying on my grind almost every day. Both require the focus to push myself and resist complacency.

It’s easy to spend too much time tinkering with social media or pick the lighter weights. It’s harder to ignore distractions and focus on the task in front of me, whether it’s code or heaving kettlebells.

When I do manage to focus I benefit twice. Immediately I feel great because I challenged myself and moved my work or workout forward. Later, I realize I’m getting better at putting the work in every day and tuning out that which is not important to what I’m trying to do.

The TV infomercial benefits of working out, ripped extremities and a strong core, are a tertiary benefit to developers and creative types. Even the decrease in neck fat, the ability to lift heavy things, and reduced tendency to get winded are auxillary. The real benefit that people who make things get from working out are increased focus and discipline.

Driven to drawing monsters

From my notebook:

Monster
I don't recall what I was working on the time, but it seems that the interaction between many Gowalla models loading from cache via a get class method and something about memcached was causing enough trouble to drive me to draw a little monster.

Clips from unfinished pieces

On the crux of America's challenges:

Part of the American experiment is answering the question, "how can we best take advantage of abundance?" Beginning with manifest destiny and evident in the machinations of Wall Street, one of the story lines of America is the quest to make sure resources of all kind are abundant and generating wealth. But we're arguably at a pivot point. Our money and energy don't go as far as they used to.

How do we make the transition from resource abundance to resource scarcity?

On helping people troubleshoot the Gowalla API:

While this level of self-documentation is quite helpful, sometimes people have questions on the developer list. For this, I've found that asking people to show me whatever it is they're trying to do using curl is invaluable. It's a win-win situation. Often, dropping down to a lower-level tool like curl helps to focus your thinking and makes silly error obvious. If it doesn't become obvious to the API developer, they mail the list with the command they think should work. At that point its either obvious to me and I tell them what to change, or I have a nice, isolated test case from which I can easily try to reproduce their problem.

Who gets screwed when a borrower declares bankrupcty?

Is it possible that bankruptcy-declaring-borrowers are screwing lenders in aggregate? I find it really hard to believe that the banking industry, with its legion of lobbyists and regulatory capture, that any group of uncoordinated individuals could screw the banks.

On the other hand, there was lots of screwing on the part of the banks that led to the financial crisis. Whether it was predatory lending, relying on moral hazard to double down on terrible bets, or asinine compensation structures, the financial industry did something very human. They violated social norms. Except, corporations of this size don't have social norms. They have only market incentives; when the executives, board members, and majority shareholders look at the books, the numbers devoted to "doing the right thing" are probably a rounding error.

On tail recursion and compilers:

Fact of life: modern processors don't execute your code in the order the compiler spits it out.

If your code has, for instance, two adds followed by an if statement, it's pretty likely that second add is going to be executed concurrently or after the conditional. In the world of computer architecture, they call this out-of-order execution, and it's just another service your hard working processor offers to make sure your code runs faster than you ever intended it to.

On shorter cycles of production and the need to get past perfectionism:

Our modes of production are causing us to change how we produce. More and more mediums, be it journalism or software, are produced on shorter timelines. This is leading us to optimize production such that we can bang the content or code that matters into templates that mostly work, but have a tolerance for the rough edges where things don't work.

On Barack Obama's 2010 State of the Union speech that preceeded the health care debate:

Just for grins, I went and read the GOP response to the State of the Union. While they had some vague counterpoints policy-wise, it read mostly as subtle and useless jabs combined with carefully-constructed language to console their base. The GOP is a cynical, gutless organization.

On refactoring and deleting code:

People often say that they would miss having a refactoring browser in languages like Ruby, JavaScript, or anything that is reasonably dynamic. My glib response to this sort of comment is invariably "well, the best refactoring I know is to select the code to modify, hit delete, and start over." Let's take that apart.

I've observed that, despite our best intentions, we are often loathe to change code that we suspect is working, or that we suspect we don't know why it's there. And so, like the planet on which we live, applications accrete into Katamari balls of overly-coupled code that is bound only by locality. Cutting this Gordian knot is often the first step in reclaiming a project.

Deleting code is the knife with which we can attack this problem. Many will acknowledge the goodness of deleting code; it is, quite nearly, a virtue unto itself. I've observed that some of the best developers I know are always on the lookout for ways they can obviate code. So, by way of a strawman, I hope you see that I'm quite correct in this regard.

Focus, momentum, and accomplishment

Lately, I’m a little fascinated by the interplay between focus, momentum, and accomplishment. Focus is the feeling of flow, the world around you fading away. Momentum is the feeling that you’re moving things along, getting stuff done. Accomplishment is stepping back, looking at what you’ve done, and feeling like you did something good. These factors play out differently in the three activities to which I decide much of my time.

When I’m building software, I’ve found that momentum leads to focus, accomplishments yield momentum, but focus does not necessarily yield accomplishments. Yet, the most exciting moments seem to come when I’m focused and building momentum. Those times when my attention is fragmented but I’m working through a list of stuff that needs to get done doesn’t feel like accomplishment, but it does seem to get the job done.

Anecodotally, it seems that, by definition, Monday is the day of the week that lacks focus but still possesses some form of accomplishment. It’s the sacrificial lamb of the work week.

When I’m reading, writing, and organizing information, I’ve found that momentum is not much of a factor. It’s all about focus. Stick my head into a cluster of ideas, focus on what I’m reading, how I’m thinking about it, or how I’m writing it back out. Keep the problem state in my head, admitting as few distractions as possible. Come up for air periodically, review my progress, and decide to either continue or move on to other things.

Of these three activities, I’ve found that I’m most methodical about how I use momentum when I’m thinking. It’s sort of a rate limiter; after I’ve read something particularly dense, I’ll immediately do something banal like catch up on social medias. Not sure if this tendency is enhancing or diminishing my thinking.

I spend several hours a week training. The coffee shop (thinking) and the gym (training) are my third place(s). Recently, it feels like I’ve leveled up. I had a few consecutive workouts where I was more focused than I’ve ever been whilst exercising; no worries about my breathing, or if I was pushing myself too little or too much. From this focus I found momentum. A couple minutes on the treadmill would turn into tens of minutes, then a half hour. One set of strength exercises would blend into the next. I was able to push myself to higher levels of accomplishments. It felt awesome.

Interestingly enough, I’ve found that I need a day off from each of these activities. As awesome as it sounds to have the kind of intensity that lets one make awesome things every day of the week, I’ve found it necessary to relax and take time away from coding, thinking, and training. As it turns out relaxation is an important part of a balanced diet of focus, momentum, and accomplishment.