Tell me more ×
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.
up vote 52 down vote favorite
64

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

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

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: FAQ.

90 Answers

1 2 3
up vote 0 down vote

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
show 1 more comment
up vote 13 down vote

That's it's harder than you think.

While it's easy(ish) to put something together that works when used normally, coping with erroneous input, all the edge and corner cases, possible failure modes etc. is time consuming and will probably be the hardest part of the job.

Then you've got to make the application look good too.

share
3  
i think this is the source of the old saying '90% of the work takes 90% of the time. the last 10% takes the other 90% of the time' – GSto Sep 9 '10 at 14:41
show 2 more comments
up vote 16 down vote

Critical and logical thinking. you can't do anything good without it.

share
up vote 4 down vote

Short-circuit evaluation, althought it's one of the first thing they teach you about boolean operators.

share
up vote 6 down vote

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

share
up vote 10 down vote

Which language and environment is most suitable for the job. And it's isn't always your favourite.

share
up vote 93 down vote

  1. The bug is in your code, not the compiler or the runtime libraries.

  2. If you see a bug that cannot possibly happen, check that you have correctly built and deployed your program. (Especially if you are using a complicated IDE or build framework that tries to hide the messy details from you ... or if your build involves lots of manual steps.)

  3. Concurrent / multi-threaded programs are hard to write and harder to properly test. It is best to delegate as much as you can to concurrency libraries and frameworks.

  4. Writing the documentation is part of your job as a programmer. Don't leave it for "someone else" to do.

EDIT

Yes, my point #1 is overstated. Even the best engineered application platforms do have their share of bugs, and some of the less well engineered ones are rife with them. But even so, you should always suspect your code first, and only start blaming compiler / library bugs when you have clear evidence that your code is not at fault.

Back in the days when I did C / C++ development, I remember cases where supposed optimizer "bugs" turned out to be a due to me / some other programmer having done things that the language spec says have undefined results. This applies even for supposedly safe languages like Java; e.g. take a long hard look at the Java memory model (JLS chapter 17).

share
17  
I prefer to say "The bug is probably in your code", since I've come across bugs in runtime libraries a few times. I've yet to run into a compiler bug though. +1 anyway. – Chinmay Kanchi Sep 9 '10 at 16:24
29  
If you've never found a bona fide bug in the compiler, you're not nearly adventurous enough with your coding. ;) – Mason Wheeler Sep 9 '10 at 22:57
8  
@Chinmay, @spudd86, @Mason - yes ... and I've also found my share of compiler and library bugs in my 30+ years of programming. But in my experience, 99+% of bugs turn out to be (at least in part) the fault of my code. My answer deliberately overstates this to get across the point that you should always suspect your code first. – Stephen C Sep 9 '10 at 23:06
5  
I don't get the irrational fear that people have with multi-threaded programming. I suspect the people who perpetuate this view, don't program much multi-threaded code. It's just not that hard. +1 for everything else though. – Steve Evers Sep 13 '10 at 17:19
4  
If you're working on the compiler, then the bug is probably in both your code and the compiler ;) – Legooolas Sep 16 '10 at 12:19
show 13 more comments
up vote 19 down vote

Every programmer should know about testing.

share
6  
It doesn't work unless you've tested it. – J8D Sep 9 '10 at 16:13
up vote 84 down vote
  • How to read other people's code.
  • Code doesn't exist if it is not checked in Version Control System.
share
8  
+10000 if I could for the version control comment. History and change logging are absolutely indispensable and are the reason you should put everything in version control right from the start. – Legooolas Sep 16 '10 at 12:20
2  
...and the repository has been synchronized to at least one other location. Important with DVCS, but also with centralized VCS. – Roger Pate Sep 27 '10 at 11:37
1  
+1 one for version control comment. – Tyler Egeto Oct 20 '10 at 2:08
2  
I will plus one for learning how to read other people's code. It's more difficult that most of us realize, but an essential part of successful programming. – bogeymin Dec 24 '10 at 13:10
show 2 more comments
up vote 27 down vote

Every programmer should know that he's putting assumptions in code all the time, e.g. "this number will be positive and finite", "this code will be able to connect to the server all the time within a blink of an eye".

And he should know that he should prepare for when those assumptions break.

share
6  
specifically state those with assert() -- everywhere. assert() will help you document your assumptions and save you when you are wrong. – Dustin Sep 15 '10 at 18:42
1  
...unless compiled with NDEBUG. – Roger Pate Sep 27 '10 at 11:51
show 1 more comment
up vote 63 down vote

