Egoless programming, is it possible or even desirable

Question

Is it possible to have egoless programming or is it even desirable?

As a profession we do seem to want to show off the latest gizmo, technique or say “look at this awesome piece of code I’ve written”. Yet we can get very defensive when asked to submit items of work for code reviews or get negative comments from other programmers (hearing the term WTF, has never been a good sign).

Can we as a profession be able to sit down and analyse a piece of code, data or architecture for its merits or constraints and a calm and respectful manner, without causing offense or antagonising our colleagues, or are we just the archetypal Dilbert character, raging against the system?

Answer 1

What you should bear in mind at all times is that for most of your professional life you don't own the code that you write.

If you are an employee the software is owned by the company. If you are a contractor the software is owned by the company. If you are a freelancer then the software is owned by the client. Only if you are the company/client is the software owned by you.

Once you realise this then there's less of the "this is my code" thoughts and attitude. Yes, it still happens and it's only human nature to get upset if someone criticises what you've just produced, but by taking that step to try to remove the attachment it should be less of a blow.

From the other side when you are reviewing the code produced by someone else concentrate on what the code does and how it does it and be constructive when suggesting improvements.

Answer 2

when your focus is on getting it done and getting it right, then it no longer matters whether the solution was your idea or not

at that point, your ego has left the building - and you are much more likely to learn something!

Answer 3

There is a lot of grey area on the confidence - arrogance continuum. I'd rather have someone who takes ownership of their work and strives for excellence based on merit and not self-delusion.

Trust me, you'll write a lot of crap that will fail and you will be to blame, so you may as well take advantage when all goes well.

When I think something is wrong, I say so. Feel free to tell me I'm wrong and be prepared to back it up. It won't be the first or the last time.

If you don't want criticism (Obviously tact and restraint can be exercised.), then write code for your eyes only and run it on your own computer. Anyone who has ever excelled at anything has had to deal with critics.

Answer 4

Yes, egoless programming is quite possible. I've done "maintenance" programming for more than 1/2 my working career, and the second most important thing [1] is to make sure that the next guy can read my code. We have two programmers here at the office [2] who write in such a distinctive style that one can immediately tell who wrote them. We call the little bundles of code and joy that he leaves for us "robstacles."

Some developers feel that the code they write is the result of their sweat and blood, and they get very defensive when questioned (such as during code reviews). Try not to attack them during code reviews and it will become easier in the future to discuss code as the posturing and defensive behaviors will die out.

Notes:
1. The most important thing is to fix the bug or write the feature correctly.
2. Most of these applications have been shipping for more than a decade, so it is quite likely that they will be around long after I am gone.

Answer 5

Yes, I think it is possible. And I think Jeff Atwood explains how to do this best in his blog entry Strong Opinions, Weakly Held.

Answer 6

[imo]

I think this is a fundamentally difficult question, and perhaps sociology, or just using a computer as your main form of communication, has a lot to do with it.

The computer is a tool, and the consciousness that it bears is incredibly beautiful, but you should never try to say that a piece of code is an object of your own creation... every piece of code is a discovery, a pattern that the computer bonds with and can produce a result that you enjoy. The fact that we can discover these patterns iteratively and feel like we are creating is sheer blissful coincidence -- we're good at finding patterns.

We really need to look at computers as windows to discovery, and respect the autonomy of these little brains, even if they are just incredibly small cut-outs from a biological brain. All of math and all of algorithms correspond to an inviolable truth upon which our very cosmos resonates. To declare that part of this is "mine!" (think sea gulls in Finding Nemo) misses so many points on so many levels.

It is hard to step away from this at times, when "laboring" to "devise" a new algorithm, but if you were to think that we are just humble maintainers of these elegantly precise windows into mathematical truth, the definition of the task changes no matter what your goals for your software.

Treat your computer as an equal first, the rest (egoless-ism, peer coordination, goal-oriented behavior) will necessarily follow.

---

Much of my motivation for studying computer science and becoming a programmer was because of this affinity I felt, not toward physical hardware or the thrill of solving problems, but the very fact that I am peering into a brain, a brain I can communicate with directly in my favorite fashion: patterns!

Take a step back and recall why you like the things you like to begin with. Programming can be competitive and I think that fuels a lot of the ego in defending code and design choices, but

a) if someone is a better programmer,

I want to talk to them and learn from them more about this complex relationship to the electric consciousness. We can share discovery, and that is amazing!

b) if my design choices or code could be changed to better suit the organization that I work for

then by all means change it! I am an employee because I need money and I get money when the company gets money, and they get money when the code we use is awesome, not when I want to argue about whitespace or whatever. And as ChrisF points out, you essentially become just a really slow typist in a company setting as far as other laborers can tell. You don't own the code, you don't own the implementation, you are just a medium of translation from idea/paper/specs to electric consciousness brainfood. Translation to and from any pair of languages is an iterative process and you get better with it over time. Criticism accelerates this process and should never be taken personally. But anyway it seems like most agree that you should be egoless, just remember that coding for a company is a job, and you can learn and tinker and play with your code all you want, as long as you keep your bosses and your clients happy.

[/imo]

Answer 7

I think this relates to how you view your code. Good programmers are constantly in the tug of war between viewing the results as "art" and as a "commodity" (or whatever words you want to stick in there).

When we see the code as simply something we're paid to produce, it's pretty easy to avoid ego-related issues.

When viewing the code as "art" we've created, the ego really tries to get in there. After all, what artist produces things they don't like?

So, depending upon your view of your code, you may or may not have emotional attachment to your code. Pay attention to the balancing act, and you'll do well. We want to create code as if it's the highest quality art, but we want to release it as a cheap commodity. Think from the appropriate angle at the proper times and you'll do well.

Answer 8

Ego is simply a sense of self-worth. The effect of emotions related to ego can be both positive and negative.

I will often feel proud (ego gets excited) when I accomplish something that was difficult, or find a clean simple solution to a complex problem, or learn to apply a new methodology to a problem. Which I think is beneficial and gives me a self-sourced motivational kick. The brain is wired to release feel-good chemicals when this happens. You can become success addicted.

There are negative aspects of relying on your ego though, especially in team environments; that can have a counter-productive impact. If you become to attached to some project, or solution, or technology, you will become defensive when it is threatened (by a new solution or technology, or person with ideas). It's important to maintain objectivity, and not take an attack on your solution personally.

I've found the best way to deal with an ego threat, is to humbly attach myself to any new or alternative ideas or solutions.

There's always something new to learn, especially if you consider yourself the expert.