Find the Why to Find the Way

Junior programmers want to know the “right way” to do things. When I teach, I tell people that the right way to do something is the way they can do it right now. Figure out how to do what you want, and keep doing it. If you can consistently complete a task without fully understanding the steps involved, you will prepare yourself for new understanding.

As you learn, you will apply the things you learn to the things you have done. You will develop a new context and appreciation for the work you have done. You will begin looking for new things to do and new ways of doing them.

Eventually, after having practiced the what and studied the how, you will begin to ask why. You will ask why the things you do work. You will ask why you do them. You will see that the things you have done are just a selection of infinite possibilities, the path you’ve taken so far one of countless possible. You will continue to practice, and study. You will learn not to see opportunity or to create it, but to exist with it. You will share what you have learned with others.

Do what you can right now. Make your own way. Find your why. Never stop.

*poof* … and then Rails was gone

DHH posted some code extracted from Jim Weirich’s talk on Hexagonal Architecture in Rails, and invited people to present alternative solutions. Here’s one of mine.

A hexagonal application

DHH’s first example satisfies the intent and properties of the hexagonal architecture. It allows the application to equally be driven by multiple clients and to be developed and tested in isolation from its eventual deployment environments. It defines ports for interacting with the application and requires adapters to use the ports.

Look at his example controlller:

I don’t see any dependencies on Rails, do you? I see a dozen lines of code that follow the conventions used in many Rails applications, but I do not see Railties, ActiveRecord, ActionController, ActionPack, ActiveSupport, or any of the libraries core to the Ruby on Rails framework. I see an application that saves employee records. It abstracts the details of how it saves those records, and how it gets its input.

Spotting the Ports

Looking at this bit of code through the lens of ports and adapters, I see a couple ports. The first port saves the employee record. The second port accepts input from a user and communicates results back to the user.

The ports are still a bit abstract at this point, so I’ll define protocols for the adapters to follow:

These specs make it easy for me to write new adapters to work with this application. If I can implement objects that satisfy this protocol, I can extend the capabilities of the application without modifying its core logic, and I can change the core logic independent of the technologies that support the application.

When I write the specs out like that, I’m amused by what seems to be a good bit of work to support 10 lines of code. At first I thought this might be too trivial of an example, but I’ve identified two protocols that together define six methods.

Adapters bring new capabilities

I’ll start off with a persistence adapter. The first one can work in memory to get me going.

Next I’ll make a view adapter to accept input and provide feedback.

Now I need to connect the adapters to the application. I can do this without changing any application code.

By ordering everything right, I can paste it all into irb to run the app.

Modular design

In 30 lines of code I’ve built entirely new adapters to DHH’s application. I didn’t abstract Rails away – DHH’s design decisions meant that Rails was never there to begin with.

It’s not just a lovely bit of Ruby trickery ;) This is what happens when you work towards a hexagonal architecture – you design applications that speak well-defined protocols and depend on abstractions. The architecture doesn’t make this happen automatically. You have to think about the architecture and make design decisions to support it.

Keepin it Hexy

In terms of hexagonal architecture, the original Rails controller and action fulfill the properties of making application logic available via protocols, and keeping the application logic independent of persistence and UI implementation details.

I hadn’t considered that the view might be the primary adapter and so it makes sense to inherit from it. I think refactoring to make the dependencies explicit will lead to a more natural design.

Inverting the dependencies let me move the application code right to the top. It now purely expresses the application code without any hidden dependencies. You can use the protocol specs to define new adapters easily.

Wrap up

Ultimately, the hexagonal architecture style attempts to guide you toward a modular design style. A modular design style enables powerful software systems that are easy to reason about and change. DHH may have tried “to illustrate the design damage that’s being induced by following this pattern”, but I’d say his example shows how easy it is to apply the hexagonal architecture in Ruby. Hexagonal architecture doesn’t replace your design sensibilities, it augments them by providing a set of factors to consider when designing software.

Fear of failure

