14

In order of importance, if its possible to do so and it may not be, what are the most important foundations of knowing how to program. Algorithms, iteration, recursion, etc?

Note that where I put etc. is where my question lies. I recently read an Internet post that said 9 out 10 programmers can't gasp program!

http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

I want to have a deep knowledge of what it is I am actually trying to accomplish when programming and an exhaustive comprehension of the basic tools at my disposal. Basically I want to be able to paint with all the colors of the wind.

Improve this question
4
  • 3
    Jeff Atwood's post isn't really about deep programming knowledge... It's about the reality that many people lack some basic, fundamental insights about programming, and how the lack of those fundamental insights prevent them from developing significant programming skills.
    – Robert Harvey
    Jan 30, 2013 at 7:07
  • 2
    I don't understand why this question was closed. It's a question that has been starred 5 times and has lots of helpful answers. This is the kind of information that I want to come across - just because there's no simple answer doesn't mean the information isn't of good value, perhaps programmers.stackexchange.com needs to re-evaluate it's criteria for closing questions.
    – Rocklan
    Jan 30, 2013 at 22:01
  • @LachlanB I voted to reopen...needs 4 more votes to succeed
    – Michael Brown
    Feb 15, 2013 at 22:02
  • I think this is a good question but any reasonable answer will be too long for the format of this site. Any good university curriculum will cover these concepts, and the fact that such a curriculum takes a few years of dedicated study and practice, followed by additional years working on real projects should make it clear why the answer cannot fit in here.
    – Giorgio
    Feb 16, 2013 at 11:17

6 Answers 6

Reset to default
17

This list is a start... you're asking a big question!

  • How to clarify and write down what the customers wants ("requirements"). This is an art in and of itself. If you can do this, your programming job will be much better.
  • How to estimate and project plan. People will ask you for an estimate, be prepared.
  • How to constructively review other people's code.
  • Design patterns. This is a big one. But don't overzealously use them for the sake of it.
  • Learn the difference between a bug, issue and feature requests
  • Keep up to date with frameworks/libraries. You don't have to use them, but you need to know what they do and their pro's/con's. If something seems way too hard then there's probably (hopefully) a much easier way of doing things.
  • How to document complicated algorithms in a flowchart or just write it out in english. Don't expect that someone will spend 2 days trying to reverse engineer your code.
  • How to organise your code structure so that anyone else can understand it
  • How to comment your code
  • How to write unit tests
  • Know what's going on under the hood. Eg calling a web service - what's it actually doing?
  • How to abstract away logic into classes.
  • How to refactor code
  • Learn the gist of quite a few programming languages. You'd be surprised what you can learn from other areas
  • How to tell other programmers what to write.
  • How to explain to management what you're doing and why.
  • Like Peter said, how to debug. I agree with everything he says, real programmers debug, not just guess.
  • How to work with maniacs. There's a lot of them out there.
  • How to GET STUFF DONE. All the theory in the world won't help you if you can't get stuff done.

I answered another question along similar lines (with similar content) here:

tips, guidelines, points to remember for rendering professional code?

Improve this answer
11
  • 1
    +1: GET STUFF DONE! A couple of years ago I posted a rant that said that this was the defining characteristic of an engineer -- they get stuff done. Sometimes it ain't pretty, and sometimes you will have to go back and redo it, but at the end of the day they get stuff done!
    – Peter Rowell
    Jan 30, 2013 at 6:23
  • @PeterRowell: you might find this an interesting read: brandonsavage.net/when-to-write-bad-code
    – Marjan Venema
    Jan 30, 2013 at 6:58
  • Unfortunately the question isn't really one that fits the Q&A philosophy and format of the site, but that doesn't minimize the value of your answer. If you care to expand it and add a bit of explanation for each point, it will make a great blog post for our community blog.
    – yannis
    Jan 30, 2013 at 9:16
  • @MarjanVenema: Yes, I completely agree with him. Back in the 80's I was tasked with writing a spec for a new editor, to be approved before I started coding. I stared at that damn blank screen for more than a week trying to figure out how to describe something I didn't understand. My manager expressed his displeasure with my lack of progress. After a 3 day weekend he had a draft on his desk. He asked what had happened, and I said that I wrote the editor over the weekend, and then simply wrote a spec of what I had working. I did rewrite some of the code, but it was mostly refactor/cleanup.
    – Peter Rowell
    Jan 30, 2013 at 19:04
  • 1
    @YannisRizos - I'd be interested in writing a blog on this. Would you like to send me an email with any guidelines or should I just write something up?
    – Rocklan
    Jan 30, 2013 at 21:40
21

Under the heading of "etc." comes something which can easily take 50% or more of your time.

Learn how to debug.

This means learning the Scientific Method. I mean really learning it. And then applying it with brutal self-honesty. Learn how to state precisely what you know is true, what you know is not true, and those things which you don't know. Any time you sloppily assign an item to the wrong category, you've just made your life a lot harder.

Learn to say "I think" instead of "I know". You only get to say "I know" when you "think" something is true (or false), and then you prove it!

Many bugs are trivial, but they can be hard to see because you "know" what the code should be ... except it's not. Find a freind to explain it to. Ask them to be an "expert idiot": someone who doesn't know your code, but who you know you can't blow BS past. Don t be surprised if in the middle of a describing it to them you suddenly stop and say, "and so you can ... see ... see that ... sh*t. Thanks."

