Software development companies that I recommend hiring or working at

Software development companies that I recommend hiring or working at

People often ask if I can recommend companies to work on large software
projects. Just as often, people ask me if I can suggest companies they should
apply to work at. I’ve always listed a few solid recommendations, and then a
couple others that I think might be good based on people I know that work there
or have worked there.

I’m changing my policy as of today. I’m only going to give the solid
recommendations – the recommendations I can give based on my personal
experience. With that in mind, if you are looking to hire a company to work on
your software project, or you are looking for a place to bring your talents, I
suggest contacting:

The answer is the same for both questions – who to hire, and where to work -
because a place that does the best work is where the best people want to work -
and they do.

I have worked for a client of Pivotal Labs, and worked for Pivotal as a
contractor. They have perfected the art of constructing effective software. They
also have created a work environment that I think is just killer – smart and
friendly coworkers, a commitment to best practices, predictable SANE hours,
regular learning opportunities, and oh yeah the amazing breakfast every morning.

I’ve known the brains behind Thunderbolt Labs for several years. They take a
scientific approach to software development, and cut through way more bullshit
than you’re prepared to throw at them. As far as work environment, they work
mostly remotely and have the smartest people I’ve ever seen on one team. Working
for Thunderbolt got my fingers in two of the biggest software projects to happen
in 2013 in my opinion, in terms of visibility and coolness. Perhaps they’ll give
me permission to reveal the clients’ names… :)

The rest

I’m sure there are a lot of wonderful companies out there that will do a great
job of building your software, or be a great place for you to grow as a
developer. At this point, I can only honestly recommend places that I have
direct experience with – and I have lots of direct experience with Pivotal and
Thunderbolt Labs.

HOWEVER if you think your company should be on this list, we can absolutely make
it happen. All we need to do is arrange for me to spend 2+ days working with
your team in an ordinary work environment (other than the fact that there’s an
outside observer who’s apparently doing reviews on his blog?). You don’t pay me,
you just cover my travel and accomodations. If I choose not to recommend you, I
won’t ever say anything about my visit. If I do recommend you though, you will
join the list of what are – in my opinion at least – elite software development

If you want to build the skills you need to work at top software companies, check out my RubySteps learning program. You’ll receive daily code examples with explanations, and one interactive lesson each week that will help you become a better programmer, absolutely free.

How you can learn more by writing code than by reading it

When you’re learning to program, you’ll often hear the advice
"learn how to read code". The idea is that by reading code, you will see how other people do it and you will pick up on it, and learn new techniques and ideas. That’s like saying you can
improve your walking technique by watching other people run – and you haven’t
yet learned to walk! In linguistic terms, you don’t know how to ask where the
bathroom is, and you’re sitting down to read something that could be a technical
manual for hydraulic toilets or could be a guidebook to the most luxurious
bathrooms in France!

I know I sound ridiculous. I sound ridiculous for saying you can learn more by
ignoring everyone and focusing on your own programs. What if you don’t know how
to program? If you’ve ever done a hello world tutorial, you can program. You
won’t be able to do as much as you want, and you won’t be able to do as much as
other people, but you will still be able to write an endless number of
programs. Most importantly, you will be in a position to learn more by asking
questions, reading lots of documentation, and yes – learning from other people’s

Here’s my 1-step guide to becoming an expert programmer:


If that doesn’t work for you, try again. And again, and again, until it works. I
promise you it works. It’s what I’ve done to develop my career over the past ten

You’re probably wondering why you should write so many programs, instead of
reading other people’s code. Writing code is the best way for you to develop
your sense of coding style. You will express ideas, and you will experiment. You
will feel things as you write code and read it over, and you will incorporate
those feelings into your regular work as a programmer.

This goes double if you’re just getting started. You don’t want to try to
understand someone else’s style before you’ve started to understand your
own. There will come a time when it makes sense to read someone else’s code, and
where doing so will challenge your coding sensibilities. I do not think that
time comes until you’ve written at least 100 programs, and I do not think that
time comes regularly for more experienced programmers. You will spend plenty of
time reading other people’s code as part of your work – it will quickly become a
part of your daily practice.