By most measures, I led a charmed life growing up. My family wasn’t wealthy, but I never missed a meal other than when my dad took us on adventures and forgot that children need food to make it through the day. I went to good schools, with good teachers and good fellow students. I traveled the world courtesy of the US Navy. Both of my parents were around as much as they could be. Dad got deployed regularly, yet I remember him coaching most of my soccer teams and serving as a leader in my Boy Scout troops. Mom worked the night shift at hospitals, and still managed to drive my brother and me to and from school every day. They read to us, took us hiking and fishing and camping, told us stories, and planned reunions with our extended family. They provided my brother and me with all the love and support any kids could hope for. They took an active interest in our own interests, and it has paid off. My brother, aka “Grease,” flies an F-15 for the Oregon Air National Guard. My software career has taken me all over the world and helped me make hundreds, if not thousands, of wonderful friendships in the process. Basically my parents did everything in their power to set us up for success, to prepare us to go out into the world and make of ourselves whatever we want. I think they did a damn good job.

One thing they didn’t prepare me for, however, was failure. Now that’s probably unfair to say, because I got the “it’s not getting knocked over that matters, what matters is picking yourself up” lecture from my dad more times than I can count. “Stick-to-it-iveness,” as my mom calls it, is highly valued in our family. My brother inadvertently coined the term “gription” when he was 8 in order to describe that never-give-up nature of his own, unable to string together as many syllables as my mom or separate the concepts of “grip” and “traction.” In some twisted way I think I can take a bit of credit for preparing him to deal with failure, having spent over a decade beating him in every contest where a physical advantage was an unfair advantage. As for me, given the world I grew up in, I never knew real failure. Looking back it feels like I was walking along the blades of a powered-off blender, unaware that life had its finger on the button, just waiting for the right moment to push.

I remember the first time I failed, or at least the first time I feel like I failed. It was my senior year of high school, when my soccer team lost in the semi-final round of the Colorado state soccer tournament. Heartbreaking as it was, losing that match wasn’t my failure. My failure came a month or two beforehand, during an after-school practice. Earlier that week, a couple of the younger players had screwed up in a big way and our coach was pissed. He began the practice by having us run “suicides,” where you start at one end of the pitch, and run sprints to and from each of the lines across the pitch. After ten of these, a downright exhausting workout, he lectured us on the behavior that he expected from our team. Then he announced that our practice would be the usual two hours, only this time we were to run suicides the entire time! We could go home when we felt like we had worked hard enough that day. Then he blew the whistle and that was that. I ran two or three suicides before calling it a day. I had AP Chem to study for, and after all I wasn’t one of the screwups so I wasn’t going to take their punishment. That’s where I failed. I failed to push myself. I failed to support my coach. I failed to stick it out with the one player – our team captain – who ran until our coach forced him to stop because he looked like he was going to fall over and die. I failed to serve as a good example to the younger players on my team. I failed to share with them the lessons that I had learned from the truly excellent leaders I was blessed to work with in my life up to that point.

I won’t be offended if you’re laughing at me by now, at this self-indulgent account of failure which doesn’t even begin to touch the realities of life. I direct you back to my blender metaphor. That was the year that life pushed the button on me. Still, I think it was closer to a puree setting than full on ice crush or liquify.

That was the year that my parents got divorced, my high school sweetheart dumped me, and I voluntarily enrolled in an engineering school in upstate New York. Lacking any sort of motivation to get out of bed most days, and feeling a billion miles away from the supportive family I grew up with, I started getting bad grades for the first time in my life. I got my first D, and my second D, and then I dropped out before I could get my first F. I moved to Washington state where I could play poker, and lived with my dad for a month when he took me in in an effort to bridge the relationship that I had chosen to sever. Living with mom wasn’t an option. She liked to tell us that her job was that of an archer, drawing the bow back and aiming it as best she could and then relinquishing control once she had let the arrows loose. She was pissed, hurt, and fearful when one of those arrows chose to drop out of an excellent university and play poker instead.

