52

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

Tamara Wijsman
  • 8,259
  • 14
  • 58
  • 94
Maniero
  • 10,826
  • 14
  • 80
  • 133
  • 7
    See this also http://stackoverflow.com/questions/132798/what-should-every-programmer-know – pramodc84 Sep 09 '10 at 14:14
  • This sort of question really annoys me. It can only spring from the mind of someone who sees the world in terms of black & white. Not every programmer has the same job and if it is the smallest common denominator that you are looking for, the answers below show that you just end up with a list of pet peeves. – Captain Sensible Jun 24 '11 at 18:22

90 Answers90

92

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

Stephen C
  • 25,180
  • 6
  • 64
  • 87
  • 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 09 '10 at 16:24
  • 2
    I had a compiler (gcc) fail to compile code with an internal error once... I never got around to reporting the bug, but it got fixed. – Spudd86 Sep 09 '10 at 18:31
  • 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 09 '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 09 '10 at 23:06
  • @Mason: Probably. I tend not to have to write code that uses the more obscure parts of a language, so compiler bugs just don't happen for me. – Chinmay Kanchi Sep 09 '10 at 23:22
  • Well, except when it is in the compiler. Type ordering issues quite commonly cause problems in .NET with type scanning code when moving between compiler versions. – Ryan Roberts Sep 10 '10 at 16:07
  • 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. – Steven Evers Sep 13 '10 at 17:19
  • 3
    @SnOrfus - there is no question that writing and debugging concurrent code is harder than ordinary code. Whether you call it "hard" is a matter of opinion, I guess. – Stephen C Sep 14 '10 at 06:12
  • @Stephen C: +1; I'll agree to that. – Steven Evers Sep 15 '10 at 06:14
  • As far as #1 goes, I disagree when it comes to doing winforms GUI application development. I know MS may consider some artifacts to be features and not bugs but that doesn't mean I won't have to waste a lot of time/effort trying to implement a hackish workaround if one even exists. – Evan Plaice Sep 15 '10 at 12:06
  • @Mason Wheeler To be fair, sometimes you don't even need to be adventurous. Delphi 6 doesn't multiply Cardinals correctly - it uses imul (signed multiply), not mul (unsigned multiply). Write an RTP stack with range checking on and wonder why you get range check errors! – Frank Shearar Sep 15 '10 at 13:32
  • I've found at least one compiler bug - the company acknowledged and logged it as a bug. :-) – Paul Nathan Sep 15 '10 at 18:06
  • @SnOrfus - I'm not afraid to write multithreaded code, but I'm afraid when other people do, and when I try to write multithreaded code using other peoples' libraries. Also, most concurrency-related bugs typically don't show up when you are testing out some code by yourself in a single-user context (like running a web app on your local machine). – John Cromartie Sep 15 '10 at 18:54
  • 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
  • @Legooolas I remember when gcc's abs() builtin made code think -10 == 10. That was a _maddening_ few days :) That was not long ago, gcc 3.4. I still have the patch that fixed it. – Tim Post Oct 20 '10 at 04:52
  • 1
    Sometimes it is useful to suspect a bug in library code and start writing a good bug report. While writing test case that shows that bug, you either find that there's actually no bug, or maintainers tell you what are you doing wrong. – Vi0 Oct 22 '10 at 20:38
  • @snOrfus, it IS harder to test multi-threaded code as you introduce that context switches can happen at any point so the code can step on each others toes. Also you introduce the "when is the data cache over here the same as the data cache over there"-problem which is HARD: –  Nov 20 '10 at 08:10
84
  • How to read other people's code.
  • Code doesn't exist if it is not checked in Version Control System.
pramodc84
  • 1,803
  • 23
  • 23
  • 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. –  Sep 27 '10 at 11:37
  • For that matter, code doesn't exist unless a work item exists which authorizes the developer to write it. – Jesse C. Slicer Dec 13 '10 at 21:46
  • 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
  • plus one for learning how to read other people's code. – itsaboutcode Jul 06 '11 at 05:09
