We developers are a peculiar breed. In a way, I like to compare us to mad scientists—you know, the guys in movies huddled over glass beakers, trying to find the right mixture of red and green ooze to make a bizarre invention that goes horribly wrong.

Okay, maybe not quite that crazy, but we’re quite passionate about what we do. We love creating things. Building useful applications that people value brings a lot of fulfillment to a job that has us spending most of our time staring at a computer screen, and where we place ourselves at risk of carpal tunnels or mild obesity.

But back to the mad scientist bit. We spend a lot of time agonizing over peculiarities, trying to find the right mixture, formula, algorithm, or animation sequence. Who else but a developer would stay up till 2 a.m. working on the right formula for determining non-overlapping space between a masked loaded image and its container?

Since we tend to be very focused and isolated, we’re often seen as being introverts. Many of us are the stereotypical office geek—somewhat socially backward but brilliant, yet at times diva-ish. Unfortunately, some of our natural tendencies as developers can hinder our progress. I’m going to spend some time exploring what a character in TRON:Legacy calls the “art of the selfless,” or “removing oneself from the equation.” I believe that there are a few key ways that will help us to be the brilliant mad scientists we were meant to be, but also see the bigger picture and make our organizations better for it.

Leave Ego at the Door

One of the hardest steps to take towards being selfless in development is to not let yourself get in the way of making your apps better. You put a little of yourself into everything you make, but it’s extremely important to not let your infatuation with your first build lead you to viciously defend it like some kind of maternal nesting animal.

The first step towards becoming more selfless in development is to forget your ego and remember your purpose: to build applications that solve problems and do what they were meant to do. Everything else will ultimately be an extension of this concept.

The way you respond to criticism and feedback is a good gauge of how closely you cling to your ego. When people can’t figure out basic features or functionality of your application, it’s easy to get frustrated having to explain why you built something the way you did. Ego can get in the way here; many developers take on a condescending role as they explain simple functionality to “lesser” life forms. The important thing to remember here is that if those close to you (coworkers, friends, bosses, etc.) can’t figure out how to use your application, chances are the end user will have an even more difficult time. Learn to take any and all feedback gratefully and respectfully; you need to foster an environment where criticism is a positive thing, another chip off the stone block that will one day become a masterpiece sculpture.

Another indicator of whether ego is getting in the way is how much you resist change. When new features are required or new technology is mandated, the easiest but least helpful reaction is to search for reasons why these changes aren’t as critical as everyone seems to think they are.

Finally, remember the hard truth that you have an extremely limited perspective as a developer. As much as you might think you can place yourself in the shoes of your users, it’s extremely difficult. In fact, it’s impossible. There are companies and job titles dedicated solely to figuring out what users are thinking. That’s not really your job, but realizing that you don’t have all the information is a step towards taking yourself out of the way of progress.

Learn Some New Languages

Have you ever noticed how marketing and sales folk seem to speak almost entirely in buzzwords? Yes, it can grate on the nerves, but there’s something very helpful you can do to become a greater aid to your organization: figure out what they’re talking about. You need to learn some new languages in your company. Realize that the language of engineers or programmers often sounds like dreadfully boring and nonsensical acronyms to folks not familiar with the difference between a bit and a byte, just as marketing buzzwords may sound silly and unimportant to you.

When you’re ready, start with these same marketing and sales people. They have to understand your applications in order to turn technology into revenue, the lifeblood of any organization. It’s easy to see yourself as the guy in the trenches, doing all the hard work. But if you think a little more about it, coexistence with sales and marketing is absolutely critical. You don’t have a job without marketing and sales, and they can’t make a living without you. The more you understand what’s important to marketers and salespeople, what drives sales, and what strategies your organization is using to reach customers, the better perspective you’ll have when building the app that will be so critical for their success.

Just as important is the language of your customers. One of the most humbling and yet potentially enlightening experiences for a developer is to see a real customer, in the flesh, using your application. Unfortunately, for most of us this is a near impossibility, but here’s where another language becomes so important: the language of customer data. Integrate analytics strategies into your application, and then learn to read the metrics so you can make important connections between how you intended the app to be used versus the reality of actual use. When you get good enough at this analysis, you may be able to get just as much, if not more, information from the data than you would watching a live customer using your software.

“Your Product Sucks”

I was having lunch with a very successful business founder the other day, someone who has a knack for cutting through bull and getting straight to the core of things. He talked about his software company and the first version of the product they built, as well the response they got from their first pitches to potential customers: “Your product sucks.” Instead of shuffling back to their basement office with tails between their legs, they found opportunities to better their product. When the next version of the product got a similar response, they learned from it and made it better. Their motto became “embrace your suckiness.” Eventually they became a software company that makes stuff that doesn’t suck. Quite the opposite, in fact.

So, don’t be afraid to embrace your app’s suckiness. In fact, relish opportunities to find out exactly where your app falls short. If you get good at that, you’ll become a more potent developer, someone who can iterate faster and ultimately is successful quicker. It’s essential to find failures fast, readjust, course correct, and go forward even more boldly than before.

On to Developer Zen

Remember, finally, that lots of people can be brilliant at development. But becoming a selfless developer, one who sees from his own perspective as well as the organization’s, one who feeds off of criticisms and is always improving and iterating—this developer will help row his or her ship towards success as an organization and fulfillment as a developer. Removing yourself from the equation is a liberating experience. You empower yourself to see beyond the lens of developer and out on the horizon of truly successful development. Plus, you might make a few friends along the way.

Add new comment


Great article. I completely concur. One tip for making it easier to "Leave your ego at the door" is to "show it before you build it". I find it much more productive to discuss and get buy-in on a prototype first. It is much easier to not get defensive about a prototype that I spent a few hours on than it is a design/implementation that I've spent a few weeks on.

Printed. Pinned on cube wall. I speak marketingeese and I'm still guilty occasionally often.

Not all developers talk in code. I've always tried to speak in plain English even if I'm talking with other developers.

It goes beyond jargon, though. Some people are unable to understand a concept unless you can give them a visual example. Building a simple prototype, or explaining a new feature with the help of a simple design, can be a lot easier to sell to colleagues or clients.

Perhaps this sounds obvious. I've found that it's hard to resist saying "what if we added this?" to an existing system without providing a decent visual example.

As an additional tip, I've found that you can learn a lot more in a small company - especially if you're not in a large team of developers. Working as the only developer, or one of a very small team, can make a huge difference to your experience. In larger companies, developers are often isolated from "the business", so can slip into tech-speak all too easily.

Useful blog. And not only for designers, but for a lot of other professions too. :)

Thanks for a good post... The art of being selfless is something to strive for for everyone involved in UX. All too often I've come across UX designers with egos bigger than the eiffel tower and a complete lack of empathy or interest in the end user. Totally inappropriate when in the business of making stuff that works for REAL people

Thank you UXMAG!
it was a nice read on easy friday.
Selfless mode is a life long art. hmmm!