I'm bored today so I desided to update my programming rules, make a 2.1 if you will, I know the smart ones out there never trust a 1.0 anyways... My Rules (2.1):
1. Kludges that we'll fix in the next release never get fixed in the next release... 2. If you dont do it right now, you (or some poor bastard that replaces you) will have to do it right later... 3. It always costs more to do it later... 4. You're not going to have more funding for the next release. (thanks Decius) 5. Beware of anyone in a suit... 6. The man in charge usually didn't get there by being better than everyone else; keep that in mind. 7. If you don't talk to your customers to see what will make them happy, then sooner or later someone else will... 8. Sales guys can be powerful allies for interoffice BS, but if you make yourself too available they will never leave you alone... 9. Management has no idea what the customer wants... 10. Engineering has even less idea what the customer wants... 11. Assume every engineer you work with is an idiot, try not to let
on that you know...if you find engineers that are obviously not idiots, find a way to keep them... 12. Never outsource your core competency... 13. Lazyness and incompetence are contagious... 14. No-one cares if you read wikipedia all day every day if you get your work done on time... 15. If they do care, find another place to work... 16. Your code is not finished until you've tested it... 17. Never assume they have tested their code... 18. Simple regression testing is best done when its automated; its less error prone too. 19. Engineers that think lack of documentation is job security should be fired sooner rather than later (otherwise you'll make them right)... 20. Contrary to popular belief, third party libraries reduce portability of your code... 21. "Cool" is not a business case... 22. Engineerings job is to say yes, no matter how stupid management's requests are...good engineers find ways to say yes that spotlight their intelligence and managements stupidity...(e.g. if they ask you to turn lead into gold, tell them you will if they allocate a few trillian dollars and a fusion reactor)... 23. The night before its due is probably not the best time to start integrating your code in a large project... 24. You can be really good at your job, and a dick, or you can be so so at your job and a really nice guy...you cannot be a dick and bad at your job... 25. Time estimation is really hard...it will take longer than you think it will... 26. Demonstrating that your compeditors suck isn't enough to get anyone to buy your product... 27. Don't ship anything you're not proud of... 28. Your code will be used in ways you never thought of...plan accordingly... 29. If you can't settle on one way of doing something, do it both ways and make it a configurable option... 30. Don't ever have arbitrary limitations, or if you do, hide them better (e.g. "max users 256"...hmmmm?)... 31. Strive to make a really good 1.0, then move on to other, more fun projects...you'll still get all the glory for that first project, but you won't have to do the work anymore... 32. In general, meetings are the opposite of getting things done... 33. An engineering manager's job is to keep his engineers sheltered from politics or any other "real world" consideration, so all they have to think about is coding... 34. Don't ever let your company make you do something you would not be proud of; you may have to work with them now, but you'll have to live with yourself and your reputation for the rest of your life. 35. If your company makes a habbit of asking you to do something you're not proud of, find a new job. 36. If its been done before its boring... 37. Keep your code for work very seporate from your code for play... 38. Anyone that repeatedly declares things impossible should find their way to your kill file... 39. Writing drivers for open source kernels that keep changing their internal APIs like some sick game of musical chairs (read as Linux) should be avoided at all cost... 40. Be carefull how you mix your licenses. Using GPL'ed code everywhere might speed up your startup's time to market, but it could all be for nothing if your code ends up being forced into becoming GPL. 41. Never commit to anything in emails that you're not actually committing to, if you must commit to it over the phone or in person with no witnesses...otherwise learn phrases like "I'll look into that" or "we'll see what we can do"... 42. Don't work any harder than you will be rewarded for... 43. Only listen to the boss that can fire you, the others are just useful for stopping bucks before they hit you... 44. "Working from home" doesn't count against vacation time... 45. Coupling == inevitable nasty rewrite... 46. Try to design things so that likely coding mistakes can't happen (e.g. don't make the length field in a TLV include the size of the TLV header, or some jackass will not account for invalid lengths)... 47. Chances are your customers are not as dumb as you think they are... 48. If you force developers to be more accountable for the bugs they cause, then the bad programmers will spend more time fixing bugs, and less time adding more bad code to the project... 49. Odds are (java|soap|xml|other wiz-bang thingy) won't be as revolutionary as you think it will be...C is still alive and well and not going anywhere...so is COBOL for that matter... 50. In general, "revolutionary" products, arnt... 51. If it can be made non-interopertable, it will be (e.g. IPSEC). 52. RFC's are just a jumping off point to start negotiations; protocols are almost always implimented differently. 53. Don't trust any RFC with updates on April 1st (e.g. IPSEC...jerks)... 54. IEEE specs are worse than RFCs... 55. ITU specs are worse than IEEE specs... 56. Stop using ASN.1 its more trouble than its worth... 57. Comment your code as if you were going to have to pick it up and use it again in 15 years... 58. If you get bored, make your engineers swap code with each other...either you'll get better code out of them, or they'll kill each other...either way it should be fun to watch... 59. If you're made responsible for something (like security) but you are not empowered to make sure it happens, then your real job is to be the person blamed when something goes wrong. 60. No-one notices when you come in early, management always notices when you stay late. 61. If you're supposed to be in the office at 10am and you're going to be late, come in at noon and bring lunch. Everyone will assume you've been there all along and you're just coming back from lunch. You'll get a better parking space too. 62. Open source code is filled with bugs. 63. Closed source code is even more filled with bugs. 64. It doesn't matter how secure your product is if no-one is willing to use it. 65. 1.0 rymes with "oh no!" 66. Any time you use open source code in a project, be prepared to maintain your own branch of that code. You never know when the developers will get bored and leave you hanging. 67. Writing a technical book is way more work than you probably think it is. 68. From time to time every rule must be broken (even some of these), one of the tests of a good engineer is knowing when those times are. What do I mean when I say "do it right"?:
Before I get the replies on this I want to clear something up about what I mean when I talk about doing something the "right" way. Its important to distinguish doing something right, and doing something ideal. Often there is not enough time to impliment the ideal solution, there is always time to impliment a right solution. So what do I mean when I say do it right? Its the difference between a release with all the features you could ever want, all done the way you want, and shipping a release without all the features you want, but none of the code there is going to be a major road block for the next release, and its not going to impose an unreasonable burdon on the user. Doing something right in this game is mostly a matter of process and learning how to avoid problems before they happen and it usually doesn't add any extra time to the schedule. That sounds like something that you should expect from any software release, but getting things done the right way is nearly impossible in many software houses. My programming rules 2.1 | 