At this point I’m still 19, and the blender is still set to puree. Most people know what the higher settings feel like, as I’ve learned since then – family members battling cancer; friends going to prison; friends going to fight a war, and not always coming back; people lying and cheating and stealing; loved ones passing way too soon.

If I’ve made you depressed, I’m sorry. This stuff has taken the last ten years of my life to sort out and it’s pretty clear that I need to get it out now. I promise to turn things around and end on a positive note.

I was not prepared for any of the nasty things life threw my way. I was not prepared to be hurt far beyond anything I had experienced before, for reasons that I could not understand. The world I grew up in – the happy, blissful, charmed existence of my youth – was shattered, and I was fucking terrified. I stopped doing many of the things I loved. I stopped opening myself up to new people and new experiences. I stopped pushing myself because I was scared to fail, that I would fail to achieve every outcome that I wanted. I was given plenty of lessons that I couldn’t predict and control every outcome, and that all I could control was my own response – just as my parents had taught me growing up. Being young and brand new to this reality thing, I denied it. Hard. When things didn’t go my way, I got hammered, or high, or took my anger and frustration out on people that I cared about. I didn’t think the rules applied to me, that I was exempt from the harsh realities of life. I spent the next ten years engaging in the parts of life I enjoyed and escaping from those I didn’t.

Some folks who know me might find this post strange. After all, I’m a happy guy, I do cool things, I have incredible friends and family. I’m certainly not a giant fuckup. The reason I can spend this much time writing about the negative things from the last ten years is that there’s not enough time in the world to write about all the positive things that have happened in that same time.

I feel weird. Despite all the positives and success in my life, I feel like I have been just a shadow of who I really am, who I can be. I have been so afraid of failure and pain that I have denied myself opportunities to achieve the success I want. I didn’t really have any idea until recently. Several months ago, one of my best friends flew down to see me to find out what was going on with me. He looked me in the eye and said, “You have so much potential, and it seems like you don’t even know it and you’re throwing it away, and it fucking kills me. What’s up?” All I could manage was “I don’t know man…I don’t know.” I was too scared to tell him the truth, scared to tarnish the image I felt he had of me as someone having my shit together. I was too scared to tell my best friend – one of the few people who cared enough to ask and cared even more to listen – that I struggled with addiction and depression, both made worse by the fact that I didn’t understand why and was too proud to tell anyone or ask for help.

I have made big changes for myself. I’ve kicked the bad shit and cut back on the not-quite-as-bad shit. I am now willing to face the unpleasantries that are part of the reality of life. I choose to face them instead of escape. I choose to get over my fear of being exposed as imperfectly human to myself and others, to share my failures and get help when I need it.

Looking back, I feel bad for the kid who felt the need to escape whenever he didn’t like what life threw his way. But I get it – I am that kid, just a little older and wiser. I’m still scared of pain and failure, that hasn’t gone away. I don’t need to succumb to it anymore. I don’t welcome it, but I acknowledge it, and choose to experience it as a part of my life. I understand now that each moment where I actively engage in my own life is a blessing that I give myself. There’s nothing profound about that statement, I must have heard it hundreds of times in various forms from other people. What is profound, for me, is applying it to myself for the first time that I can remember.

To the people who have helped me through tough shit: thank you. You engaged me when I couldn’t do it myself. To everyone who has seen the spark in my eyes when we work or play or talk or hang out: thank you. You engaged me in that moment and in doing so helped me engage myself. You helped me get a win that I didn’t even know I desperately needed until now. You let me experience my true self in those moments. After enough practice, I’m able to do it on my own, even when the moments are unpleasant.

TGIF. Let’s kick some ass today :)

Learning about my privilege

Well, yeah. Part of my privilege is being able to go through life basically unaware that bad things happen to good people solely because they’re women, or brown, or muslim, or gay, or any other number of attributes that don’t apply to me. I’m not completely unaware, but I certainly was for the first 25 years of my life. That’s part of the privilege of being a white dude born to educated parents who worked for the United States Navy, I guess.

