The Programmer's 10 commandments.

The Programmer's 10 commandments.

I found very valuable words and just want to share all of you members. I am convinced that any programmer that practice these will make a success of their career.

1. Know more than you “need” to know.

Knowing a programming language and being able to program in it is not enough. In today's IT industry it is hardly enough to qualify you for doing a few loose projects at home.

You are working on a computer, that computer has both hardware and software components. You need to have a working knowledge and understanding of both. It is highly unlikely that you'll be working on a stand-alone computer, so you also need to know at least the basics of networking.

So, when will you know enough? The answer is simple... NEVER!

2. Learn at least one new thing every day!

Every successful programmer I've ever met, has made learning new things on a daily basis an art form.

The IT industry moves at a ridiculous pace, make peace with the fact that you will never catch up with the current scene of all the available technologies. Be aware of the fact, that if you do not learn new things regularly, you will be useless outside your current place of work within 18 months.

3. Getting it to work is NOT ENOUGH!

Take pride in what you do. Honestly, just because you finally got your program working, does not mean it is done. Clean up your code, comment it where needed and test the damn thing thoroughly.

4. Consider those that come after you.

Think of the guy that has to maintain your code, as a homicidal psychopath, that knows where you live. Write your code in a way that would make sure he never gets the urge to seek you out.

Too many programmers write their code in a way understandable to nobody other than themselves and the compiler or translator they happen to be using at the time. Don't be one of them and when you find one, bang them over the head with a clue-bat.

Download some source code from a reputable open source project and look at it, compare what you produce to it and you'll quickly find where you can improve.

5. Document what you do.

With applications like Javadoc and doxygen, there are no more excuses.
If you don't document your applications you cannot, by the biggest stretch of the imagination, call yourself a programmer. At best, you are a glorified typist.

6. Follow, respect and take responsibility for the development process.

The development process from requirement gathering, through testing, deployment and maintenance. Has been developed by those you are now learning from. They had to learn it from the school of hard knocks.

Respect this experience and use their knowledge.

So when exactly are you done?
Only once the application is deployed, running and requires no more changes, can you say you are done. Before you reach that point, you cannot factually state that you have finished your work.

7. Respect your peers.

Throughout your career you will be working with many other programmers, developers, software engineers etc. etc. etc.

You might reach a point where you are factually the most experienced or trained individual on a team. This is when you need to be doubly careful. Do not allow yourself to become arrogant.

In years gone by, it was possible for a single programmer to see to an employer’s needs. These days, if you want to progress beyond “Hallow world”, you'll have to learn how to work with others.

Nobody likes an arrogant SOB, no matter how good he is. This will eventually lead to that individual's downfall.

The IT industry is one of the few where a good reputation can get you far beyond the level of your formal education. A bad reputation on the other hand, will see you getting stuck at the bottom of the pile, regardless of how many degrees or certificates you spam your CV with.

8. Respect the user.

Yes, there will be times when you think the user is the most irritating, uneducated, short sited being produced by this universe, for the sole purpose of making your life hell.

I've found, that when you respect the user, listen to their opinions and grievances while taking action to improve their lives. You invariably end up with someone that will listen to you and take your advice.

Over the short term, this could take a lot of work and effort. But over the span of a career, those users are the best references you can possibly gather. They are the ones that will tell your future employer that they are absolutely devastated at seeing you leave and that they don't understand why your current employer can't make a plan to keep you.

9. Demand the best of yourself.

Do what you have to, check it, improve it, check it again, read some relevant material on what you have to do, check it again, test it to death, clean up your code, test it again, do your documentation and... Test it again.

Even after you have done this, you can be sure there is at least one more thing to do. Find it and do it.

Do all of the above to the best of your ability.

10. Demand the best from your peers.

You will never survive if you are the only one doing all the things needed in order to make sure your product is a good one.

Your peers share responsibility with you, if they are not doing their best it will come back to bite you when you least expect it. Do not tolerate incompetence, but also help and educate where needed.

Optimize variable names for maximum clarity, not minimum typing.

It’s OK to make mistakes. The only thing that isn’t OK is to not learn from them.

Don’t leave code commented out unless it’s clearly explained.

Approach each piece of code you write like its final finished code. Don’t leave loose ends to clean up later because you’ll never have time to clean them up.{even you are creating the sample application}

Never code an algorithm that you know won’t work in the final product either because it won’t scale, run fast enough, or will have a rare failure case.

All successful products have a life longer than you can conceive. Files and processors will grow by factors of 10,000 – make sure your design can accommodate change {think for all possible areas before doing the code}.

Don’t code the first algorithm that comes to mind. Try to examine all possible approaches and choose the best. Best way to get someone to review your approach before coding {Always discuss your approach with in your team}.

Don’t put band aids on bad code, rewrite it. At first is seems hard, but after you’ve done it a while you’ll find successive rewrites go much faster than you thought.

When you work on someone else’s code, don’t leave it in worse shape than it came to you. Ask the original author to review your change.

No bug is impossible to fix.

Get to be good friends with a programmer, designer, or writer who’s better than you.

Get assumptions verified and do not be afraid to point out gaps in management or sponsor thinking. Do this tastefully, but do it before trying to implement a failed plan. We have the sole responsibility for solution quality or relevance. Realize what is needed is not always exactly what is asked for. Try to return people to pure business requirements if the document, email or post-it you have is too specific or generally too confusing to be understood. Be a bother in the short term to be an asset in the long term.