DZone Top Article of 2011: Ask DZ - What's the best programming advice you've ever got?

"the maiin thing, about OOP, is not inheritance. It's state encapsulation. Hide your internals while opening to extension."

One of my most productive days was throwing away 1000 lines of code. - Ken Thompson

My Cobol teacher, at the very beginning of my career: "Single point of definition". i.e. do not copy/paste code. It only proved to be true over and over again. I wish many more people had had this advice.

I can't pick one but I can pick a few and let the community decide:

1) It's ok to say "I don't know" from time to time. This field is broad with too many specialties for any single person to know every intricacy of the whole field and its specialties. A person with a solid track record of quality who occasionally admits not being an expert on something, proves themselves to be competent at evaluating a broad base of knowledge and more importantly trustworthy. There is nothing that scares be more than a software engineer who knows everything.

2) Tolerance for imperfection is inversely proportional to the time it takes to deliver. In other words, the longer it takes to deliver a solution, the greater the scrutiny by the customer. (a good solution today is better than a perfect solution next year)

3) The single greatest failing of our profession is our inability to identify and manage expectations. Too often we get in a rut of delivering on requests without thinking how the request fits into the original scope. Keeping a code base tight and narrowly focused produces greater consistency and quality within an application.

4) yes, a Swiss Army knife does have a knife and a toothpick and a screw driver and scissors and corkscrew. But if you spend all day using any single one of these tools, you will notice that the knife is not as good as the ka-bar you have in the truck. The scissors are not as good as the scissors in your desk. The corkscrew is probably broken off by the third time it is used and the screw driver isn't even as good or useful as the lowest end craftsman. In short, none of the individual tools is as good or even good enough quality as the real thing (well maybe the toothpick). Software is the same way. You will find your swiss army knife of software is almost always comprised of substandard toolsets compared to the individual offerings in each category.

5) Software development is always an exercise in compromise. You can have it fast, cheap or bug-free, pick 2. We trade high memory utilization for speed. If you want something more reliable/fault tolerant, it will cost more redundancy/complexity. The hallmark of a good engineer is identifying the sweet spot in that compromise. What is your customer willing to live without?

If you are not a part of the solution, then you are probably a consultant.

If you can say "value add" without falling on the floor laughing then it is probably time to get out of consulting.

Software is never done.

"Don't sweat the small stuff". My manager gave me a little book many years ago. It was a couple of months before I even read it, but it sank in and I applied it to life as well as work.

Some things are important but most things are either a low priority or not important at all. Concern yourself with what really matters to you and apply effort where you can make a difference, and you'll be satisfied instead of frustrated.

"A moment of convenience, a lifetime of regret."

I don't remember where I read this from, but it says something like this: "Pretend that the guy who is going to maintain your programs is a villain psychopath who knows where you live"

I would say the very best advice I ever got was YAGNI - You Ain't Gonna Need It. More details on the actually story if anyone is interested can be found on my (just started) technical blog. The essence of it though remains always the same and is as simple as they come by. Reduce clutter wherever you see it. Write only the code that is actually needed. Add only the features that are going to be used. Besides the less code you have, the less bugs can hide in it.

1. Encapsulation - We should know what to make public and what to keep as private or protected. It helps us to improve the understanding of the application that we design as well as oop.

2. Finding the resuable part of code and writting them as utilities and making it visible using public keyword. If we focus it on making it more generic, so that it can be utililized the most. It reduces the lines of code and it increases the readability. It mainly helps when we work as team so that the other person can reuse the piece of code written by us. Its a feel goodfactor also for beginners :)

3. Eqivalent to data model, constructing business object is a key for application design. 

4. While debugging an algorithm, we should try our best to find out the issues through the error messages rather immediately jumping to a debugging tool. This will help us a lot in the way we think and understand we do mistakes.  Once we figure out the data structure, its always good to compare it with other suggestions in google.  By this way, we can improve our knowledge and we can become a better coder day by day

"You are not as smart as you think."

 Applicable not only to programming.