What should every programmer know?

Question

Regardless of programming language(s) or operating system(s) used or the environment they develop for, what should every programmer know?

Some background:

I'm interested in becoming the best programmer I can. As part of this process I'm trying to understand what I don't know and would benefit me a lot if I did. While there are loads of lists around along the lines of "n things every [insert programming language] developer should know", I have yet to find anything similar which isn't limited to a specific language.

I also expect this information to be of interest and benefit to others.

Answer 1

• Look for the bad in the buzz - it's nice to think that because something is new, it's better - but every technology has a downside and a limitation. Just because your first real-world corporate team isn't using the latest technology, it doesn't mean their heads are stuck in the sand - look for the reasons why and realize that serious redesign and techology rev won't happen at certain phases.
• it's not about being the star, it's about being on the team - sort of a twist on the elite developer bullet - I'll take a team of 10 people who can cover each other's faults with strengths as a team over the 1 hot shot any day.
• Asking good questions makes you look smart - conversely, handing in something way off the mark because you didn't ask a single question makes you look dumb. Check in early and often with others on your team, especially your designated lead. Restate the goals, even if you have no doubts you understand them, to confirm that you have the right idea. This isn't stupid, it's good communication. The more you can do this, the bigger and harder work you'll be given.

Answer 2

• The most important thing you bring from college is NOT technological - The most important thing you learned is how to learn. The fact is that a large chunk of any specific technology you learned in college will be out of date in a few years, so your ability to learn and absorb new things is paramount.

Answer 3

The fastest way to learn is the slowest. The slowest way to learn is the fastest.

In universtiy I was one of those guys who always asked the prof. for the formulas, for tricks and mnemonics to memorize the right answer, for the fastest way to solve the question, and this is my greatest regret.

Learning things by formulas and memorization means you start every problem at step one; you can't apply any of your previous solutions to new problems. I was no better at solving problems at graduation than I was as a freshman.

The guys who did best were the ones who learned how to do things from first principles; they derived the formulas instead of memorizing them, and would solve the same question multiple times to try different approaches and check their answers.

Yeah, at first those guys took forever to solve the simplest problems, but from then on they never had to solve them again, they knew it cold. By the final year they could solve many problems at a glance, and could estimate the right answer without working it out first.

Answer 4

If you want to be the best possible programmer, you need to understand how the "magic" works. Others have suggested learning about compilers, and that's a good start. I would even say every serious programmer has to build their own compiler at least once. But there are other "magics" you need to understand:

• How floating point maths work on the bit level
• How an operating system manages processes and memory
• How a CPU handles instructions internally (microcode, pipelining, branch prediction, ...)
• How everything is built out of transistors, and how transistors work on the level of basic physics

I would also suggest studying "magical software techniques":

• How game AI works, how a chess game plans its next move
• Different sorting algorithms
• Different techniques for laying out connected node graphs and finding paths in them

You should end up with a knowledge good enough to feel that you could look up everything you need to know to work on any part of the entire system. What this then will give you is a grounding that lets you tackle any issue, regardless of how many disciplines it traverses.

Ofcourse, this isn't all required to be a good programmer, but your question wasn't about being good, it was about being the best you can.

Answer 5

• Source control, unit testing, and continuous integration are far more important than any clever algorithm.

Answer 6

Every programmer should understand that generally the best solution for the business and the most technically elegant programming solution are not the same thing.

Answer 7

THIS:

http://media.smashingmagazine.com/cdn_smash/wp-content/uploads/2010/06/aboutprogramming04.jpg

alt text http://media.smashingmagazine.com/cdn_smash/wp-content/uploads/2010/06/aboutprogramming04.jpg

Answer 8

Where to find the information the programmer needs :)

Answer 9

The fact that, No one is indispensable!

Answer 10

Managing expectations of your clients, your manager, your coworkers.

Answer 11

