18 thoughts on “How to become a good programmer

  1. Re: your tweet on Joe’s observation about build tools. The Java build stack is a brute. When I see people put “Java” as a skill on their resume my first instinct is to ask them how long their last Ant file was.

  2. A very simple question I want to ask is… When you find a simple algorithm to solve some problem and you do it using some programming language… does that makes you a good programmer or a good-problem solver ???

  3. If only. Not everyone is conscientious or diligent enough to become a good programmer, no matter how many years of experience they acquire.

    Experience is about taking advantage of opportunities. Finding an unusual defect in a program, then digging down to find out what the cause is and digging below that to find the root cause, then figuring out how to not just fix that defect but to fix the design to eliminate that entire class of defects, then figuring out how to change your development process to reduce or eliminate such defects, etc. Learning more and growing with each level down the rabbit hole.

    But not everyone does that. Some developers learn to pass the buck along. Or they learn the old “mutate until the bug goes away” trick. The same is true for every skill. Not everyone who paints, or cooks, or writes, or makes music, or codes becomes a master, regardless of years of experience.

  4. Wedge: Bill Gates said that he could tell after a year what kind of programmer someone would become. You can tell early on in someone’s career whether they have basic talent and whether they want to keep learning. Maybe it takes more than a year — some people start out with enthusiasm and later decide they’ll just coast — but I agree you usually tell early on where someone’s going.

    As far as years of experience, there’s a saying that when someone says they have 10 years experience you should ask whether that’s really ten years of experience or one year of experience repeated 10 times.

    The thing that struck me about Armstrong’s advice was “forget about the tools,” not the 30 years part. The best developers use sophisticated tools to do more quickly what they know how to do manually. But mediocre programmers use the tools as a way to avoid understanding what they’re doing. That’s OK for a while, as long as they stay on the “happy path” that the tool supports. But after a while they confuse the tool for the task. They’re unwilling to think outside the patterns the of the tool and they are helpless when something goes wrong.

  5. This is the exact approach I took 19 years ago. I used to write programs on paper prior to enter them in text editor. I learned the basics of programming, algorithms and data structures and never looked back. A good book, a text editor and creative thinking on how to use a particular language feature is all you need, all other things are optional.

  6. Truth (and that capital “T” wasn’t just ‘cuz the word “truth” was initial in the pseudo-sentence)! I agree entirely that tools have zip to do with languages and can in fact be positively obfuscatory to learning languages (saw lots of COBOL programmers fail to learn Java when required to use Visual Age as their IDE). Further to echo some previous points, there’s a BIG difference between necessary and sufficient. Mr. Armstrong’s an optimist.

    A humorous analogy I encountered long ago is that programming is like explaining procedures to a fast, stupid, one-armed person. Computers are incomparably fast and similarly stupid – they follow instructions without exception at whatever speeds that cable properties permit. As for the one-armed aspect:

    Programmer: Put the value 3 into variable A.
    Computer: Discards current value from A, replacing with value 3.
    Programmer: Now put the old value from variable A into variable B.
    Computer: Old value?

    I’m slow – I’ve been at this since ’69 and am only just gettin’ there. I’ll try to salve my disappointment with my performance with the knowledge that I’ve only been doing it as a my sole, full-time profession since ’95.

    On the more serious side, I suggest that serious explorations of multiple languages and methodologies can accelerate the process.

    Your remarks to Wedge about tools, remind me much of what I see in contemporary attempts to employ frameworks…if the programmer can’t do it without the framework, duck!

  7. But after a while they confuse the tool for the task.

    That’s so true for statistical languages as well. For a while SAS used to define the subject and for some people methods didn’t exist if they were not implemented there.

  8. Luis: Good point about statistical languages. I’ve run into a couple variations on that.

    First, people confuse a scientific task with their favorite statistical method for carrying out the task. When you propose a different method, they don’t know what you mean.

    Second, people confuse an algorithm with what the algorithm is computing. I’ve had numerous conversations in which someone couldn’t understand that I’d computed what they needed because I’d done so in a way they didn’t expect.

  9. How can one become a good computer programmer and a good computer user? My reasons for this, is due to my less reading and always what I want to involve myself in is practical, and also, I have a knowledge about the practical, and don’t even have what to practice with, and my CCNA and ORACLE tutor advised that I must read, to become a good networker, but presently am studying computer engr. And I see myself loving NETWORKING*, what should I do? Am confused.

Comments are closed.