Programmers, Decision Makers, and Egos


Let’s be realistic. Our field is not exactly known for its humbleness. But that’s to be expected when you work in a field that most of the world not only doesn’t understand but, frankly, fears. Think how many people for so long wanted nothing to do with computers, thinking they were some kind of super-beings that could outsmart them. (I’ll stop here before I get myself worked up into an egotistical frenzy.)

So we know we’re good, and we’re proud of our work. But you, as a manager or boss, aren’t interested in egos. You just want the job done, egos or not. And now I’m here to warn you that egos are the very thing that could hurt your software, making it less useable. Therefore, you need to know how to manage egos in addition to managing software projects. In this section I talk about this very issue of egos.

The Kinds of Programmers

In order to understand how to manage programmers (and their egos!), you need to understand the main types of programmers. The types I’m about to describe here are not drawn from a psychology textbook or from a human resources journal. These are the types that I’ve personally observed in my years as a programmer:

  • The ideal, confident, knowledgeable programmer

  • The cowboy programmer

  • The stuntman programmer

  • The unsure, nervous programmer

  • The helpful programmer

  • The overconfident programmer

Not all programmers fall into these groups. But most do. And some programmers fall into more than one group. (For example, a programmer might be both an ideal programmer as well as a helpful programmer—a good mix indeed!)

The Ideal Programmer

The ideal programmer comes to work almost everyday, occasionally gets sick and stays home (I say that for a reason; read on), is understanding of the tasks, and knows her shortcomings and limitations. But in spite of her shortcomings, she knows her resources and how to get help online. She knows where to find answers to her problems. She admits that she doesn’t know everything and that she’s not perfect. She creates good, solid code. She writes to the established coding standards. She finishes the code on time. And she creates highly useable software.

RULE

Every programmer should strive toward being an ideal programmer. But few make it.

The Cowboy Programmer

Next on the list is the cowboy programmer. This is the programmer who locks himself in his office, won’t let anybody talk to him, and just goes and goes. But the problem is he doesn’t always write good code. He might not adhere to the best standards, and his code might have some really hard-to-find bugs. The problem with the cowboy programmer is that he does everything his own way. He’s not a team player, and he doesn’t trust other programmers. He’d just as soon write the whole program himself.

But the real problem with the cowboy programmer is that he usually has the boss (that is, you) fooled. You think he’s the most amazing programmer on the planet. You love him because he works 70 hours per week. He creates an amazing amount of code. But you need to recognize this rule:

RULE

Just because a programmer grinds out piles of code that seems to work doesn’t mean the code is 100 percent correct.

Dealing with a cowboy programmer is a touchy issue. You don’t want to discourage him! He’s working, and he’s working hard and, frankly, doing a pretty darn good job.

Further, he’s probably a serious introvert and really doesn’t want to be forced to play with the other kids. Instead, let him be. But, for your own protection, you need to do the following:

  • Keep tabs on him and make sure he’s staying on task. While they aren’t likely to spend hours playing Tetris, some cowboy programmers might spend hours adding a cool new feature they think is necessary but is not part of the plan. Of course, staying on task includes making sure he’s staying on track with the design documents, as well.

  • Make sure he stays healthy and gets some food on occasion. Seriously! These people sometimes starve themselves quite by accident. (I don’t personally have that problem. I like food too much, as my scale would attest.)

  • Perform regular reviews on his code. (Don’t wait until the end! This guy’s cranking out lots of code!)

  • Make sure the code is to the company standards. This is a problem, because a lot of cowboy programmers don’t particularly like coding standards.

The code review is vital here. You need to watch this guy’s code because it may be great, but, more likely, it’ll have a few errors here and there. (Not many, but a few.) If you have some ideal programmers, make sure they go through the code very carefully during the review.

Now with the coding standards, the problem with the cowboy programmer is that he tends to scoff at various standards. Therefore, one thing that can help you is to do a special code review very early on. Make sure the cowboy is creating the expected classes and member functions and sticking to them. Cowboy programmers have a tendency to write a lot of hack functions to work around (rather than through) a problem. By this regard, a lot of cowboy programmers tend not to be the best engineers.