76

Floating point computations are not precise.

Chinmay Kanchi
  • 6,173
  • 2
  • 39
  • 51
  • 22
    +1: [What Every Computer Scientist Should Know About Floating-Point Arithmetic](http://docs.sun.com/source/806-3568/ncg_goldberg.html) – Adam Paynter Sep 09 '10 at 16:49
  • If anyone doesn't know what I'm talking about, read @Adam's link. It's an excellent summary of the pitfalls of floating point computation. – Chinmay Kanchi Sep 09 '10 at 16:53
  • 1
    And if they don't know they can be amongst the set of people who ask on stackoverflow daily. – Brian R. Bondy Sep 09 '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
63

Don't stop learning.

systempuntoout
  • 3,545
  • 3
  • 29
  • 33
44

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

Chris Holmes
  • 2,244
  • 14
  • 14
39

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.

Igor Popov
  • 103
  • 5
JohnFx
  • 19,052
  • 8
  • 65
  • 112
  • 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 09 '10 at 18:30
  • +1 I went from javascript/php to C# and fell in love with stepping through code. I wish that dynamically typed languages could do a much better job of this. – Evan Plaice Sep 15 '10 at 11:54
  • Another weird behaviour is the programmer insisting that every part of his program is correct while the result if faulty. "-You don't need to print the array on the console to check if it's sorted because the line above is array.sort()." "-Well... you know, it's not working. There must be something wrong somewhere. You can't just defend your code at this point!" – gawi Sep 27 '10 at 18:59
  • 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
37
  1. Don't be clever; be clear.
  2. Use before reuse.
  3. Names matter.
  4. A function does 1 thing and does it well.
  5. Small is better than big.
KevBurnsJr
  • 131
  • 1
  • 4
34

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

clrod
  • 472
  • 5
  • 8
  • Yes and no. You sound like every prof I ever had in university... all of whom never made a lick of software in their entire life. Knowledge, without skills is useless in our profession. – Steven Evers Sep 13 '10 at 17:25
  • Yes. jQuery is best example. – pramodc84 Sep 15 '10 at 07:28
  • 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 00: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
  • Sometimes for a beginner it is very hard to see why, beyond the obvious, some things are used. I've read many books that show how to do something but leave me wondering why I would. – fender1901 Apr 29 '11 at 13:54
26

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.

LennyProgrammers
  • 5,649
  • 24
  • 37
  • 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
  • @Dustin +1 There's no way you can just remember all your assumptions - document them programmatically and you'll be told exactly when they turn out to be wrong assumptions. – Skilldrick Sep 23 '10 at 11:05
  • 1
    ...unless compiled with NDEBUG. –  Sep 27 '10 at 11:51
19

Every programmer should know about testing.

Tom Duckering
  • 151
  • 4
17

Learn concepts. You can Google the syntax.

pramodc84
  • 1,803
  • 23
  • 23
  • Good in theory, except Google is terrible for finding *specific* syntax: Searching for terms like "object reference" or "this" given a gazillion results, and searching for idioms like "$?" give no results at all. – l0b0 Jan 17 '11 at 10:06
16

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

Mladen Prajdic
  • 351
  • 1
  • 6
14

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

btlog
  • 626
  • 5
  • 4
14

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).

Carlos
  • 1,479
  • 1
  • 12
  • 17
13

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.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
  • 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 09 '10 at 14:41
  • I think a lot of people tend to consistently under-estimate the complexity. "How hard can X be?" - famous last words :/ – Roman Starkov Sep 21 '10 at 23:20
  • @GSto I don't want to work 180% of the time, 100% is just fine by me! – adamk Dec 24 '10 at 15:53
13

Big O notation and its implications.

Some useful references

ocodo
  • 2,948
  • 3
  • 23
  • 31
