This is not a bid for world domination, nor a political statement as one would normally associate with the word Manifesto (thanks to Marx and Engels). This is instead a suggested code of conduct for computer programmers.

I'm the Best at What I Do, bub.

While Wolverine from the X-men was good at slashing things to pieces, programmers need to be the best at assembling something from nothing. To that end, you need to believe yourself able to be the best at what you do and strive to be so.

That means not only knowing what you are doing now but continuing to learn and expand your skills, finding new and better ways to do things and creating the best code and products that you can.

Your Mother Doesn't Work Here

Code needs to be clean, organized and readable. This is a highly logical area of the universe and as such it needs to be structured.

Clean as you go. Keep your code structured and easy to read. Take notes, and stay organized. If you're going to do further work on the project or hand the project over to others to continue development you need to make it as easy as possible for them.

Besides, you might need to return to a project at a later date and if it's all thrown together haphazardly you might never find the thread you need to follow and fix. There are no maids or housekeepers in programming.

The Third, Fourth, Fifth, Seventieth Time is a Charm

The quickest way to save yourself time, money and energy is to test early and test often. The sooner you can find that potentially fatal flaw in the code the sooner you can fix it and save yourself hours of poring over thousands of lines of code searching for a misplaced decimal point or a missing semi-colon.

Tearing down a flawed building is far more difficult than inspecting the bricks beforehand. So inspect the 'bricks' of your code and test them before plugging it all together. It's much easier and more efficient to test your code units than it is to debug the entire project after the 'building' has already been erected.

Darwin was a Software Programmer

Everyone knows Charles Darwin's theory of Evolution by now. But change makes people uneasy so many try not to think about it.

As a programmer you must always be thinking about change and the evolution of the code and the project. Nothing in the universe is static and even the requirements of the project can change on the fly.

Even if the project specs stay the same your approach and code will change. Software evolves over time and is never truly complete. But like every good writer knows, at some point it's done.

It will never be perfect, but it will always be changing. Go with the flow and don't fight the evolution of the software.

Crash & Burn Doesn't Mean Death

Going down in flames is every pilot's worst nightmare. But for programmers it should be seen as an opportunity to excel.

You worked hundreds of hours coding your masterpiece only to find that several months after release a major flaw is found and causes massive instability in the program and creates unprecedented levels of crashing.

Relax, find the problem and solve it. It's your code; you can fix it. Once you do, give that patch or update away free. This is a situation where you can show your clients and users how skillful and magnanimous you are, not how greedy or unprofessional. If it's a flaw you should have found, say so, fix it and give it away. Your clients will love you for it.

Users Know Best?

You know what you want to accomplish with your software. But do you know what the users want to accomplish with it? If not then it's time to find out. You might think you are building the best software available but if it doesn't do what the users need, it's useless.

Users use what you create, so they know best what the software needs. Ask them, they won't bite. Well, they usually won't bite. Once you have the list of suggestions find out what's most popular or important and start from there when adding on features and functions.

Beauty is in the Hand of the Creator

Your code might be amazing and a beauty to behold, but the interface needs to be the same. If you're not the most artistically inclined person in the world then you need an artist.

Giving the interface an ergonomic design is of course necessary. But giving it an aesthetically pleasing look and feel may be just as important. You need an artist to make the package look as good as the underlying code. It's not always about doing it all yourself, sometimes you need a helping, artistic hand.

The Right Tool for the Job

Getting an artist for the art makes sense. So why not get a writer for the writing? If you're not an accomplished technical writer then you might not have the necessary skills to write the manual, user guides and other documentation. It's ok, we're not all gifted with words.

Just as you need that artist to make the package pretty you also need a writer to make the documentation readable. So don't be afraid to scream for help, the writers aren't so bad really.

Love Yourself and Your Work

In the end you need to love what you do and who you are. If you don't then your work will reflect it and others will see it. Craftsmen never blame their flaws on their tools, so don’t blame yours on anything other than yourself. If you take the time and care to create something you love others will know it and you'll be far happier in the long run.