What has changed? Well to start, I dated a woman who wouldn’t let me off the hook for being ignorant just because I’m mostly a good person. She made me aware of social and cultural dynamics that I never knew existed. She clued me in to issues that I have the privilege of not experiencing first-hand.

Second, I work in an industry that over the past few years has become more aware and vocal of the social and economic gaps between privileged groups and marginalized groups. I don’t know how this awareness compares to other industries, but I do know that technologists – software technologists in particular – are uniquely suited to address disparity problems. Collectively we have a great deal of privilege that many people throughout the world do not enjoy. We can work from home, the beach, Paris, wherever we feel like. We can build successful businesses without ever stopping to put on pants. We can drop out of college and still pull down six figures. We can stretch our minds every single day, play with new concepts and ideas and never have to do the same thing twice. Most importantly, we can teach others to do all of these things.

Folks that enjoy privilege need to participate in this conversation. We need to start by listening. We also need to express our ideas in order to get feedback and learn. By necessity we start off simply, because we don’t share the same experience and perspective. I don’t expect a pat on the back for trying not to be an ignorant asshole, but I am aware that for me personally, playing with duplos represents progress. At the very least, I’m starting to put pieces together.

Why not to pair

After 10 years in the game, I’ve finally managed to articulate the reasons why I feel it’s not worth pair programming. Behold!

It costs twice as much

I get so frustrated when I board a plane and see two pilots in the cockpit. If airlines would stop paying two people for one job, maybe I could check my baggage for free.

Earlier this year I had ankle surgery, and there were five doctors in the operating room – FIVE! How does someone call himself a surgeon if he needs other people to help him perform a surgery? The operation set me back 10 grand…greedy bastards.  I could have gotten a pimped out Mac Pro with the money they overcharged me.

You can’t tell me that it’s a safety issue in aviation and surgery. Commercial airplanes are basically giant computers that fly themselves. They’re not prone to drinking before flights and don’t give in to terrorist demands in the petty hope of making it home alive to see their families. Navy corpsman have performed countless field surgeries with far less training and in far harsher conditions than the so-called “elite” surgeons that work in the comfort of sterile operating room.

Problem solving is not a social activity

I hate articulating problems to others and processing their feedback. It uses up valuable bandwidth that would be better dedicated to holing myself up and tinkering away until I come up with something to brilliant. Everyone knows that Crick was just a pain in Watson’s neck.

Learn on your own time, not on the job

If you don’t know exactly what to do at all times, you’re really not qualified for the job in the first place. Go home and study until you get your skills up to snuff. All problems that arise in a software project can be avoided with a little more upfront analysis and design, so don’t expect to be paid to figure things out.

Develop software, not people

Nobody mentored me, I had to learn this stuff the hard way through good old fashioned hard work. Unless other people go through that same process they won’t appreciate the secrets of professional software development. I once spent 10 hours tracking down a syntax error, and I didn’t even know what a syntax error was! That built character. Programmers these days give up too easily. No wonder they need crutches like automated tests and version control – if they spent more time making sure their code worked right they wouldn’t need all those tests, and wouldn’t feel the need to go back to an older version from time to time.

On the flip side, explaining things to others is just a waste of time for senior developers. They won’t learn anything from someone who has different experiences. It’s not worth seeing the programming world through the eyes of another person. Nobody ever deepened their understanding of a subject by teaching it to others. In fact they risk losing their expertise by being forced to water it down.

Culture happens from the top-down

When people work closely together, they risk forming bonds and working styles that differ from those outlined in the corporate culture handbook. They might start to spend their lunch breaks together, talking about non work-related things, and miss out on the team-building nerf gun fights & foosball tournaments.

Loss of personal freedom

I love putting on headphones and listening to music when I program, but I can’t do that when I pair. I have to share a stereo with the people around me and occasionally negotiate with them about what music we listen to. We have to take turns sharing equipment and space, and I’m forced to share a bit of another person’s perspective.

Get on with your bad self, by yourself. I know I will.

Exploiting the GitHub profiling problem

