I think mine is "there's no such thing as a five minute job" - that programmers tend to be overly optimistic about development and that we should really think through a the implications before promising a quick solution to a problem and then diving in to code
closed as not constructive by DeadMG, Walter, Telastyn, psr, Jeff Atwood Aug 4 '12 at 8:34
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
There is always a better way to write your code.
No matter how excellent you find the code you write, you will be surprised how bad it is if you review it in a few years. Just because a few years before, you were unaware of some patterns you know today, or some language features you've learnt meanwhile, etc.
Think before you start coding.
There is nothing more permanent than temporary solutions :)
If it is awfully hard to solve a problem, most likely the problem itself is badly posed from the very beginning.
Your software will live considerably longer than you think it will at the time that you write it.
I started my career in the 80's. I started on software that originated in the 70's and was still being used in the 90's (maybe longer, I don't know for certain of its fate). Some of my own open source code is half way through its second decade.
Working well with others is very important.
"Show me your 'Go to guy' and I will show you your problem"
Slapdash Hero Coders - those who just crank out code with no regard for convention, readability or whatever anyone else is working on - can cause more harm than good.
Not saying that the people who can write tonnes of good quality code are bad thing. Just rare.
That would be the lesson of humility.
Learning new languages is part of the job
I learned about four programming languages in school back in the 80's but have used one of them in a job. I've had four jobs where I didn't even know the language I was hired to use.
If anything has been a constant in my career, it's change.
Software is never complete.
There is always some changes in requirements, improvements, bug fixes that you have to be prepared to handle. Thus, be flexible and accept the fact that
"software is never complete" and always has room for improvements.
Keep studying every day. The knowledge of today is obsolete tomorrow.
Ironically this answer should be obsolete tomorrow too. But really, study hard one or two stuff and be certificated if it's possible, be the God of that things (maybe programming languages or system/network/database administration) and always keep an eye in other minor things, like other languages without importance to you.
That's the biggest lesson that I learnt from my 16 years of experience. I was for almost 10 years a mono-language programmer, using Pascal in its era, and Visual Basic 6 at the beginning of the millenium, and a PHP developer since 9 years ago. But from then I learn that developers need to know at least a little of everything.
"If your math is wrong, you're toast."
Learnt it the first time several years ago. Learnt it again just two weeks ago.
I would say the best lesson I learnt is
"You should always go for the best approach possible and not your approach."
I have learned that best design principle is KISS (Keep it simple, Stupid!).
I have learned that keeping your code simple and clean should be the primary concern, and each team member should understand what you have code.
The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.
If it ain't broken, don't fix it !
Trying to extend and improve stuff that already works may give you a big headache
There is no try
Lets say you have a task or bunch of tasks that are estimated to take 4 days. Then your boss or project manager asks if you could try to get it done in two days for some important reason. Wanting to be a good, flexible employee, you might be tempted to say: sure, you can try. Most likely outcomes from this is that you either miss the deadline, or you're going to do half-assed hack to get it done. And it's not your boss's fault for asking you to do it, that's his job. It's your fault for not saying no, which is your job.
You can't bargain with time. You can bargain with scope. Be professional and don't sell yourself short.
"That will never happen" actually means "That will never happen until the first day in production"
It feels good to write top-notch, cutting-edge, clean code.
Even if I am asked to do some quick fix-workaround that would ruin the code base, I rather do it the good way.
Writing code is easy. Reading code is difficult. Even if the code is yours. So, whenever possible, go for readable approach.
You aren't smarter than others. Don't ever think you're approach is the best just because its yours.
Pay attention to WHAT is said, not BY WHOM it is said. Brilliant ideas might come for the most unexpected sources.
Don't be lazy. Take your time to write nice code. You'll have to fix it anyway at a higher cost.
Don't use fancy OOP features just because you can! - YAGNI (You ain't gonna need it)
Use fancy OOP features because they have specific, demonstrable benefit to the problem you're trying to solve. You laugh, but i see this all the time. Most programmers never met an object they didn't like. I think it should be the other way around: these techniques are guilty until proven innocent in the court of KISS.