Nontrivial bugs require an arsenal of techniques. A classic that can quickly spotlight most non-timing related bugs is Wolf Fence in Alaska. There is a wolf somewhere in Alaska; build a fence cutting the state in half. Which side is the wolf on? Cut that side in half. Lather, rinse, repeat. Doing this 20 times at well-chosen places in the code reduces the area where the bug (wolf) can be to 1/1048576. Kill that wolf.

Tip: look for handwaves—physical, mental, or any other kind. As soon as you (or your colleague) flinch / divert / minimize attention paid to a portion of the code, go totally rabid. Because the area where you just know the bug can't be, even though you've spent hours / days looking for the d*mn thing and still can't find it ... that's the highest probability location for the bug. Nobody gets a 'bye', nobody (including the machine, the OS, the compiler, or you) gets any sort of "due respect". There's a bug. Period. End of sentence. Now go kill the d*mn thing.

I know of no school that teaches debugging as a subject unto itself. IMNSHO, this may be the single most glaring piece of evidence that they (universities / professors) are not teaching you to be a programmer, they are, instead, teaching you to be ... like them? Harsh? Perhaps. True? Make up your own mind. Now prove it.

Improve this answer
3
  • You may be interested in the Saff Squeeze, a technique described by Kent Beck which uses tests and refactoring for debugging: Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze by Kent Beck, Three Rivers Institute (Abstract: To effectively isolate a defect, start with a system-level test and progressively inline and prune until you have the smallest possible test that demonstrates the defect.) It sounds very much like your Wolf Fence, using Tests and the IDEs Refactoring capabilities.
    – Jörg W Mittag
    Jan 30, 2013 at 2:15
  • 1
    Great answer - anyone can write code, real programmers debug.
    – Rocklan
    Jan 30, 2013 at 4:13
  • @JörgWMittag: I'm a huge fan of automated regression testing. I first used it on a search engine project back in the mid-80's, and I was shocked (shocked!) at the stuff that would fall out after what appeared to be a "minor" change to some innocent looking piece of code. (Note: this was 200,000+ SLOC of C, and memory management problems were the bane of our existence.)
    – Peter Rowell
    Jan 30, 2013 at 19:11
3

I'm afraid this is a pretty large question for anyone to answer conclusively or authoritatively, especially given that you want a prioritized list. There are lots of programmers out there, and they work on very different things - sure, fundamentals stay the same, but what you need to keep active in your memory can be really different, and indeed there are lots of tasks where you can stay pretty high-level without going deeper.

It seems though that you are genuinely concerned about how to be a better developer, and not just a jack-of-one-trade. I find that admirable, and I can share some of the things that have helped me learn how to program.

Pretty much all of programming boils down to algorithms and data structures. They, in turn, are examples of the larger question - how do we model things and processes from the real world into a representation such that a computer can understand. If you are just starting out, it might be useful to use a higher-level programming language (like Java, Python, whatever) to become familiar with implementing data structures and algorithms.

At a certain point, having played around with data structures and algorithms, you may start getting that gnawing question "but how do we go from telling the computer what to do, to the computer actually doing it?" Then you can look into how a computer actually computes - how memory and the CPU work together to execute instructions, how operating systems abstract the hardware so you can write a program that, say, opens a file, without coding to a particular low-level hard-drive interface.

This is probably a good point to start - how algorithms and data structures model problems from the real world, and how a computer actually performs computation. Knowing the latter is very useful in mastering lower-level languages like C, which utilize far fewer smoke and mirrors than OO and scripting languages :)

Improve this answer
2

YAGNI: "Always implement things when you actually need them, never when you just foresee that you need them."

In my experience, it is common for "programmers" to foresee many cases in the future and try to "improve" the code by adding codes to anticipate them! In most cases the code that they added will just bloat the code and add complexity to the code.

Improve this answer
1

The most important thing to know about being a programmer is that writing code is a grind, and a workmanlike "blue collar" attitude towards producing what you're being paid to produce will get you farther than any esoteric learnings.

Learn to get into the zone. By that I mean the mental state when you're focused only on your task and you can begin to keep a great many things in your head and how they interoperate all at once. Once you're in the habit of getting into the zone at will, start worrying about the rest. Until you can pound out code like some kind of a code pounding out thingy, the rest is virtually useless.

EDIT:

If you don't believe this and you downvoted me I beleive that you do not know if you have the determination to do it for 20 years. I know that I do because I accept this. ;)

Improve this answer
0

A recent question, related in some way to this one, and Answer had a link to This blog which discusses the same problem from a different angle.

Probably the most important concept for any developer is "humility"....Once you accept you don't know it all, you are open to explore solutions. Most of the people who write blogs on programming are in the top percentile, and the problem is many have yet to control their narcissistic tendencies.... which is why they blog..... You need to learn to identify these bloggers and ignore there rants

The linked blog is really nothing more than a rant - In every industry complains that recent graduates are useless are common, that it takes years to get them useful and productive. Perhaps the problem is that these self proclaimed guru's actually expect too much and have forgotten that once they would not have been able to solve FizzBuzz. Not everyone can be in the top 10 percentile, by definition, half of programmers are below average......

Improve this answer
1
  • I agree that people rant a lot, but I think the point of the posts you linked above is that the people who didn't know how to solve FizzBuzz were applying for programming jobs, which is different from just being a beginner and needing to wrap your head around programming idioms. I do agree with you on the point about humility though, and many people seem not to know what that is.
    – RuslanD
    Jan 30, 2013 at 3:33

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