For example, left to their own devices, they might write a gazillion lines of code swarming through a million functions. But toward the end, they realize that three of the functions don’t work correctly. While the problem really occurred during the initial phases of the coding, it’s now too late to go back and fix it. So they’ll write 10 other special-purpose functions to aid the faulty functions.

They’ll do this quickly and get it out the door, and it will work. For the most part. But every once in awhile, the code might break, showing some bizarre protection fault that nobody can seem to reproduce. The bug is probably a needle of code in a giant, moon-sized haystack. But the real problem is in the whole layout and design of the code, the bigger picture. The design is wrong. And that’s what you need to catch. And worse, most managers and bosses are often unaware of this kind of problem.

Most managers and bosses simply see tons of code that, frankly, works. How could it be wrong? But it is wrong:

RULE

Creating software is more than just grinding out code that works most of the time. Creating software is about engineering a product from start to finish using sound design principles.

But as I said, don’t discourage the cowboy programmer! He really is doing a good job. You just need to keep tabs on him. And the cool thing about the cowboy programmer is he’s usually quite humble. Therefore, if you go through his code and find some problems, he probably won’t mind at all. He’ll be happy to go through and fix them. Cowboy programmers are easy to work with. They wrote the majority of the code during the dot-com revolution of the 1990s, and they aren’t necessarily a bad thing.

The Stuntman Programmer

The stuntman programmer is the one who writes obfuscated code that is impossible to read and impossible to maintain. Such programmers often work very quickly and are exceedingly confident of their work.

While their code may be good (it’s very hard to tell), you really can’t have this kind of work in your project. Why would you want code that other programmers are unable to read and maintain? And if the code has a bug in it, tracing through the code can be a nightmare.

But the fundamental problem with such code is the question of who can decide whether such code is legitimate code or stuntman code. The code, of course, will be perfectly readable to the programmer who created it, and perhaps most of the other programmers just aren’t “good enough” to understand it. But suggesting that other programmers aren’t good enough to understand it is itself a clue to trouble:

RULE

Code should be so well written, well commented, and clear that most programmers can understand and follow it. If not, the code must be rewritten.

Stuntman programmers can be difficult because you may have no choice but to deal with them directly. Code reviews are a start: If the other programmers find the code overly complex, then the issue must be addressed ASAP. But the problem is now you’re dealing with an ego. This is one instance where you’ll simply have to be firm. Your organization simply cannot afford to have stuntman code in its software. I’m not about to offer advice on personality and human resources issues, but you do need to stop stuntman programming.

The Unsure, Nervous Programmer

Most people who don’t work in the programming group will agree that these programmers— the unsure, nervous programmers—are some of the nicest people in the whole bunch. They don’t have inflated egos, and they tend to be chatty and personable.

Such people also usually aren’t very good programmers, and they know it. They’re constantly asking for the help of the other programmers, which makes them a bit of a thorn in the sides of the other programmers. (The overconfident programmers tend to despise the unsure, nervous programmers.)

And these programmers, unfortunately, can also be a thorn in the side of the software itself. Bosses usually like these programmers and want to help them succeed and do well. The bosses will then give the programmers some pretty hefty duties that might be a bit out of their reach. But the unsure programmers usually work very hard and are willing to spend a lot of hours on their work. That’s a good thing.

I have three suggestions for dealing with unsure, nervous programmers:

  • Keep sending them to training courses.

  • Assign them a mentor.

  • Find somebody who can teach them how to use online help and other online resources for quickly finding answers.

One of the real differences between the unsure programmer and the ideal programmer is that the ideal programmer has discovered how to quickly find answers to her questions without automatically asking somebody else for help. The unsure programmer isn’t necessarily less intelligent or less capable; rather, it’s an issue of confidence. Teach the unsure programmer how to find answers for herself, and she will gain confidence and likely do very well.

However, as with any other programmer, you need to do code reviews and watch the unsure programmers. The fact is, they tend to not be very good programmers (at least not yet; they’re still learning). And so you need to watch their code closely. Otherwise, other programmers will end up fixing the unsure programmers’ bugs, resulting in frustration and other personality issues.

The Helpful Programmer

The helpful programmer is the one the unsure programmer runs to when she needs help. The helpful programmer is friendly and easy to get along with (just like the unsure programmer) and is usually willing to help the unsure programmer.

