When my friend "gigix" challenged me on "you said a is good, b is good, but what is good". Reflection on your objective is the best advice ever received.

The one that has remained with me for decades is to think about successful programs as icebergs. The part above the waterline (10%) is development; the part underwater is maintenance.

use code only if required!!!

#lazy #lazyprogrammers

Clearly define the problem you are trying to solve before trying to solve it. Break down into the smallest steps possible, and say them out loud to a co-worker. Rinse, repeat.

Think through the problem, and map out solution paths(could be written or mental) before writing code.

Code should be self-documenting

"You're a good programmer. Not a bad one, not a great one.". Since this 'feedback' my professional life is always looking to be a better professional.

I am currently still missing

• SOLID en.wikipedia.org/wiki/SOLID_(object-oriented_desi…)
• SOC en.wikipedia.org/wiki/Separation_of_concerns
• Design by Contract en.wikipedia.org/wiki/Design_by_contract
• Don't leave broken windows blog.codinghorror.com/the-broken-window-theory
• Isomorphic code approaches
• Program against the interface not the implementation
• TDD (although "think before you code" applies to some degree)
• D³ Design driven development
• Write code in the domain you're working in (use the words the people you write the software for use so "unified semantics" )
• Make it work, make it fast, make it good
• Write self-documenting code

and some more ;D come on guys .... we're not even done with the basics yet :D ...

I have read a twitter somewhere and was about python and could be applied to any programming language:

If you want to learn python, try building something with it.

if you don't exactly know what you're doing, don't do it.

code should run on your mind before it runs on the compiler.

"Fix the cause, not the symptom", you would think a head doctor said it to the house surgeon, but one of my earlier mentors told me that.

When you see a bug, it's not about going and fixing it with the first idea that comes to your mind. Always, try to determine the root cause and refactor the code/schema from scratch if need be. "Long term gains, than short term gains" was his idea.

Sleeping is the best debugging strategy.

My JavaScript mentor told me: “Everything's Legal”, and while I don't think all code is good code, as long as it works it could be a lot worse!

1) Think outside the box.

2) If you're stressed out, relax for awhile.

3) Don't be afraid to ask for help once in a while.

4) Don't bash people, only keyboards

There is one that's actually not from a tech guru, but from a cleaning lady who quoted her father, he was a carpenter: "When it's done and it's good no one will ask you how long it took!"

Actually quite wise words, not always true but in the end people will look at the results and rarely about the process. But if you fail or deliver something bad ... that's a different topic.

Besides that I read a lot of books and listen to a lot of talks over years so most of the things I could say will pop up anyway, because they are at the core of our trade and so they get spread by devs who actually wanna be good in what they are doing.

But I'm looking forward for some pearls.

I'm torn between these 2:

1. Don't forget it's called Software... It is MEANT to be changed. This means it should be built to easily be changed over and over.
2. Think about what the computer is actually doing. At the end of the day, we are programming a real computer; a machine. Think of problems in that way rather than applying overwhelming artificial constructs to the problems in order to fit into some methodology.

1. DRY
2. Learn the concepts, not the syntax
3. Don't use too much of framework magic.
4. Show your love to you code, and it will love you back.
5. Think before your hands touch the keyboard.

General coding advice which I have received from my mentor.

1. Think twice about the problem before writing the code.
2. Don't use IDE's shortcut to format ur code, while typing it should comes.
3. Have a thought like computers are stupid we should instruct it properly.