Cloud Zone is brought to you in partnership with:

John Esposito edits Refcardz at DZone, while writing a dissertation on ancient Greek philosophy and raising two cats. In a previous life he was a database developer and network administrator. John is a DZone Zone Leader and has posted 331 posts at DZone. You can read more from them at their website. View Full User Profile

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

01.18.2012
| 25653 views |
  • submit to reddit
For example, Travis Griggs' blog post explains some of the best OOP advice he ever received.

What is the best piece of advice anyone ever gave you, and why it was so good? Maybe include some particular projects the advice helped you with, or how the advice improved your general approach to development, etc.

Comments

John Esposito replied on Thu, 2011/09/29 - 5:33pm

I'll start. My physics teacher once told me: 'The best way to understand an application is to find some well-written code and see how it works.' I guess this is more about learning than actual development, but the general idea is that there's never any need to re-invent the wheel.

Thomas Escolan replied on Fri, 2011/09/30 - 2:54am

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

Mihai Dinca - P... replied on Fri, 2011/09/30 - 3:03am

This is not an advice someone told me, this is something I saw about my team mates and I embraced from my  first days of programming: "Put passion into your work". If you like what you are doing, you can create better software.

Aravind Yarram replied on Fri, 2011/09/30 - 6:24am

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

Wojciech Kudla replied on Fri, 2011/09/30 - 10:26am

"Do the simplest thing that could possibly work"

Dirk Estievenart replied on Fri, 2011/09/30 - 10:44am

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.

Jonathan Fisher replied on Fri, 2011/09/30 - 10:57am

Pretend you're the guy maintaining the code you're writing. Comments can't compensate for an over-engineered solution.

Matt Young replied on Fri, 2011/09/30 - 12:29pm

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?

Ronald Miura replied on Fri, 2011/09/30 - 3:21pm

All advices are useful in some context, but usually bullshit in yours. Think for yourself.

Loren Kratzke replied on Fri, 2011/09/30 - 7:02pm

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.

Paul Denninger replied on Fri, 2011/09/30 - 10:54pm

*Echoing Wojciech's comment
"Everything should be made as simple as possible, but no simpler." -Einstein

Many of the popular "layers" being added onto software in this day do not make coding simpler, just more bloated and buggy.

Lund Wolfe replied on Sat, 2011/10/01 - 12:52am

"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.

John Fuex replied on Sat, 2011/10/01 - 11:23am

No one ever told me this that I can remember, but I learned it on my own.

 

Quippy quoty version:

If the hill is getting steeper, you are going the wrong direction. 

 

Practical, but less poetic version:

 If the complexity of your code is getting more complicated, or you are running into difficult problems to solve in code, you are probably doing something wrong. Take a step back and re-think your overall solution instead of trudging through it.Also, if you are solving a meta-problem more than 2 levels deep, you are DEFINITELY on the wrong track.

Cay Horstmann replied on Sat, 2011/10/01 - 5:36pm

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

Jacky Chan replied on Sun, 2011/10/02 - 8:40am

Need to undersand all the codes no matter copy  and  paste from your friends or source codes on the  internet.

Setya Djajadinata replied on Sun, 2011/10/02 - 11:44am

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"

Sivaprasadreddy... replied on Mon, 2011/10/03 - 3:01am

Its not an advice, i took it from the movie The Dark Knight.

If you are good at something, Never do it for Free.

I guess, It fits in IT industry.

If a smart developer proactively gave a very good idea for the project, Project Managers will never realize its value. If you gave the same idea when a Production Issue came and everyone is on call then only they will realise how valuable your idea is.

 

George Kalfopoulos replied on Mon, 2011/10/03 - 4:36pm

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.

Ivan Lazarte replied on Tue, 2012/01/10 - 1:06pm

The Art of Unix Programming is all you need to know.
http://catb.org/~esr/writings/taoup/html/ch01s06.html

Eric's rules are timeless, and I apply them every day.
For those too lazy to click through:

Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Rule of Simplicity: Design for simplicity; add complexity only where you must.
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
Rule of Transparency: Design for visibility to make inspection and debugging easier.
Rule of Robustness: Robustness is the child of transparency and simplicity.
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
Rule of Least Surprise: In interface design, always do the least surprising thing.
Rule of Silence: When a program has nothing surprising to say, it should say nothing.
Rule of Repair: When you must fail, fail noisily and as soon as possible.
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
Rule of Diversity: Distrust all claims for "one true way".
Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Venkatesh Jayapal replied on Thu, 2012/01/19 - 3:20pm

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

Jacek Kruszelnicki replied on Thu, 2012/01/19 - 3:53pm

"Keep It Simple, Stupid." (From "Programming in Fortran" (early 80s).

As relevant and ground-breaking as ever.

Franklin Chen replied on Fri, 2012/01/20 - 2:33pm

"You are not as smart as you think."

 Applicable not only to programming.

Neil Carrier replied on Thu, 2012/02/02 - 5:27pm

When I was in grad school, whenever I'd say "I'm bored," a friend of mine would reply "Write a program!" And that was the best advice I've ever gotten: practice, practice practice...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.