mikebernat.com Web-Development, Design, Usability

2008.07.15

One of the most common threads that all programmers share is that of an ego. Some are much worse than others and some have found a way to control or manipulate their ego into a great benefit. Beyond skill-sets and other programming-specific talents I believe the greatest room for personal improvement in programmers as a whole is that of the ego.

The programmer's ego stems directly from the mindset and attitude developed by years of working toward personal-perfection. Becoming a great programmer is a double-edged sword. On the one hand you develop a great analytical mind, seeking perfection in everything they set out to do. This is initially an un-wavering demand placed on amature programmers by the compiler to obey its requirement of perfect syntax. On the other, you begin to apply this attitude towards other people,  including strangers, coworkers, friends, and even family, expecting nothing but perfection. The sooner you realize and work toward a compromise the better off you will be.

A quote by GeraldWeinberg from The Psychology Of Computer Programming.

The idea is that programmers must fight the natural tendency to treat their programs as part of themselves, and therefore to reject all criticism. Rather, they should do their best to treat their designs & implementations as objects independent of themselves, and to view criticism dispassionately on its merits. It's a spiritual discipline that we all fall short of, but that's worth attempting.

How can you tell if you suffer from damaging ego? Beyond the obvious like people calling you a jerk all the time or getting poor peer performance reviews, it may not be completely obvious. Personally, the biggest red-flag is when someone, or even myself, reacts poorly to well-founded criticism. Sure it might not seem well-founded at the time but it is imperative you give everyone their just-due and listen attentively and spend time digesting what has been said. More often than not I will regret not giving myself a moment or two to ponder a piece of criticism and just write it off the second it enters my head.

Some other Symptoms

• Hesitate to submit to peer review
• Do not cope well with criticism
• Produce lots of code, littered with errors
• Negatively affect personal and team dynamics
• Have to be reminded to test
• Confine themselves to their personal cube or office

Criticism

I used to say that spending time testing code I wrote was only admitting to the possibility of personal fault, and that couldn't be possible because everything I wrote was immaculate. Obviously this was meant as a joke but there is a kernel of truth in everything we say. This was rarely the case. I had the idea that somehow believing in myself and my abilities would produce better results. Once you start to doubt and second-guess yourself you get into trouble. Maybe I watched too many Disney movies when I was a kid (or even last weekend - sue me!) but this simply is not the case with programming.

Programming is very much a team-sport. After understanding that it doesn't take much to realize that your code-quality will improve drastically if you simply run things by your coworkers. I'm not suggesting passing the same simple function or method around to 5 people to look at and make modifications to. But from a design perspective before any code is even put into zeros and ones have a couple people take a look at your work-flow and see what they think. In any situation where you are giving the chance to collaborate with others do so because I guarantee you that 9 times out of 10 someone will have an idea that will ATLEAST improve upon your own if not totally replacing it.

The deal is this: when I say something to you about your program, you should listen - listen well, so that you really hear me. If you are all involved in getting insulted because I don't see how glorious you and your code are, we won't be productive.

Arrogance

Arrogance is essential to any programmer. I alluded to this concept before but I would like to emphasize that it is necessary to believe in your style and chosen code-path. Doubting yourself at every corner brings about diminishing returns if you do it to much. Weighing self-doubt and confidence is a balance each programmer must find on their own.If possible, switch on total self-doubt during testing and you're applications will be immaculate.

When dealing with others it is better to talk plainly in facts. Once the facts have been laid out, suggest a different method, making it obvious this is an opinionated suggestion and you are more than willing to discuss the pros/cons. You don't want to insult anyone - remember you're all playing on the same team and want to better each other.

Here are some great examples:

Examples of facts:

• I inspected your code in a debugger and saw an integer overflow, which led to an out-of-bounds array index, which caused the program to crash.
• Fortran can be more easily optimized by modern compilers than C.
• I measured the performance of these two implementations of XYZ, and implementation A is 20% faster.
• Bit-shifting is faster than division on most processors.

Examples of opinions:

• Your program is using 16-bit integers, which are overflowing. You need to increase the size to 32-bits.
• Fortran is better at numerical computations than C.
• Since implementation A is faster, we should use it.
• Bit-shifting is a PrematureOptimization.

It is extremely easy to slip into opinionated-mode so make a personal-note to recognize this. Definitive words like 'need' and 'have' leave little room for learning and understanding and are best avoided.

Guidelines

• Don't simply declare your decision. In most cases, things shouldn't be a decision from any one person. They should be a discussion.
  • Facilitate and encourage discussion by encouraging all to contribute to decisions.
• Don't use put-downs, e.g. "That was the buggiest code I've ever seen." Be clinical when it comes to code that isn't yours. Better: "There were a few bugs."
  • Constantly search for better solutions. Openly discuss innovative solutions. See if they apply elsewhere. Ignore errors - note them to be fixed, but ignore them. They are not part of design (unless you are building an ExceptionManager?).
• Don't assume that someone hasn't already put plenty of thought into something. "Now that we're done with this, let's go back and pick some decent colors for the web page."
  • Acknowledge individual contribution [unless this is very strongly frowned upon in the culture in question, someone I once worked with cited his doing this as one of his biggest faux pas during a period working in Japan - JonHanna?].
• Don't state facts. State opinions, because that is what they really are. Bad: "Nobody puts binary data in a database. It just doesn't make any sense." Better: "I've never had a good reason to put binary data in a database. I've never seen the benefits of it."
  • DO state facts as facts - this design exposes security holes; this other one has several specific advantages; DO state opinions as opinions rather than facts - the design that corrects that problem seems better to me.

Tech Republic has a great article detailing a list of 10 Commandments of Egoless Programming (Originally via Builder.com):

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
3. No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
4. Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
9. Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Critique code instead of people—be kind to the coder, not to the code.As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

Check out the Printable Version at the bottom of their page.

Competition

I am an ultra-competitive person by nature. I can't help it if I like to win or be right all the time, but I am always very aware of this fact and try my best not to let it offend others or even have them aware of this fact until I'm certain it won't damage the relationship. When I tell people I hardly know that I am super competitive I want them to be surprised. Competition in programming is well-founded in some shops and hardly touched on in others.

It's very difficult to introduce competition into the workplace without hurting one's feelings. At the same time some people thrive on it and you can see a very obvious difference in the quality of things they produce simply because they want to be better than someone else. In programming I've heard of something called the 'Wall of Shame' where people would print out and hang up snippets of horrible coding practices for everyone to see. A sort of public humiliation designed to help teach the poor unfortunate victim never to do it again and at the same time teach everyone else who might not already know.

This can be very beneficial but, like I said earlier, difficult to implement without meeting resistance from non-combative, passive-aggressive coworker. It's also possible to really offend some people and in some kind of bizarre extreme case have a lawsuit on your hands (Don't blame me!). It's all about testing the waters around you and determining a system that will benefit everyone.

 

Tell me about what works for you and your work environment.