But helpful programmers have their own set of problems, relating more to human interaction and less to coding. The helpful programmers can easily get bogged down spending so much time helping everybody that they aren’t able to get to their own work.

I tend to carry the role of the helpful programmer, and I know firsthand that it can be frustrating at times to have everybody running to me for help. I enjoy helping people (that’s why I teach and write as well as program), but at the same time I occasionally need to put up the Do not disturb sign.

One possibility for handling helpful programmers is to divide up their time and officially make them a mentor, giving them a reduced programming load. Most development groups can stand for a mentor or two, and the helpful programmers are ideal for this role.

But be careful with helpful programmers: Just because they can explain things well and are friendly doesn’t necessarily mean they’re always right. They need code reviews just as much as anybody else, and so do the people they are helping.

The Overconfident Programmer

Of all the programmers in the list, this programmer is the most difficult to deal with. This is the programmer who tends to be extremely arrogant and unwilling to work with other people. This is, in essence, the stereotypical computer guy whom laypeople don’t like dealing with.

Since I’m not writing a psychology book here, I won’t even begin to try to understand what kinds of issues cause people to become this way. But the overconfident programmer can be detrimental to the entire project. The reason is the overconfident programmer will tend to take on more work than he can handle, will grind out an enormous amount of code, and will bully people around into thinking he’s always right, that his code is perfect, and that he knows best. Yet, he’s not perfect, and he will have bugs but will probably refuse to allow others to help fix them. (He may even resist a code review.)

Some other programmers even reach the point where they are afraid of the overconfident programmer. And worse, this programmer might actually drive away some of the ideal programmers, and they will seek work elsewhere.

Now I’m probably stereotyping a bit here, but the truth is, every single place I’ve worked has had at least a couple of people who fit this description. And worse, the overconfident programmer’s work rarely is that much better than the other programmers. Some are good, and some are very good programmers. (But those really good ones still need code reviews, because nobody is perfect.) Others aren’t good, and the ideal programmers know it but have trouble convincing you, the boss, of the truth.

How do you deal with an overconfident programmer? One good way is by resisting your urges to give him too much authority. You, as the boss, may easily start to feel like he really is the superhuman he wants you to think he is, and you will seriously consider promoting him and putting him in charge of huge amounts of work. He’s demonstrated to you that he is good, after all, right?

But promoting him has an inherent problem: If you promote him and put him in charge of a team, why is he still spending all his time grinding out code? Because at heart, he really doesn’t want to be in charge of a team. He wants to write code.

Let him be a coder. And if he really wants to move up the ladder, send him to some manager training programs, and then let him decide what he wants to do. If he still wants to be promoted, let him know that a promotion will mean spending less time coding. Is he okay with that? If so, go for it, provided he’s had the appropriate managerial training.

I don’t want to be too hard on these people, but I want you, as a boss, to fully understand what is happening. So here goes:

SUGGESTION

My personal experience is that the overconfident programmers are responsible for the majority of the kinds of bugs that result in software crashes. Therefore, be aware of who the overconfident programmers are and have plenty of reviews of their code.

Finally, try to get the input of the ideal programmers. You know who the ideal programmers are. You can recognize them because they do a great job, and they don’t bully people around. Let the ideal programmers watch over the overconfident programmers. You will probably be surprised to learn that the overconfident programmers aren’t always the superhumans you thought they were.

start sidebar
Avoiding Letting One Great Programmer Rule the Ship

I don’t know if this really happened, but sometime back I heard a story from a coworker about a guy who was the top programmer at a company. (However, he was also the overconfident programmer who bullied everybody around.) The company had a tight deadline, and one day the programmer walked into the boss’s office and said, “You know I’m the only one who can do this work. And if I quit, your product will never make it out the door. So double my salary or I’ll quit.” The company felt stuck, so they doubled the guy’s salary. Then the moment the project was over, they fired him.

Never, ever, ever let your company get into this situation. This company made a major mistake in letting the organization get to the point where only one guy knew how to complete the project. Because the fact is, nobody is irreplaceable. What if the programmer quit anyway? Then what would the company do?

