Mike Lynn posted an updated version of his previously posted programming rules. It's a good list. Read it over. Obey.

Mike Lynn posted an updated version of his previously posted programming rules. It's a good list. Read it over. Obey.

Hear hear... these are good stuff, as expected (even if the pedant in me is calling out for a spell check ;)...

k wrote:

Mike Lynn posted an updated version of his previously posted programming rules. It's a good list. Read it over. Obey.

Hear hear... these are good stuff, as expected (even if the pedant in me is calling out for a spell check ;)...

did you notice that it wasnt a 2.0 ;), I already had some fixes of the sort, I'm keeping the list offline now so I'll run spell check one of these days, I desided to do that next release, I'll definately have time next release, trust me...

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 configur... [ Read More (0.7k in body) ]