If I can go into old geezer mode for a moment (hey, I just turned 29 the other
day)… I really wish I knew about version control systems when I was first
learning to program. I remember some cool programs I wrote – poker simulators,
my first web application, "love programs" I wrote for valentines (not as
romantic as I’d hoped). I don’t have the source code for them anymore, and I’d
love to have them. They’re like old records, I guess. Anyway, if you’re reading
this, then I’m sure you can find access to free version control hosting. I
highly suggest keeping copies of your programs in version control. You will
build up good habits, practice skills that are critical to your success as a
professional programmer, and have a logbook of everything you’ve done. This can
be very motivating, and it will definitely be valuable when it comes to
remembering something you’ve done. It’s also a great starting point for a

Reading is the secret to your success

When I was a kid, my favorite tv show was reading rainbow. It still blows my
mind that they had a tv show about books and reading. It blows my mind even more
that Levar Burton just raised the most money in kickstarter history to bring it
back and put it in more homes and classrooms than ever before.

Anyway, my point is that reading is not only important, it’s also amazing and
will make your life better. If you read anything right now, make it the error
messages. Make it anything on the console. Read every last little piece of
information that the computer feeds back to you as you use it, because that is
the most relevant and useful information you will ever get. Read the
documentation for the software you use – the majority of software out there has
no documentation, or out-of-date documentation, so if you do come across a
project with comprehensive, useful documentation, you have struck upon a gold
mine. Too many newbies ignore the documentation, and don’t read command line
output because they don’t understand it. Newsflash: the only way you’ll learn to
understand it is by reading it and figuring it out. I use google all the time,
but I still have to figure out what it is I’m looking for.

Once you have a habit of writing code, and reading computer interactions and
documentation, you should incorporate reading other people’s code. Expand as
much as you can and read as much code as you can. See what’s available and
incorporate what you learn into your work. But don’t do that until you’ve
developed a coding style. Don’t do it until you’ve developed a coding lifestyle.

If you want to develop a coding lifestyle, my RubySteps learning program will help you build a daily practice for programming success. You’ll receive daily code examples with explanations, and one interactive lesson each week that will help you become a better programmer, absolutely free.

Why learning your second programming language can be harder than the first

Learning a new programming language is never easy. You have to learn new syntax,
tools, and libraries. You make use of what you already know in order to
understand new things, but sometimes what you know can make it harder to
understand a new concept.

I’ve noticed that this applies especially to people who are learning their
second programming language. Becoming a programmer already warps your brain
enough – when you discover that what you’ve learned is just one of many
different ways to think about solving programming problems, it can be tough to
handle. I have seen professional programmers of ten years baffled by things like
blocks in Ruby. Now I’ll be the first to claim fault with my teaching, but
I’ve used those same teaching methods with people who have never studied
programming and they’ve been able to get it. I am certain it is not that the
professional programmers are bad at what they do, but that their thinking is so
ingrained that they literally can’t accept the idea when I show them something
radically different from what they already know.

Whether you’re learning your second language or your twentieth, here’s what I
suggest: as you work, and as you go through documentation and educational
materials, make a list of EVERYTHING. Every function, every library, every tool,
every concept. Build up that list for the first week or two, don’t do anything
with it. Then go through the list, and map everything on it to things you
already know. What do you know about how strings work? What do you know about
order of operations? Networking? Exception Handling? Now you have a list of
things that the language has that you’re familiar with. It also represents a
starting off point for investigating further – you’ve identified similarities
with this language and other languages you know, but now you need to learn how
it differs. You don’t want your knowledge of another language to incorrectly
prejudice your understanding of the new one.

Additionally, you’ll have a list of things that don’t map up to anything you
know. This represents even more learning opportunities, ones you may struggle
with. Keep your head up – it’s okay if it’s hard. It is a brand new part
of your mental universe, after all!

If you’re struggling to make the leap into the Ruby programming world, my RubySteps daily learning program can help you. You’ll receive daily code examples with explanations, and one interactive lesson each week that will help you become a better programmer, absolutely free.

Why pairing with someone who knows less than you is the best way you can spend your time

People who don’t like to pair program have a number of reasons that I won’t get into in this post. One that I will get into that regularly comes up is the frustration they feel when pairing with someone junior to them – someone who knows comparatively little about a problem or how to solve it. They feel that explaining things slows them down and uses up energy that they could direct toward solving the problem itself.