Maniero
  • 10,826
  • 14
  • 80
  • 133
  • I find Big O notation is one of the main things most computer scientists have a problem with (myself included) – Richard Dec 13 '10 at 19:42
13

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.

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
11

Pointers, obviously. :)

Laurynas Biveinis
  • 209
  • 1
  • 6
  • 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 09 '10 at 16:29
  • 14
    @Chinay Kanchi No. Pointers should be understood by everyone. – alternative Sep 09 '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 09 '10 at 23:25
  • @mathepic You'll be shaken to your very core if you were to learn how many CS students graduate each year that don't understand the first thing about pointers. If I hadn't gone out of my way to take placements each summer I wouldn't have even been taught about pointers in C or references in Java... – Mike B Sep 13 '10 at 14:54
  • 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. –  Sep 27 '10 at 11:55
  • @Chinmay, EnderMB: Exactly, **indirection** is the point here. In any language (except proably Haskell), you need to know indirection to understand how and where data will change. – Dario Dec 30 '10 at 11:23
11

Code Complete 2 - cover to cover

Kyle B.
  • 782
  • 6
  • 12
  • you really should know this before you accept money to program. If you find thing you did not know in it, consider either a career change or an intense period of self directed study to get you across it all. And then apologize to your co-workers. And it only covers the programming basics. – Tim Williscroft Oct 07 '10 at 00:58
11

Data is more important than code.

If your data is smart, the code can be dumb.

Dumb code is easy to understand. So is smart data.

Almost every algorithmic grief I've ever had has been due to data being in the wrong place or abused of its true meaning. If your data has meaning put that meaning into the type system.

10

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

Dan Diplo
  • 3,900
  • 1
  • 27
  • 30
10

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

Rick Minerich
  • 171
  • 4
8

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.

8

True skill is reflected in the ability to execute a simple design well, not in the ability to make a complicated design work at all.

This skill comes from greater mastery of the fundamentals, not in mastery of the arcane. A high-caliber programmer isn't defined by their ability to code what others cannot (using higher level functions, advanced functional programming, what-have-you) but rather in their ability to refine perfectly mundane coding. Choosing the appropriate decomposition of functionality between classes; building in robustness; using defensive programming techniques; and using patterns and names that lead to greater self-documentation, these are the bread and butter of high-caliber programming.

Writing good code that you, or someone else, can come back to in a week a month or a year and understand how to use, modify, enhance, or extend that code is crucial. It saves you time and mental effort. It greases the wheels of productivity by removing roadblocks that you would have stumbled over before (perhaps interrupting your train of thought, or perhaps taking hours or days of effort away from other work, etc.) It makes it easier to concentrate on the hard problems, and sometimes it makes the hard problems go away.

In a word: elegance. Every class, every method, every condition, every block, every variable name: strive for elegance.

Wedge
  • 270
  • 1
  • 5
6

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

pramodc84
  • 1,803
  • 23
  • 23
Brian R. Bondy
  • 7,067
  • 32
  • 53
5

Data structures

Maniero
  • 10,826
  • 14
  • 80
  • 133
5

How to use Google

bbonamin
  • 101
  • 3
4

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

Federico klez Culloca
  • 3,092
  • 24
  • 24
4

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.

l0b0
  • 11,014
  • 2
  • 43
  • 47
4

How to accurately estimate how much time a feature is going to take to implement. More importantly, how to convey you're not bullshitting when you submit that estimate.

wheaties
  • 3,584
  • 22
  • 23
4

Coding style matters:

  • consistent indentation matters,
  • consistent use of white space (e.g. around operators) matters,
  • consistent placement of { } s matters,
  • well chosen identifiers matter,
  • etc.

... and good design matters.

Ideally, the programmer learns these things before (or during) his/her first code review. In the worst case, the programmer learns them when the boss tells him/her to make some non-trivial changes to some horrible code in a hurry.

Stephen C
  • 25,180
  • 6
  • 64
  • 87
3

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.
red-dirt
  • 3,668
  • 1
  • 22
  • 26
