What should every programmer know about programming?

Question

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

Answer 1

That there are -

1) Other programming paradigms beyond just OO (object orientation) 2) Other better IDEs beyond Visual Studio (this one is especially for programmers who have worked only on Windows and only on MS technologies)

Answer 2

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 3

How the computer really works, language fundamentals, algorithms/data structures, algorithm analysis, and some measure of complexity theory.

Answer 4

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 5

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 6

Every programmer should know the "science" in Computer Science (design patterns, algorithms, objects, etc...) if you can master that, you can program using any language, it is just a matter of getting used to the syntax.

Answer 7

Cryptography. You don't have to be able to write your own encryption algorithm, but you have to have a basic understanding of how encryption, message authentication and the PKI works. I have struggled for too long with blind trial and error in this area. Recently I have picked up the book "Cryptography Engineering" (by Ferguson, Schneier, Kohno) and it has been a real eye-opener.

Answer 8

Unit testing is not a silver bullet. You can still introduce bugs, write wrong tests and it should not be the only form of tests you do.

Answer 9

Computers don't understand semantics. Suppose you have this:

var ferrari = new Ferrari();
ferrari.DriveTo(Places.Seattle);

To the computer, you may as well have used different type names and used:

var mxEEcceqs = new safHBBdueWE();
mxEEcceqs.HYBbQAW(n3dNm.pDojeW);

Naming things is very important, but don't make the mistake of assuming the computer knows what you "mean" just because you named your type "Ferrari" or your method "DriveTo".

Answer 10

What lexing and parsing are, just a vague overview is fine. Better yet, passing familiarity with at least one parser generator framework.

Most of the most horrid WTFs I've seen is people's custom parsing routines. Horrible to initially code, worse to maintain.

Answer 11

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 12

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 13

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 14

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

Answer 15

The more you know about how security works on your platform of choice the better.

Answer 16

Test like you fly, fly what you tested.

Answer 17

1. a thorough understanding of foundation concepts e.g. datatypes, interfaces
2. a medium to high level understanding of the tool they are using e.g. specific .net/java knowledge
3. a reasonable idea of 'the other technologies your stuff interfaces with' e.g. how databases work
4. roughly where their technology base is headed e.g. what is cloud computing and what impact it will have on their current skillset

Answer 18

How to write a FizzBuzz program.

Answer 19

Code is only beautiful if it does what it's supposed to do.

Answer 20

Fixing code requires more intelligence than writing the same code initially.

Therefore, if you write code at the limit of your cleverness then you are, by definition, not smart enough to fix it when it breaks.

Answer 21

Write your data structures first -- that means everything from database schemas to swizzling/serialization mechanisms.

Most projects are about storing and moving data from point A to point B in format C.

When all is said and done about 90% of your code will be logic for doing the formatting, but the real killer is just having a format to access and write your data. Once you have an API for data access you can play around with the formatting however you want, but once you start production with a storage API it can really hurt to realize that you screwed it up.

Answer 22

In Steve Yegge's 5 essential phone screen questions, he's trying to make sure interviewees have a basic knowledge of:

1. Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
2. OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
3. Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
4. Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
5. Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.

http://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

At the time he wrote this, he was at Amazon, but works (and probably conducts interviews) at Google now. This just gets you past the screen. Here's how he described what he was looking for:

what I'm looking for here is a total vacuum in one of these areas. It's OK if they struggle a little and then figure it out. It's OK if they need some minor hints or prompting. I don't mind if they're rusty or slow. What you're looking for is candidates who are utterly clueless, or horribly confused, about the area in question.

Answer 23

1. build something that people want
2. build something that you want to use every day
3. if you don't comment your code, make sure it reads cleanly
4. comment your code

Answer 24

Learn how to deploy your code, tests and software package well.

One of the worst habits of developers I have seen in industry is a common ignorance of how to put your software in the hands of other people, here are some bad signs:

New development environment-itus:

• I wanted to learn Ruby so we wrote our stuff in it, the customer and the main build will have to pick up a Ruby environment now

Version-itus:

• Our team moved to compiler version X+1 because it's the latest, didn't we tell anyone?
• We need library version Y, oh, your stuff doesn't work with that?
• We tested on a really old release, it doesn't work with the latest build?
• We hacked a special version of kernel to get the release to work

Binary-only-itus:

• Our build environment is really complicated, we'll just give you binaries

Multi-core-itus:

• Disable SMP, our stuff only works on uniprocessor environment

Hard-coded-feature-itus:

• Uncomment this #define to enable feature X, what do you mean you want it at runtime?

Answer 25

Simplicity, Clarity, Generality. http://www.math.harvard.edu/computing/programming/rules.html

• build systems as networks of simple processes connected by sockets / pipes
• exchange data in a simple text format: sets of records of "key: value" pairs, or TSV

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." BWK

Answer 26

Use the right tool for the job.

The programmer is the important element, and the language and tools should be chosen based on the problem. Don't be afraid of new languages and projects.

Answer 27

There is no crying in programming!

Answer 28

• Binary with basic understanding of signed and unsigned.
• Understand how any positional numeral system works.
• Understand how basic data structures are stored in memory.

Answer 29

There is no such thing as a bug that cannot possibly happen.

Answer 30

write code for people!

no more magic number!

don't write all code in one line!