We have a guest editorial today from Simon Holzman as Steve is out of town.
Like all professions, the official way to do things in the IT industry and the way things are actually done is often different. Most of these differences are unspoken and are due to the distinction between how the world should be and how it really is. Our children are shortchanged by this because they often spend the first few years of their career unlearning the theories that they were taught at school and college.
In practice, this learning experience is probably useful, but I believe that it could be improved by making it more explicit and phrasing it in terms that they will understand better. Even our more experienced colleagues may benefit from putting into words some concepts that they have only practiced instinctively before.
Therefore, I offer you my list of the 10(.5) Commandments (or at least, ‘suggestions’) for IT Professionals (ie Programmers, whatever the official job title is), and I eagerly await suggestions for further tips;
1. Be Lazy. Do it once, do it right and then leave it alone.
2. Be Forgetful. Document everything that you do. Even if you are the person who needs to maintain it, you will have forgotten what you did within 6 months and so you give yourself the notes so that you don't have to re-engineer it.
3. Be Disorganized. Put the documentation in the code. If it is anywhere else, it will not be updated and will probably get lost.
4. Be Stupid. Ask the dumb questions that no-one else wants to ask. Mostly, the answer will be the obvious one, but just occasionally something surprising may be revealed.
5. Make Mistakes. Shhh… It Happens. Everyone makes mistakes. The only people that do not are liars. Assume that you are going to make a mistake and ensure that you have a decent backup or a plan to recover from the mistake. Before you do an update in the database, save a copy of the original data (and check that the saved data is correct). Before you convert to version 1.1 of an application, ensure that you know how to revert back to version 1.0 if there is a problem. And try to find a way to catch your mistakes before your boss is paged because the system has crashed. Test what you plan to do, do it, and then check that the results are correct.
5a. When you make a mistake - STEP AWAY FROM THE KEYBOARD. Like in Politics, it is not usually the mistake that causes the problem, it's the "fix". Take a moment to calm down and think about what has happened, what the impact is, what the options are for fixing it and what order things should be done in. Sometimes, the first thing to do will be to take a backup so that any attempted fixes can be undone if they do not work or so that an older backup can be restored and this backup can be used to identify the work that needs to be redone (You did ensure that this backup did NOT overwrite the previous one, didn't you ?) Usually, there will be a better fix available, but panicking and leaping head first into action is not the way to find the best fix.
6. Avoid Technology. When someone asks you for a technical solution to a problem, check whether there is a manual process that would work instead. Get the manual process working and only then consider automating it. Automating a bad manual system produces a terrible automated system. Automating a good manual system helps everyone.
7. Do not Multi-Task. Very few people can do it well. Get your projects prioritized and work on one at a time. Get it to a clean status (even if not finished) before starting on another one. Otherwise, you end up with 25 half-finished projects... most of them are kinda-sorta working and so your boss will not let you waste time finishing them properly but there are continual issues that need fire-fighting and disrupt everything else.
8. Cheat. Hard-Code the dates of Public Holidays for the next 10 years rather than trying to calculate them, use another piece of code that does 90% of the job, use someone else's code if it does what you need, ask someone else for help if you have questions, look for information on the Net. IT is not about "all my own work", it's about finding solutions. The 1% of people that might gripe about stealing their code are outweighed by the rest of us that are honored by it so long as you give due credit. There may occasionally be genuine Intellectual Property issues involved and, if this is the case, by all means respect the law, but these are rare; the entire industry is founded on a basic premise that we are each standing on the shoulders of our predecessors.
9. Never Test Your Own Work. Of course, you need to test it to ensure that it is functional, but the ‘real’ testing should always be done by someone else… ideally a user. And you should watch what they do, at least for a short time. I once wrote a date input routine that worked perfectly until the user typed in a date using periods instead of slashes. I did not know that this was even possible, but it was much easier for the user on the numeric keypad. Of course, I fixed my code, but I would never have known that this was a problem if I had not been there. The user would have tried using slashes and would have accepted that that was the necessary way to do it. Every test that you do on your own work will include the assumptions that you made when you wrote it. It needs someone else, ideally someone with a different mind-set to yours, to provide a real test.
10. Learn to Type. “a” is not an acceptable name for a variable. Get over it. “Counter” will do if it is used in a clearly defined chunk of code. Functions should be called verb_noun or something similar that gives a clear idea of their purpose. UPPER CASE IS NOT AN ACCEPTABLE FORMATTING STYLE, despite what Fortran devotees might claim. Nor is the use of just lower case despite the lovers of c. Away from your coding, while ee cummings might not bother with punctuation, we are supposed to have enough intelligence to know the difference between a comma and a period. Prove it. In all of your communications, ensure that you appear to be a professional. You will gain respect and people will pay more attention to your suggestions if they look like something worthy of their attention. A professional musician may not need to know how to read music, but the will to learn earns them the respect of their peers. Touch-typing is not needed, but you should be able to hunt and peck at better than 25 words per minute. The Spelling and Grammar Checkers are your friends.
(c) 2006-2014 Simon Holzman
