What should every programmer know about programming?

Question

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

Answer 1

User mistakes are not; they are usability mistakes:

• Dangerous functionality should be undoable, not just warned about. Here's looking at rm, which still doesn't work with the trash can.
• Do the least harmful thing if the user breaks (ESC, Ctrl-C). Ideally, the system should be in the same state as before running the command. rm, again.
• Harmful options should be far away from harmless ones. Right-clicking a file in the GNOME Trash can shows "Delete Permanently" directly adjacent to "Restore" :(

Not to pick specifically on GNU Tools or GNOME, but these were the easiest examples to come up with.

Answer 2

That knowing the answer to this question doesn't make you a programmer

Answer 3

Big O notation and its implications.

---

Some useful references

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Answer 4

Speaking of commercial software dev here... Obviously might not apply to a DOD security system or a hedge fund quant.

• Focus on what works, not on what's clever, KISS.
• Keep the 80/20 rule in mind, and don't spend all your time trying to please/sell the minority.
• Take a course in data structures / algorithms.
• Test, test, test.
• Don't go mucking about in code that is in production, and currently working. Unless you have excessive cash flow and no new ideas. Then it's fine.
• The vast majority of your time will be spent sorting through the cruft, and not solving interesting programming problems. Unless you're interviewing, in which case people only want to see how you solve interesting programming problems.

Answer 5

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.

Answer 6

Never blame on the user what could be fixed with a cleaner user experience or better documentation. Often, programmers automatically assume the user is an idiot who can't do anything right, when the problem is a poor overall experience or lack of communication. Programs are meant to be used, and to treat the user with contempt is to miss the point of programming in the first place.

Answer 7

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

Answer 8

Don't stop learning.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

Can't believe this hasn't been mentioned

Every programmer worth is salt needs to be able to produce world ready software.

By this I mean following basic internationalization principles such as externalizing all strings etc.

I can't believe how many times I've seen hard-coded English strings or dialogs with truncated strings etc. when the product has been translated.

Answer 13

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.

Answer 14

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

Answer 15

Software Licensing Basics

• The difference between a "viral" copyleft license (GPL) when compared to closed-source-friendly Apache, and non-viral MS-PL/MS-RL.

• When you should use LGPL, and when not to.

• License compatibility. For example, you may link a modern Apache license'd library to a GPLv3 code, but not GPL 1 or 2.

• If you own the source code in it's entirety, you may publish it under as many (or few) licenses as you wish.

Note to S.O. community:
Please feel free to edit this answer as you see fit... mainly for information not suited for the comments section below.

Answer 16

Evaluation.

A programmer ought to know how the statements they write are evaluated. a(line.of(code) is aSequenceOf(evaluations)) and if you don't understand what that line looks like after each step of its evaluation, you are going to be extremely restricted as a programmer in your ability to take advantage of language features.

I'm not just talking about the basic

if (bool == false):
    return true
else:
    return false

which of course can just be replaced by return !bool.

I'm also referring to the ability to understand your language to the point where you can come up with something like this:

string[] thingsToOutput;
for(int i = 0; i <= thingsToOutput.Length; print(thingsToOutput[i++]));    

When I first saw a statement like that it blew my mind a little bit; it hadn't occurred to me I could leverage the for loop in such a way. The person who wrote that statement more fully understood the possibilities available to them - they saw more open doors than I, which gave them more freedom and power in their ability to design code.

Now, whether it's good code is an issue - whether any of those doors should be opened - that's up to debate. It remains that with great power comes great responsibility.

Answer 17

It stands in a few letters, really:

• RTFM (and for the kewl kidz today: JFGI)
• DRY
• KISS
• H2G2

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.

Answer 18

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.

Answer 19

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

Answer 20

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

Answer 21

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.

Answer 22

Troubleshooting and Debugging Skills

They hardly spend any time on this topic in any of the programming courses I took, and in my experience it is one of the biggest determinants of how productive a programmer is. Like it or not, you spend a lot more time in the maintenance phase of your app than the new development phase.

I've worked with soooooo many programmers who debug by randomly changing things with no strategy for finding the problem whatsoever. I've had this conversation dozens of times.

Other Programmer: I think we should try to see if it fixes it.
Me: Okay, assuming that does fix it. What does that tell you about where the source of the problem is?
Other Programmer: I don't know, but we have to try something.

Answer 23

Program with maintainability in mind.

Answer 24

Order of execution.

You'd be amazed, when talking to programmers vs the people who've never seen or touched code or the pretend programmers*, the thing they don't get is the order of execution. If you meet someone who can't pick up on the control structures, get this idea in their head first. You'll find that they learn faster after that.

*yes, those people who are able to get jobs as programmers, but when you ask them the simplest technical question they go brain fart.. I think we've all met one of those.

Answer 25

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

Answer 26

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

Answer 27

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.

Answer 28

Every programmer should know how to use the debugger, and know how to use it well.

Answer 29

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

Answer 30

write code for people!

no more magic number!

don't write all code in one line!