I understand where they’re coming from. Explaining things to someone is hard and takes a lot of energy. It takes patience, especially when the person just doesn’t seem to get it. I feel that frustration. I think of all the work I have left to do, a list of work that really will never end, and I think if I could just move through that list faster everything would be better. I feel the exhaustion of looking for new ways to explain things, knowing the answer but not knowing how to communicate it in a way someone else can understand.

All programmers feel frustration. We feel frustration when we’re first learning and are faced with the task of figuring out endless error messages. We feel frustration when code doesn’t work the way we think it should, or the way we want it to. We feel frustration when our managers change the requirements on us yet again, and move the deadline up a week.

Frankly, I’m not sure the frustration ever ends. We may feel we have reprieves from it, but in my experience it’s just that another kind of frustration has taken over for the time being.

Highly collaborative environments accept frustration – in fact they may encourage it in the form of tough questions and lively debates. Frustration, as something that never really ends, can be dealt with in a group in interesting ways that I don’t think are available to individuals.

When you explain something to someone, you take on all the frustrations that go along with that. You also take on their frustration in a way – by taking some on yourself, you allow their original frustration to be replaced by a different one that involves them grasping what it is you want them to grasp. If they are struggling to reach a branch, you may struggle in bending that branch towards them, but in doing so allow them to reach what they want.

By pairing, you work differently. You stop thinking solely in terms of producing software, and start thinking in terms of the human interactions that produce software. You start thinking of how you can communicate your ideas rather than simply how to execute them. You allow for ideas to be expressed out loud, interpreted by someone else, and fed back to you.

I believe that this approach will lead to better health and longevity for programmers than an approach based primarily on problem-solving according to a schedule. Such approaches create frustration without effective ways of managing it, and that leads to burnout. I have seen this in myself, my friends, and in people sharing countless stories across the web.

The next time you pair with someone, consider this: they don’t know less than you do, they know differently than you do. Their understanding of the world extends in ways that yours doesn’t, and by communicating with them you will learn new ways of thinking and experiencing. You will see the sorts of problems people run into when they’re unfamiliar with a system. This applies whether it’s at a code level or using the running software system. You have made many assumptions – among them the idea that writing code quickly has more value than teaching someone and exploring problems together. Your assumptions prevent you from seeing systems in a certain way, and someone with different knowledge than you can provide valuable insight through new perspectives.

Answering questions forces you to hear your thinking out loud and clarify your thinking in a way that you can express to someone else. This skill is invaluable in terms of your career and life, so if you can build it just by explaining things you know to someone who knows differently, you can make a big impact over the long term.

Beyond that, working alongside someone else is a great way to help them succeed. Sometimes people are afraid of competition, but that is very short-term thinking. The more people that do well in an organization, the more the organization needs to make room to let the successful people shine. When you do eventually leave a company, you are most likely to get your next job via someone you’ve worked with before. You’re also the least likely to get your next job via someone you’ve worked with before. As a friend of mine says, “You meet the same people coming up as you do coming down.” By working with someone to help them learn, not only will you build a connection with someone you value, you also invest in people that down the road are likely to be valued connections in your career and life.

For me, the main reason to pair is that I just like working with people! Things come up during the day that I find amusing, and I like to crack jokes. That works great if I can make a wisecrack in a second and keep going, but if I’m working alone and have to tap someone on the shoulder and interrupt them…well that’s too much pressure, and I’m just not going to do it. I also run into problems where I get stuck, and I really benefit from having someone else’s eyes and brain working on the problem. Whether they know the answer, or we figure it out together, I’m always in a state where I’m learning and rarely in a state where I’m stuck. If you can practice being in a state of learning rather than being stuck, and do that for a long time, you will be very effective as a programmer. Pair programming is a great way to be in a learning state, and that goes for both people.

The next time you pair, no matter how different your understanding is from another person’s ask yourself: “What can we do together, right now, and what can we learn from it?”

If you enjoyed this, you might love my RubySteps daily learning program. You’ll receive daily code examples with explanations, and one interactive lesson each week that will help you become a better programmer, absolutely free.

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!