Karl Martino – 11/6/2001
Following is a list of principals I’ve picked up, during my programming career, that I hope to carry in everything I do.
for a child to understand, and even then I struggle. Being an idiot has forced me to refactor
mercilessly. If I don’t, there’s no chance of me understanding my code. And if I don’t understand
my code, there’s no chance of me getting it to work.
I’ve seen people who can solve complex problems, and I admire them. Alas, I’m not one of them.
So whenever I have to solve a complex problem, I make it simple first.
If I can’t make a problem simple, it’s usually because someone else insists that it remain
complex. In that case, I have to wait for someone smart to fix it (thank you, smart person),
or for someone to change their mind and allow me to make the problem simple. Wayne Conrad
Complex problems are just a series of simpler problems smushed together.
A curious and motivated user with the right tools is unstoppable, except when it comes time to work together. Then a single stinker, a person who wants to stop progress, has a lot of power, if we give it to them. Dave Winer, 2001
Solve problems, don’t just point them out.
from Jesus. And I put them in a book. If you don’t like their rules, whose would you use? Dale Carnegie
Steal ideas liberally from everyone else. Originality is not a virtue. Learn from the past.
appliances of culture. Nietzsche
Put trust in people, not in things.
Don’t build solutions that try to do everything. Nothing can do it all. Instead, create solutions
that play nicely with others, do only a few things, and do them well.
evil. Donald Knuth
single reason – including blind stupidity. W.A. Wulf
Perfectionism can be taken too far. It’s best to get a solution that does most of what you want to do then none
at all. Using a war metaphor – it is better to win the majority of small battles then to wait for one conclusive
battle-to-end-all-battles.
It is best to actively hunt for solutions to problems and not have problems come hunting for you.
Projects must have solid deliverables. Only when goals are can be stated in clear cut terms can they be
achieved. Projects chasing after goals that are not black and white are never successful.
Sometimes you need to do the things that failures do not like to do. Every journey begins with that first
step. And sometimes it is the hardest. Schedule your priorities, not the other way around.
Aways shoot for everyone looking good in the end. Find the good-guys and make sure they each share in
any success. If you can do this with your enemies – then you’ve really done a great thing.
Business projects that aren’t solutions to diagnosed needs are wasteful projects. They are doomed to
failure. Especially true in technology. While technology may expose new capabilities – it is more typically
true that it is business need that should be satisfied by technology – not the other way around.
All of the parts to a solution should cooperate with each other and play nicely with each other by being designed with inputs and outputs that are simple and conscise.
Continuously improve skills and knowledge by seeing what others are doing in the world.
Update: This piece was republished in SOAWorld 10-19-2008.