Don't stop learning.

share
1  
Related: Don't stop believing. – Fishtoaster Sep 21 '10 at 21:18
3  
Related: Don't stop thinking about tomorrow. – Slomojo Dec 13 '10 at 21:21
7  
Related: Don't stop the music. – adamk Dec 24 '10 at 15:47
1  
Related: Don't stop movin'! It's your life, keep on movin', get it right, you gotta get it right! – Slomojo Jan 16 '11 at 3:19
up vote 2 down vote

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.

share
9  
You're talking about software engineering not CS... – Spudd86 Sep 9 '10 at 18:32
up vote 39 down vote

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.

share
2  
I was about to post this. So much of a programmer's job is fixing bugs, and a lot of people tend to be incapable of doing so (especially in others' code). – Dov Sep 9 '10 at 18:30
2  
I think the point of debugging to validate your assumptions across your program. Sometimes, you need to go fishing for some clues. This has to be done systematically. It it perfectly valid to try something that might tell you something new. I do it often. – gawi Sep 27 '10 at 19:04
show 2 more comments
up vote 11 down vote

Pointers, obviously. :)

share
3  
Pointers are only really necessary in a subset of languages for a small subset of tasks. For most tasks, you can (and should be able to) program as if the concept of a pointer didn't exist. – Chinmay Kanchi Sep 9 '10 at 16:29
14  
@Chinay Kanchi No. Pointers should be understood by everyone. – alternative Sep 9 '10 at 20:04
5  
That really depends on what you mean by pointer. If you mean C-style pointers that you can manipulate (which is what I assumed), I would argue that a Java/C#/Python programmer doesn't need to know anything about them. If you mean pointer as in Java's "references", i.e., a pointer that can't be fiddled with, then yes, some knowledge of them is necessary, if only to prevent you from slipping up. – Chinmay Kanchi Sep 9 '10 at 23:25
5  
@Chinmay: A Python/Java/C# programmer that doesn't understand the concept of pointers is lost. L = [[]] * 2; L[0].append(42) Different languages use different names, but indirection is essential everywhere. – Roger Pate Sep 27 '10 at 11:55
show 2 more comments
up vote 76 down vote

Floating point computations are not precise.

share
22  
1  
And if they don't know they can be amongst the set of people who ask on stackoverflow daily. – Brian R. Bondy Sep 9 '10 at 23:20
1  
@Brian: So true. I wish there was a way to identify questions explained by floating point arithmetic. You could create a Stack App that displays a different floating point question every day! – Adam Paynter Sep 17 '10 at 16:50
show 1 more comment
up vote 1 down vote

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

share
up vote 1 down vote
  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
share
up vote 14 down vote

Unit Testing. This is a great way to codify your assumptions on how the code is to be used.

share
up vote 5 down vote

Data structures

share
up vote 44 down vote

That the #1 thing you can do to increase the quality and maintainability of your code is REDUCE DUPLICATION.

share
4  
DRY, yes! How I can forget? ;-) – bigown Sep 10 '10 at 13:50
1  
You know, the funny thing about DRY is that it's repeated everywhere. :) +1 – Billy ONeal Jan 16 '11 at 9:11
show 2 more comments
up vote 34 down vote

The basics. Currently programmers learn technologies not concepts. It's wrong.

share
4  
+1, so true. Yes, this is something ivory tower types like to say, but it doesn't make it any less true for the rest of us in the trenches. – MAK Sep 16 '10 at 11:23
2  
Basics like spelling? Its wrong should be it's wrong, for example. – Konerak Sep 16 '10 at 11:46
2  
No, basics like doesn't care about a typo but care about programming issues. – clrod Sep 18 '10 at 0:27
5  
It's easy to learn the steps to do something and often hard to find out when you should use it and more importantly when you could use it but shouldn't. Textbooks are particularly bad at showing the how but not the why (and why not). – HLGEM Sep 24 '10 at 18:35
show 3 more comments
up vote 0 down vote

How to do it.

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

share
up vote 10 down vote

Divide and Conquer. It's usually the best way to solve any type of practical problem from scheduling to debugging.

share
up vote 13 down vote

Domain knowledge. The spec is never 100%; knowing the actual domain with which you are developing for will ALWAYS increase the quality of the product.

share
up vote 17 down vote

Learn concepts. You can Google the syntax.

share
show 1 more comment
up vote 3 down vote

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

share
up vote 1 down vote

How to write a FizzBuzz program.

share
1 2 3

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