I've been collecting books on business written by former members of the military. For example, there is Business is Combat, written by a former F-15 pilot, and It's Your Ship, written by a former naval officer. There are a few more somewhere in the stack of books on my office floor.

My interest is more than acquisitive though: I've fantasized about writing my own, but applying it to programming. From time to time I take notes on it. I've been moving the same peice of paper onto and off of my desk for a couple years, but I'm going to dump that stuff here and get rid of the paper.

Most of this dreck has to do with leading a group of people, because that's what I do in the Army. If I follow the examples of the other books, I'll have to fill it with lots of meaningful stories of combat and danger.

For now though, my half-baked ideas:

Bypass points of resistance

There's a couple ways I could go with this one, but they both smack of loose cannons. The basic concept is to redefine the problem so the problem doesn't exist. There is a lot of old Soviet army doctrine tied up in this, too. Of course, this didn't work out so well in the latest US war.

Have an SOP

That's "standing operating procedure" to you civilians. You don't have to know it all before you start, but as you go along, make decisions about how you are going to do things, then do things that way. You can change how you do things, but otherwise you should try to do things the same way each time. This lets other people know what to expect and lets you concentrate on the parts of the problem that are unique rather than the parts that are the same.

Lead, follow, or get out of the way

The opposite side of this is "death by committee" where everyone thinks they should get to a chance to speak their mind or get their way. If you're the leader, lead, and if you are not the leader, follow. If you don't like that, get out of the way. Don't be the titular leader who lets people paralyze the project, and don't be the follower who thinks he should get his way every time.

Act, Don't think

Programming probably doesn't require the split-second decisions that more dangerous pursuits require, but it still has a lot of people who want to discuss things ad nauseam. The next time you're in a meeting that lasts longer than 45 minutes, think about how much value all that extra discussion is adding. Leaders have to stop the discussion sometimes, the followers have to realize that they can still say what they want to say, but in the hallways, around the water cooler, or at the local pub.

You never get good intel

Part of not thinking so much comes from the idea that the assumptions you started with are probably crap. It's not your fault. Things are going change, so don't get caught up in the big plan. XP talks a lot about this sort of thing.

Sometimes life sucks...

...and you still have to do the job. Complaining about it doesn't get the job done any sooner, and once you finish you'll have some good stories for the pub.

Learn other jobs

Get to know how other people do their job, and you will start to see why some things happen the way they do. You can sit in your cubicle all day long complaining about the people in accounting or marketing, and they are probably doing the same thing. Different groups of people have to operate under different constraints and conditions, and they have to answer to different bosses. Understanding some of those eases the pain. Be sure to check out the section on "Sometimes life sucks".

Take care of your people

The usual stuff goes here, but along with "Don't try to make everyone happy". People do whatever it is they do for a reason, and they need to move towards whatever goal they have. That may not always be possible, but you should at least know what those personal goals are and how you can help.

Train as you fight

The army says "More sweat in training is less blood in war". I'll really have to work hard to apply this one to programming. I got nothing.

The Creed of the Non-commissioned officer

I won't go into the NCO Creed here (you can find it on Google), but the main point is that you aren't going to make anyone do the job you are supposed to do, and you won't create unnecessary work for others. To paraphrase: My coworkers will have maximum time to do their own job.

Unless someone is shooting at you...

This one is going to be a bit touchy because people are invested in their own notions of urgency. I've pissed off more than a couple bosses by telling them that I'm not too worried because no one is shooting at me and nobody is bleeding. When you start to tense up over a programming bug, step back and get a little perspective. Take a deep breath and control your stress. Unless someone is trying to kill you right then, you can probably relax a bit.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.