Pivoting yourself

In the startup world, it’s common to talk about “pivoting” a business; that is to say, taking what you are doing and refocusing on some aspect of the opportunity you hadn’t spent a lot of time on before. We aren’t all founders, though.

Today, coders have a lot of options when it comes to what they work on, but the golden ticket that companies like Github, Facebook, etc, offer, is the opportunity to work on something you use yourself. Working on your own tools, scratching your own itch, is the magic cheat sauce for motivation – it’s what compelled me to work long hours on Boards.ie and not mind being on call 24/7. It’s what compels open source authors to do what they do, and drags lots of hopefuls into the meatgrinder of the game development industry.

The obvious problem, of course, is that there aren’t a lot of these jobs to go around; certainly not well paid, or without crazy hours. Doing what you love might require starting a company. I think this is a huge missed opportunity for a lot of developers – they create their own career “filter bubble,” excluding themselves from potentially valuable opportunities, stuff they might love if they gave it half a chance.

I recently received a lovely and unexpected compliment at a friend’s barbecue. I was chatting with him while he cooked, and went to put my mug down on the side table of the barbecue; I thought, “this is an awkward place to put this mug if he needs to stick a plate there or something,” so quickly moved it off elsewhere. This wouldn’t have been a notable interaction other than that he then observed, “you know this is why you’re great – you’re considerate. Other people wouldn’t have given that a second thought; you realized I’d need to use that space.”

For me, this sort of crystalized how I approach software development. I’m deeply reliant on the concept of putting myself in another person’s position. It’s not exactly an engineering approach, which I would see as more detached, falsifiable, professional; something I constantly strive for and only ever seem to have moderate success with.

I have to believe in what I’m doing. This can be viewed as both a strength and a weakness; a strength because it empowers me to reason about the software I’m building in a very natural way, a weakness because it means that when I can’t find that internal motivation, I’m like a ship without a compass; I become lethargic, or worse, feckless. Building a product you don’t understand is fine if someone else understands it and can communicate that effectively, but it’s crazy if nobody understands.

Putting myself in someone else’s position is not always as simple as being a conscientious barbecue guest. Sometimes it requires a lot of hard work, a lot of talking, a lot of banging my head against the wall. I think that’s how it works for most people; if you don’t have the problem yourself, you have trouble grasping the requirements of the solution. In software, this can mean the developer forcing their incomplete interpretation of the problem on to the solution, or just not solving the problem at all, exasperating everyone involved.

If you can acquire the patience and empathy to understand other people’s problems, you unlock the master key for your career as a software developer. Most of the software development community’s attention is clustered around this 1-5% of jobs that happen to align with our collective interests, but there’s a whole world of opportunity dying for attention in the other 95%.

Make other people’s problems your problems.