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.
Also, see my coding standards document here:
- Understanding is more important than knowledge, donít
confuse the two. The world is full of people educated beyond their
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.
TEST, TEST, TEST and TEST some more. Better you find it than the customer.
And keep in mind during testing, your purpose is to break it, not to make it work.
The change from Programmer to Software Engineer
occurs when it becomes harder to figure out what to program than how to
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.
If you want a good estimate you must have a good specification.
And that works both ways, whether you're giving the estimate or providing the specification.
The best UI in the world can't save software that sucks. But a bad UI can destroy software that does not suck.
Prototype critical pieces and get feedback from
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.