Steve’s Programming Axioms

I am a great lover of one-liners, little idioms that convey a lot of meaning. This is a set of those idioms about programming and engineering/design in general that I have developed over the years. Not only do I adhere to these in my own development work, but I also pass them on to people working with me and for me (most often as a requirement in the latter case). Here is a list of the ones I can remember, I've never tried to keep a written list until now so as I remember more, I'll come back and add them. I welcome your comments and input, feel free to contact me. You can find my contact information at http://www.stevemobley.com.

• Understanding is more important than knowledge, don’t confuse the two. The world is full of people educated beyond their intelligence.
• A smart person doesn't necessarily know everything, just where to find it.
• It’s more important to know what you don’t know, than it is to know what you know (as in know when to ask for help).
• You may manage projects, but you lead people. People's best thinking must be given, not taken. Read the book "Multipliers" by Liz Wisemand & Greg Mckeown and be a multiplier!
• It’s more important for the code to be readable than it is for it to work (if you can read it, you can fix it).
• The user is your customer, you should learn to think like them rather than requiring them to think like you.
• It's your responsibility to prove to the user that it works, not the user's responsibility to prove to you that it doesn't.
• The change from Programmer to Software Engineer occurs when it becomes harder to figure out what to program than how to program it.
• If someone has a different opinion than you, it doesn’t mean they’re wrong, it means they might be right.
• Listen twice, speak once ... as in:
  • Seek first to understand, then to be understood (from The Seven Habits of Highly Effective People by Steven R. Covey, good book, read it).
• Object oriented design and programming are real world concepts, you can use them in any language and on any platform.
• Make things that are complex, not complicated. While they may appear complicated from the outside, internally, they should really just be a whole lot of small simple pieces put together in a complex arrangement in order to accomplish a complicated task.
• A team is not a competitive environment, be the best you can without trying to "out do" the others on the team.
• An elephant was really a mouse built by a committee. Have "Guerilla" meetings with key people and avoid getting caught up in long unproductive meetings.
• Come up with multiple solutions then pick the best one, never just implement the first thing that comes to mind.
• A picture is worth a thousand words, draw pictures of your designs to facilitate evaluation.
• Use design reviews, taking time to explain it to someone will often cause you to see things differently. If you work alone, talk to yourself.
• Understand the problem you are trying to solve. If you're trying to drive a nail, you wouldn't be too happy if someone handed you a screw driver.
• Prototype critical pieces and get feedback from potential users.
• If you're looking to advance, you need to not only impress your boss, but also your boss's boss. So attain visibility, but never at the expense of your immediate boss.
• Don't be a "what about me'er". If you are, it's probably the reason you have the opportunity to prove it.
• Don't be a "braggart". If you're really smart, people will be able to tell by your work. If you have to tell people, they won't believe you anyway.
• Everybody thinks they have a good sense of humor, laugh a lot and prove it.
• Most important, my motto in life: It's never too late to have a happy childhood.