some tips from my experience, your mileage may vary 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. beware of anyone in a suit... 5. if you don't talk to your customers to see what will make them happy, then sooner or later someone else will... 6. Sales guys can be powerful allies for interoffice BS, but if you make yourself too available they will never leave you alone... 7. Management has no idea what the customer wants... 8. Engineering has even less idea what the customer wants... 9. 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... 10. Never outsource your core competency... 11. Lazyness and incompetence are contagious... 12. no-one cares if you read wikipedia all day every day if you get your work done on time... 13. your code is not finished until you've tested it... 14. never assume they have tested their code... 15. engineers that think lack of documentation is job security should be fired sooner rather than later (otherwise you'll make them right)... 16. Contrary to popular belief, third party libraries reduce portability of your code... 17. Engineers thinking something is "cool" is not a business case... 18. 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)... 19. the night before its due is probably not the best time to start integrating your code in a large project... 20. 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 who is bad at his job... 21. Time estimation is really hard...it will take longer than you think it will... 22. demonstrating that your compeditors suck isn't enough to get anyone to buy your product... 23. don't ship anything you're not proud of... 24. your code will be used in ways you never thought of...plan accordingly... 25. if you can't settle on one way of doing something, do it both ways and make it a configurable option... 26. don't ever have arbitrary limitations, or if you do, hide them better (e.g. "max users 256"...hmmmm?)... 27. 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... 28. in general, meetings are the opposite of getting things done... 29. 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... 30. if its been done before its boring... 31. Keep your code for work very seporate from your code for play... 32. anyone that repeatedly declares things impossible should find their way to your kill file... 33. 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... 34. 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"... 35. don't work any harder than you will be rewarded for... 36. Only listen to the boss that can fire you, the others are just useful for stopping bucks before they hit you... 37. "Working from home" doesn't count against vacation time... 38. coupling == inevitable nasty rewrite... 39. 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)... 40. chances are your customers are not as dumb as you think they are... 41. 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... 42. 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... 43. in general, "revolutionary" products, arnt... 44. don't trust any RFC with updates on April 1st (e.g. IPSEC...jerks)... 45. IEEE specs are worse than RFCs... 46. ITU specs are worse than IEEE specs... 47. stop using ASN.1 its more trouble than its worth... 48. comment your code as if you were going to have to pick it up and use it again in 15 years... 49. 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... thats all I've got for the moment, I'll add more later...anyone else care to add their advice? | 