Late last week I read two articles about the problems that arise when companies use GitHub and open source as a way to evaluate job applicants. Ashe Dryden examines it from an ethical perspective, arguing that it disproportionately favors white men, who already enjoy disproportionate favor. James Coglan argues that a GitHub profile doesn’t say nearly as much about a person as some employers might think. Both articles are worth reading if you haven’t yet done so, and serve to help move our industry forward.

While reading the articles, particularly Ashe’s, I couldn’t take my mind off the obvious solution to a small part of the problem. If employers look at GitHub profiles…post something to GitHub.

Of course this does nothing to address the broader issues that Ashe and James discuss. That’s a lot harder and will take time and effort, and I’m grateful for people like Ashe and others in the community who have dedicated their time and effort to increasing diversity and tolerance in the software community and the world at large. Unfortunately, change is slow, particularly when it comes to righting injustices against disadvantaged groups of people. Slavery was abolished in the United States less than 150 years ago, but still continues in parts of the world (including in the US in the form of human trafficking).

We absolutely must continue working to level the playing field in our community. GitHub helps do that by being a freely available service that allows you to connect with other people. Any problems that arise are not because of GitHub or open source, but from a culture that permits people to attack and threaten others because…well, I don’t know why. If you’ve been paying attention, you’ll realize that our culture doesn’t actually permit that behavior at all – those people are assholes.

I understand that many people do not have time to dedicate to open source. That’s fine. I think you can make a favorable impression on a potential employer by spending 5 minutes per day posting something new to GitHub. I understand that many people might not want to have a public profile. In that case I suggest creating a semi-anonymous profile that you use only as a way to share code examples with potential employers. You might even explain to them why you aren’t publicly active on GitHub – Ashe has provided plenty of examples.

I admit that as someone who has benefitted from my involvement in open source, and has used open source as one indicator when evaluating job applicants, I was not aware of and cannot fully relate to the problems that Ashe has brought up. I think this discussion gives us an opportunity to evaluate and improve hiring practices moving forward. I also think it’s an opportunity for anyone – regardless of gender or race – to help themselves by posting some code. All it really takes to become an open source contributor is to share some code and slap an open source license on it. Hack the planet!

Why I think Google and Facebook are creepy and the NSA is criminal

My dad and I love to talk politics. After Edward Snowden leaked his information about the NSA’s massive spy campaign against American citizens, we had plenty to talk about. My dad has been a Navy officer for nearly 30 years, has served overseas for a third of that time including a tour in Iraq, and currently lives overseas. The words “Obama”, “Congress”, “war”, and “terrorism” regularly come up in our conversations. I suspect that our phone calls get “flagged,” whatever that means. I’m okay with that. My dad knows some shit that neither I nor the US government want him sharing, and of course he never would. When he signed up for the military he chose to sacrifice some of his Constitutional rights in order to protect mine and yours.

When we first talked about NSA’s prism program, he argued that companies like Google, Facebook, and Amazon have been collecting information on their users for years, and exploiting it for profit. He’s absolutely right. I find it disgusting and creepy, and I think that this profit-above-all-else mentality we’ve come to adopt in the US is diminishing in social acceptability. I hope that over time we choose to legislate such activity in order to protect people’s personal information.

NSA’s Prism, on the other hand, is criminal.

What’s the difference? Google & Facebook are companies that I can choose to engage. I had a Facebook account, now I don’t. I used to be a user and champion of all things Google, now I keep my distance. I can’t do anything about our past history – they have info on me and will do with it what they see fit – but I can choose not to give them any more info from this day forward. I can opt out. Not so with Prism. I have absolutely no power there – the NSA collects whatever information they like without being accountable to anyone. They use American tax dollars to observe the behaviors and communications of the very taxpaying citizens that until recently have unwittingly funded their own surveillance. I consider such surveillance to clearly be a chilling effect on freedom of speech, a threat to our Constitutional freedom. That’s before we go down the slippery slope of what corrupt governments have historically done with the information they obtain from surveilling their citizens.