If you have only one programmer who knows the majority of the system, then you must invest some time in bringing other programmers up to speed. Most programming shops have one person who seems to be the head programmer who all the other programmers look up to. Try to dispel this situation. Involve the other programmers in high-level meetings. Assign important work to the other programmers. And try to spread out the knowledge more evenly among the programmers.

The fact is, the one programmer may be smarter or more experienced than the others. But that doesn’t mean the others are incapable. And further, that doesn’t mean you can’t hire more programmers who are as sharp as the main programmer. Because if you have one programmer ruling the ship, then you have an extremely volatile situation that could mean the end of your organization.

If I were the boss who had the guy come up to me and demand a double salary, I would have told him to forget it and get back to work and to remember that he has bills to pay and had best not risk being fired.

end sidebar

Remember, you are trying to build a successful business by selling highly useable software. If you’re going to allow the overconfident programmers to have too much authority because you mistakenly thought they were better than they are, you will greatly risk releasing software that isn’t nearly as good as it could be.

Checks and Balances

A large software product is a highly complex machine. Think about this: A rotary car engine (found in, for example, Mazda RX-7 and the recent RX-8 cars) has only a few moving parts. With only a few moving parts, not many states are possible. This means less complexity and fewer breakdowns. (In case you’re curious, even though many people have shown that the rotary engine is superior in many ways to the traditional piston engine, the reason why it isn’t used in many cars is that the rotary engine is extremely difficult to build to various emissions standards.)

In general, the more states a machine has, the more complex it is, and the harder it is to maintain. Now look at how many states your program has: a whole lot. Your software is incredibly complex. But not only is the software complex, so is the code.

For this complexity reason, you absolutely must perform code reviews. You cannot risk letting problems slip through that would have otherwise been caught by a code review. And even the best programmers can make mistakes. As the old saying goes, two eyes are better than one. (Or, in the case of bespectacled programmers like me, eight eyes are better than four.)

Good code reviews serve as a system of checks and balances. Most governments have recognized that no matter how good people are, mistakes can be made. And therefore such governments have implemented a system of checks and balances. And you can benefit from also recognizing that nobody is perfect by implementing a code review.

But you can implement other checks and balances. In addition to the obvious one of having a quality assurance groups, you can ask that all your programmers constantly be on the lookout for problems in the software, even when it’s not related to their own part. (Remind them that they are, after all, a team.) And teach them how to post bug reports. (I’m serious—a lot of programmers honestly don’t know how to post bug reports, because they don’t think it’s their job to do so! If you start watching the behavior of your programmers, you might be surprised!)

Another way of performing checks and balances is to periodically rotate the programmers, working in different areas of the code. Now, in theory, I suppose swapping programmers around when they’re in the middle of writing their code might be an interesting experiment, but frankly, I wouldn’t try it. You could end up with a mess. Instead, swap programmers as they finish up sections of code.

Also, if you have ideal programmers, I would suggest letting them do code maintenance and bug fixing on somebody else’s code. I’ve had exceptionally good luck in such areas, because they are usually good at tracking down other problems. (The overconfident programmers are sometimes good at this too, although they might get angry at the mistakes they see.)

Placing New Hires

Be careful with new hires. A lot of programmers for some reason have the impression that they’re being brought into a complete disaster and they are the last hope to valiantly save the ship. Yet, you, as the manager, know this just isn’t true.

Such an ego trip can have a detrimental effect on the usability of your software. The problem is that the new hires will likely have a lot of ambition and will grind out an enormous amount of code. However, this new code:

  • Might not interface well with the other code in the project.

  • Might not be up to the company’s coding standards.

  • Might display a user interface that is not consistent with the rest of the product or is simply difficult to use.

None of these are necessarily the result of a bad programmer. So please don’t just assume the person lied about his qualifications. Rather, it’s a simple matter of a good programmer working in a new company. This is where providing a mentor is a good thing:

SUGGESTION

Team up the new hire with a programmer who has been around awhile. Make sure both people realize that neither is the boss over the other.

But what do you do if the new hire immediately begins criticizing everything left and right, saying what a mess everything is and how she clearly knows of a better way to do all this? (I’ve seen this happen more times than I would prefer, and you probably have, too).