Your code will inevitably have some little thing you never thought of go wrong. Don't worry, it's ok, just fix it and learn from the experience.

Answer 12

All problems are people problems

Answer 13

Every programmer should know that:

a) maintainability should not be sacrificed for insignificant performance gains.

b) maintainability is better in the long run, even if it costs a little more up front.

c) maintainability generally does not cost more up front if you know what you're doing in the first place.

Answer 14

How to talk to non-programmers about programming concepts. It's tricky to get the hang of, but it will increase your value and the ease of your life greatly.

Answer 15

Do not be a complainer, solve the problem.

Answer 16

• Writing code (with good practices is mind) makes you a better coder.
• Constant study and debate.
• Viewing problems from multiple angles.
• Humility.
• Knowing where to look if you don't know the right answer.

Answer 17

While helpful at times, you should not be fully relying on your compiler or your debugger to help you make your code better.

Answer 18

Model-View-Controller

Answer 19

What you don't know.

Answer 20

Short and sweet -- no person will be an excellent coder / programmer / developer (pick your favorite word) unless he is a continuous learner.

Answer 21

How to establish good communication with management so that requirements and time frames are achievable and realistic.

Answer 22

One of the things that I try to recall whenever I'm writing code is that someone else will have to change it someday. Now, in certain instances, this may not be true, but I write as if it is. I try to code so that they can enjoy the process, or at least not give it a second thought.

Answer 23

Be language/platform agnostic. Java is not the right tool for all applications. Neither is C#, or C, or Lisp, or [insert your own language here]

Without users, there is no use for programmers

And one of my favorite quotes... Always write your code as if the next person to come along and support it is a raving lunatic who knows where you live.

Answer 24

My 2¢ as an aspiring hardware design guy:

you should know how a computer physically works, so that you understand where the power of software bumps up against the limits of hardware, and how to prepare for them, code around them, and come out ahead.

Answer 25

Stop worrying and start doing.

Answer 26

How to learn new things and adapt. I've watch us go from assembler to BASIC to FORTAN, to C, to C++ to Java to C# and so on. I've watched computers go from mainframe to desktops to embedded in just about everything.

I've seen computers go from being large calculator only a few people ever used to controlling almost everything in our daily lives. How many computers, microprocessors, and other programmable device did you interact with today? It may be hundreds!

I know a person with a CS degree they earned about 20 years ago. She has to ask her kids to help them send a e-mail or look up a web site. They could not adapt to the changes.

Your most important skill is learning.

Answer 27

That writing code is only a small part of being a programmer.

Answer 28

You can't bolt 'security' onto a product.

Answer 29

I think that a lot of people are reluctant to help or teach others what they know, and for me, this is, simply put, wrong on many levels.

First of all, one of the best ways to really learn something is to teach it to someone else...and it that someone else doesn't understand your explaining, then it means that you don't know it enough to explain it in simple terms.

If you really are passionate about your craft, why restrict what you know to yourself? I personally think that there is a social side to programming as well. Of course, we all like our late night coding sessions with a mug and an ashtray by our sides, but believe it or not, some time or another, you will find yourself working in a team. And when you are, why not mentor the ones that are less knowledgeable than you (about the respective subject), and teach them what you know so that they become better programmers?

After all, in the final product, better developers will develop a better solution.

...and besides, wouldn't you want other fellow developers giving you a few tips here and there, or even teaching you what they know? I suppose you would...I mean, if you wouldn't, then it just means that you don't love your craft and you are just doing it because there is nothing better to do

So anyways, my point is: Do not keep what you know to yourself...

Answer 30

1. Algorithms and data structures - independent of language or platform (which always change)
2. Google :)
3. Top-down programming
4. Bottom-up programming
5. Concurrency and distributed computing
6. Relational database theory and practical understanding of queries and database design, normalization.
7. Human interface design principles and human factors.
8. How to write clearly and simply to communicate information vs. sounding elegant.
9. Testing principles and theory.