Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Please, stay on technical issues, avoid behavior, cultural, career or political issues.

share

locked by Yannis Rizos Mar 13 '12 at 20:52

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

7  
See this also stackoverflow.com/questions/132798/… –  pramodc84 Sep 9 '10 at 14:14

90 Answers 90

"Hello world" is not a complete application, as there is no demonstrated / programmatic assertion that the output is in fact "Hello world". Code is not complete until it has been unit tested.

share

Some of these have been posted already, but here is my list:

  • Build to the requirements, don't add things you don't need, especially if you "think" you will. If you need it later, add it then.
  • How to use Google search. Don't bother your co-worker, until you've looked.
  • Don't be clever.
  • It's not done till it's meets ALL the requirements, tested, documented, and checked into SVN.
  • Proper coding standards, eg: naming conventions
share

When you have to distribute an application or put a website into production outside the confines of your company, everything that you thought didn't matter, does.

share

Documentation is very important. More so if you are building something from scratch. It helps to document your ideas before writing any code.

I learned this the hard way.

share

Know your OS/Platform before you start coding.

If you code Windows/Linux/Android/iOS etc. start by learning the OS. If you target something else such as Web the same goes there.

share

My first vote would be for Naming Conventions.

share
1  
Unfortunately this IS the first thing people are often taught, and something they probably ought to NOT be taught. –  JohnFx Sep 9 '10 at 16:20

How to do it.

... What do you mean I need 15 characters?

share

Don't forget about the person who is going to use the software you're creating.

share

All data has to live somewhere. You can find it if you look hard enough.

share

Can't comment yet, but on the topic of "Testing and debugging skills", this little gem by Ned Batchelder is a must-read. (Then gain, much of what he has to say on debugging and assertions is worthy of consideration.)

share

Every programmer should know that the only thing s/he knows is that s/he knows nothing. There is a lot to be learnt.

share

Know the basic regular expression syntax including conditional grouping. Stay away from using library specific regex command addons or at least comment/factor out those parts.

share

Regular expressions THE Book about regular expressions

I can't say how many times simple regular expressions converted data that people thought would take days to manipulate. It must be present in every programmer toolbox.

Sure, we can't forget xkcd: Wait, forgot to escape a space.  Wheeeeee—taptaptap—eeeeee.

share

Every programmer should know how a processor works.

share

All problems in computer science can be solved by another level of indirection.

share

Design your code, and if your manager wants to use a RAD style approach try and get as many details as possible. Then when more functionality is added try and think if the existing code can be rewritten before just piling on more code and you end up with a highrise instead of a house.

share

Run the code or logic in your head or paper first. Don't rush to hit the compile and run command to test it out.

share

Recognize that anything that can go wrong will go wrong. Spend very little time writing code – but recognize and reuse common patterns. Refactor code constantly to reach the ideal design.

share

If something can go wrong , then it will . Assume the worst case

share

If the system works and you change it and it stops working, the change you made is what broke it, even if that cannot possibly be the case.

share

They need to know about the power of closures and start using them.

share

Hexadecimal notation. Also bit fields -- ANDing, ORing (inclusive and exclusive), complementing (1's and 2's), bit shifting.

share

Program with maintainability in mind.

share

There are some very good suggestions here, but I'm surprised no one has mentioned the excellent series of articles by Ulrich Drepper: What every programmer should know about memory.

share

every programmer should have a firm grounding in software engineering, and also system analysis/design and information systems concepts. this way if they are called upon to contribute substantially to systems analysis/design and/or information architecture, they will be in a position of knowledge + opionion..whereas normally it seems to be just personal opinion that usually simply stems from personal preferences instead of best problem solution. software engineering is a bit harder to measure, but the pre-requisite knowledge is available out there, and at suitable university degree courses where they teach more than just how to cobble a bit of code together. anyway this is not meant to be negative because the main spirit is but improvement, but then i've worked with some people who have no IT knowledge whatsoever or there's the single minded "script kiddies" that code and re-code (and only in their language of choice) and only see every problem as a repeat of previously applied solutions (by that coder.) so i would much prefer if programmers concentrated more on the larger picture in terms of software engineering (SSADM) and looked at problems as opportunities to do better for the client.

share

It stands in a few letters, really:

Ok, I'm over-simplifying, but basically if you are pretty autodidact, never stop to learn, and are a bit of a perfectionist, you should have the basis to become a good programmer.

Anything beyond that would be more specific to particular roles and technologies.

share

When someone asks you to build something, remember: they are also asking you to maintain it. Possibly, forever.

share

That whatever programs do, more than telling a machine how to do a work, they are a most unambiguous way of showing fellow human beings how to do a work.

share

Be Master of Something, but Be Aware of Everything !!!!

share

Every programmer should bind FindNextSelected and FindPreviousSelected actions (visual studio) to keyboard keys (preferrably F4 and F2). You get two things from that:

  1. Faster way to navigate between different points of variable/function/substring usage (faster than with "Find all references")
  2. Possibility to diff things inside one document. By jumping back and forward while searching some substring you can see the differences between different locations. No need to use Winmerge when need to compare parts of the same document.
share

Not the answer you're looking for? Browse other questions tagged or ask your own question.