Such a situation is a touchy one at best. You don’t want to knock the person down and criticize her, making her hate the new job. But you also don’t want her to run rampant, convincing everybody else how bad everything is. What you want is for the new programmer to write some good, solid code and to be happy with her job.

I’m not a human resources expert, and the purpose of this book is usability. However, the impact such HR problems can have on usability is extremely high. As a manager, one thing that I’ve found that works is to sit down with the new programmer and take her through the architectural documents. Give her copies of them, and let her read them in their entirety. This will give her a better idea of the decisions you made before she came around. And it should help her respect your decisions. And besides helping her fit in and not criticize your work, you’ll have the added benefit that now she’ll have a much better understanding of the entire project.

But what about the code the new programmer writes? You don’t want to watch over the programmer’s shoulders. That would likely irritate her. Instead, go back to the tried-and-tested code review concept:

RULE

Code reviews are especially important for new hires, since they don’t yet fully understand the full architecture of your system.

I can’t tell you how many times I’ve seen a new programmer dive in and start writing a lot of code (which surely impresses the bosses!) yet is developing code that doesn’t necessarily work correctly. The code may appear to work from the GUI perspective, but underneath there may be numerous errors.

Of course, code reviews are important for more than just the code written by the new hire. Everybody needs code reviews. Another problem I’ve seen a great deal is where the senior-most programmer cranks out some code that everybody assumes is perfect but is far from it.

He Said, She Said

Sooner or later you’re going to be faced with the issue of two programmers telling you conflicting things. One wants to design the code one way; the other wants a different way. What do you do?

This is an extremely difficult situation to be in. They can’t both be right. So look more closely at the situation. When you look deeply into the problem, you will likely see that it’s not just a matter of he said/she said. Instead, you’ll see that one programmer is a more senior-level programmer, and the other is slightly less senior and may well have a valid concern. The senior one may be a star programmer in the company, or a team leader, and has a lot of respect from the company. If so, don’t automatically assume the star, senior programmer is right.

I can’t speak for all situations, but the situation I’ve encountered the most often is that the star programmer wants to do something one way, and somebody else who is not the star programmer sees something wrong with the star programmer’s solution. In effect, the star programmer is really the overconfident programmer and is now defending his decisions.

RULE

Listen to what the other programmer says. The other programmer may well have a valid point, so don’t automatically discount it. The usability of your software may be at stake!

Regardless of whether somebody is more senior than the other, you might consider having each programmer write up some quick test code to demonstrate his or her respective assertion. Then you might have some other programmers review the test code and come to a decision about which is best. You, after all, are the boss. As much as you might not want to admit it, you might not have the technical knowledge to make a sound decision in this matter. And that’s why you don’t want to just automatically assume one person is right.

Remember:

RULE

Your job may be partly to help out during personnel disputes, but your ultimate job is to build highly useable software.

Making a Decision, and Staying Up-To-Date

As a manager, you need to be aware of something your programmers are doing: They are making arbitrary decisions. For example, your programmer who is writing the part of the software that opens the files may well have put in an arbitrary limit on how many files your software can have open. Is that a good thing? No! And don’t let your programmers tell you it’s the only way possible. Remind them of this topic: dynamic memory allocation. Or this one: container classes.

Too often programmers make arbitrary decisions as they are coding. They might arbitrarily decide how much memory something should have or hold, or how big a data structure should be, or how many times a function should be called, and so on. These decisions may then make their way into the general feature set of the product without anybody realizing it. And will the decisions be mentioned in the product documentation? Will the users be aware of them? Most likely not.

What do you do about arbitrary decisions? For starters, you can have your programmers read this book. If they do, they will then understand how such arbitrary decisions impact the usability of the product. Further, you can instruct all of the people attending code reviews to be on the lookout for arbitrary decisions. And the best way to handle such decisions during the code review is for the reviewers to ask, “Why did you do this?” Perhaps the programmer had a good reason. But perhaps not. It’s best to ask. And if the decision was arbitrary, have the programmer go back and look at the design documents and make sure the decision was what was expected. And if not, change it. (And, of course, this means you must have design documents!)




Designing Highly Useable Software
Designing Highly Useable Software
ISBN: 0782143016
EAN: 2147483647
Year: 2003
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net