With Google & Facebook, I have a rational choice: I can decide that I get enough value from their services to justify sharing my personal information, or not. With Prism, I am forced into an irrational choice: call bullshit on my government and help our nation change (good), go with the flow and accept the chilling effect of a government that spies on its citizens (weak sauce), or renounce my citizenship (decidedly un-American). Our nation was founded on a principle of freedom of choice, and for nearly two and a half centuries has served as an example of the power and importance of that freedom. We may have gotten off track recently, but I’m optimistic about our ability to regain our American principles and be a good example to and citizen of the global community. Ending unchecked surveillance against law-abiding citizens will be a massive step in that direction.

What Peyton Manning can teach us about agile development

Peyton Manning is having a historic season, and looks poised to take my beloved Denver Broncos deep into the playoffs and hopefully bring home a Super Bowl trophy. How does he do it? It turns out that the Denver Broncos are a high-functioning agile team, and we can see how several key agile principles play out in a football context.

Rapid planning, rapid execution

Football teams work in short iterations in order to achieve their objective of shipping touchdowns. Each play has two parts – planning and execution. Before the play, the offense huddles up to determine which play to run. When they line up, each player understands how he’s supposed to contribute to help his team move the ball closer to the end zone. Once the ball is snapped, each player performs to the best of his abilities to make that play a success. As soon as the play’s done, they do it all over again. Each play looks a bit different, but follows the same cycle of planning & execution.

Common skills, unique talents

Peyton Manning is one of the best quarterbacks to play the game, but that doesn’t mean he’s only good at throwing the ball. Football requires all players to practice a core set of skills – running, blocking, tackling, ball-handling, and passing. Although Peyton doesn’t participate in tackling drills to the same extent as defensive players, you can bet he still practices this basic skill in case he needs to make a key tackle (or at least help with one).

Communication is key

When offensive plays fails, it’s usually because of breakdowns in communication. A lineman misses his blocking assignment, or a receiver breaks from his route too late, or the quarterback fails to notice an oncoming blitz. Good teams communicate constantly, and nobody does it better than Peyton Manning. He has a plan before the snap, but once the teams line up he has new information. Taking in this new information and communicating with the rest of the team is key to adapting to the situation and making successful plays.

Getting up when you’re knocked down

Everyone gets knocked down from time to time. Cliche as it is, success comes from picking yourself up, dusting yourself off, and giving it another shot. Every team faces setbacks, whether it’s a result of human error or something far beyond our control. In each case we have an opportunity to respond to the situation and learn from it. Experience, especially the bad kind, is the first step in learning.

I hope this will make the next football game you watch just a little more interesting. Where else do you see agile principles applied outside of software development?

Join me for an online hangout where we’ll talk about RSpec, TDD, software design, and more

Update: We’ve scheduled a date and time for the session. Get the details here.


I got an email the other day asking if I’d be interested in hosting RSpec office hours using enginehere.com. I love thinking and talking about this stuff, and when I checked out EngineHere I found a platform that looks like it makes it really easy for a group of developers to talk shop and argue about code. Here’s what we can do on EngineHere:

  • live text & audio chat
  • live edit & run code
  • live stack overflow-style q&a w/ voting & discussion

Basically it’s for doing stuff live! Combining the different ways that developers communicate into a tool that makes live communication as simple as longer-cycle asynchronous communication. Kinda like what Google Wave was supposed to be, only useful :)

I expect a lively discussion…I wonder if digital medium means we’ll break the record for shortest time before someone brings up mocks and all hell breaks loose. It’ll be an open forum, we’ll talk about whatever people want to talk about, but I’ll guide it as best I can from my experience in software testing and working with people to study and improve their own practices.

The hangout is totally free, and signup takes 10 seconds via github. Ben, the guy who built EngineHere, said he’s got a few kinks to work out before we can do it, so I’m guessing it’ll be a couple weeks. If you want to participate, there are three ways I can notify you of the details:

Tell your friends, bring a loved one, it’s gonna be a good time!