3

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

Paul Nathan
  • 8,560
  • 1
  • 33
  • 41
3

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)

2

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.

doppelgreener
  • 1,274
  • 17
  • 26
2

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.

JD Frias
  • 401
  • 3
  • 8
2

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.

makerofthings7
  • 6,038
  • 4
  • 39
  • 77
2

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.

Jimmy Collins
  • 1,328
  • 9
  • 15
2

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

hplbsh
  • 137
  • 3
2

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.

2

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.

aqwert
  • 499
  • 2
  • 6
2

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

xofz
  • 345
  • 2
  • 10
2

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.

2

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.

1

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
Tyler Egeto
  • 101
  • 5
1

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

Ripped Off
  • 3,757
  • 3
  • 21
  • 24
1

Test like you fly, fly what you tested.

Daniel Grillo
  • 337
  • 1
  • 12
1
  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
adolf garlic
  • 1,061
  • 7
  • 10
1

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
1

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.

Pablo
  • 827
  • 1
  • 8
  • 12
1

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.

Amir Rezaei
  • 10,938
  • 6
  • 61
  • 86
1

How to write a FizzBuzz program.

CtrlDot
  • 101
  • 3
1

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

1

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.

Adam Bachman
  • 1
  • 2
1

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.

user2040
  • 1
  • 1
1

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.

Lou Franco
  • 244
  • 1
  • 4
1
  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
1

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?
tonylo
  • 421
  • 3
  • 6
1

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

1

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.

Jonathan Hendler
  • 101
  • 1
1

There is no crying in programming!

Billy Coover
  • 101
  • 4
1
  • Binary with basic understanding of signed and unsigned.
  • Understand how any positional numeral system works.
  • Understand how basic data structures are stored in memory.
Michał Piaskowski
  • 140
  • 3
1

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

Rayne
  • 999
  • 7
  • 10
1

write code for people!

no more magic number!

don't write all code in one line!

linjunhalida
  • 139
  • 7
1

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

stimpy77
  • 170
  • 3
  • 10
0

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.

  • That seems backwards to me, if you say that a programmer needs the skills of a software engineer :) – haylem Oct 20 '10 at 04:18
0

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.

haylem
  • 28,856
  • 10
  • 103
  • 119
0

My first vote would be for Naming Conventions.

Gopi
  • 3,113
  • 1
  • 24
  • 30
  • 1
    Unfortunately this *IS* the first thing people are often taught, and something they probably ought to NOT be taught. – JohnFx Sep 09 '10 at 16:20
  • Agree in principle with JohnFx... but to clarify, if it's so important, your tools should manage it. (It is important in most languages, and yes, I let my tools manage it). – MIA Sep 16 '10 at 01:01
0

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

Yevgeniy Brikman
  • 2,565
  • 1
  • 22
  • 23
0

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.

vpit3833
  • 1,330
  • 8
  • 11
0

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

0

How to do it.

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

Randall Schulz
  • 1,902
  • 10
  • 8
0

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.
AareP
  • 369
  • 1
  • 7
0

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

Dan Goldstein
  • 101
  • 2
0

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

Jonathan
  • 207
  • 2
  • 5
0

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

Stan Rogers
  • 129
  • 3
0

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

sharjeel
  • 101
  • 1
0

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.

0

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.

neves
  • 101
  • 3
  • "Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems." -- Jamie Zawinski – Jimmy Collins Jan 16 '11 at 12:30
0

Every programmer should know how a processor works.

Brian Makin
  • 101
  • 2
0

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

FreeMemory
  • 135
  • 2
0

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.

0

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.

0

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.

zkarthik
  • 101
  • 2
0

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

0

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.

0

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

nickik
  • 494
  • 2
  • 7
0

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

tcrosley
  • 9,541
  • 1
  • 25
  • 41
0

Program with maintainability in mind.

Jesse
  • 273
  • 1
  • 10
0

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.