What every beginning programmer should learn

Are you the kind of person who enjoys thinking about this kind of stuff?

Then seek therapy immediately!

Or, just for fun, consider this…

A young programmer, fresh out of computer programming school and still wet behind the ears, asks you — tough old seasoned professonal software developer that you are — for suggestions for things that he/she should learn in order to become as tough, as old, as seasoned, and as professional as you. What do you tell him/her?

Here is a jumbled grab-bag of concepts, jargon, ideas, resources (books), etc.  Basically, a list of the tools in the toolbox of a working business software developer.  Or at least, the first cut at such a list.

If this was YOUR list for a beginning programmer, what things would you add to it, or change?

relational database concepts

data modeling (entity-relationship modeling)

  • Chen-style (relationships shown as nodes)
  • Information Engineering (IE) style (relationships shown as lines)

data-driven program design

  • “Principles of Program Design” by M. A. Jackson
  • “Jackson Structured Programming: A Practical Method of Programme Design” (Paperback) by Leif Ingevaldsson

software requirements and specifications

  • “Structured Analysis and System Specification” by Tom Demarco & P. J. Plauger (Paperback 1979) Data flow diagrams can still be useful tools in certain contexts, even though they are obsolete for software systems analysis.
  • “Software Requirements and Specifications:” by Michael Jackson     STRONGLY RECOMMENDED
  • “Problem Frames” by Michael Jackson

object-oriented programming

  • class, object (or instance), method, static method, instance variable
  • “Beginning Java Objects” by Jacquie Barker

domain-driven design

  • “Domain-Driven Design” by Eric Evans

event-driven programming

data structures and algorithms

  • variables (in non-object oriented languages), objects (in object-oriented languages), pointers (references)
  • stack, queue, LIFO, FIFO, linked list, tree, node (and how to program them)
  • recursion (for traversing trees)
  • “Thinking Recursively” or “Thinking Recursively in Java” by Eric Roberts

process modeling, entity life-history modeling

  • finite-state machine (FSM) and state-transition diagrams
  • “Software Engineering Fundamentals: Jackson Approach” (Paperback) Leif Ingevaldsson

popular software design methods/tools/ideas

  • UML and its various diagram types
  • design patterns —  “Head First Design Patterns” might be a painless introductory book

software development management

  • iterative/evolutionary development (as opposed to “big bang” development)
  • “waterfall” methods
  • “agile” methods

programming languages

  • Dynamically-typed language: Python (or Ruby)
  • Statically-typed language: Java (or C#)
  • A good IDE (Eclipse: don’t try to program Java without it!)

added January 5, 2010

propositional logic (to help with those tricky if-then-else tests)

  • and, or , negation, material implication
  • truth tables
  • modus ponens, modus tolens, de Morgan’s laws
  • proof, reductio ad absurdum

sets and set theory

  • set, set membership
  • union, difference, intersection (and Venn diagrams, of course)
About these ads

19 thoughts on “What every beginning programmer should learn

  1. The first question I’d ask is, “Why?”

    There’s too much technology to learn it all. Having an indication of what they want to accomplish will help you put the right tools in their hands.

  2. I would recommend reading only this book: Code Complete: A Practical Handbook of Software Construction.

  3. Learn Python, a Version Control System, and Test Driven Development. Then participate in a couple of open source projects.

  4. 1. I would add, as the first item, “The Pragmatic Programmer” by by Andrew Hunt and David Thomas.

    2. At the end, point out that your list, to a large extent, provides a grounding in a list of tools and techniques that may serve a programmer well. But, to a large extent, it is only real experience that will allow you to become proficient in selecting the right tool(s) for the job.

    3. Bearing point (2) in mind, expect to make mistakes, embrace and learn from them.

    Also, I would imagine presenting a fresh young programmer with the above list would prove extremely daunting. In practice, you need to mentor said programmer and provide additional wisdom of experience as each occasion demands.

    Finally, emphasize that you too are still learning – good “tough, old, seasoned, professional” programmers never finish their education.

  5. What should beginning programmers learn? Here’s a few things that come to mind:

    Learn the business. Programming is fun. But you can’t beat building systems that meet or perhaps even exceed users’ expectations for job satisfaction … and job security.

    Learn to network. Find people in your organization or your field of interest who know what they’re doing. Ask them how they do it and what turns them on. Join a local special interest group in a problem area that interests you. Read some decent blogs.

    Learn the difference between (A) understanding problems and (B) solving problems. The correct sequence is (A) then (B).

    Learn how to think and write clearly. One of the things we learned in the old days was how to make useful descriptions of process components, data structures and data elements called data dictionaries. The best dictionaries had clear, concise, indexed descriptions and were revised frequently, often daily during development. Everyone on the project was expected to know what was in the current dictionary and to provide constructive feedback. The best teams typically had the best data dictionaries. And they built the best systems.

    Learn how to do decent unit testing.

  6. hmm .. have to admit i pretty much disagree: i just answered this and my standard reply is: read philosophy and follow philosophy blogs: basically learn how to think and form arguments and analyze arguments .. all the rest is technical. (heavily quialified w/ IMHO and i suppose i am in the wrong profession?)

    • Databases are huge, but not necessary. I get on fine without designing them.
    • Ditch the data modelling, requirements and specs.
    • Keep and practice the OO and then forget the “rules” and just write C.
    • I have no idea what domain-driven design is so ditch that.
    • Forget event driven design because once he reads one handler he’s going to get it.
    • Keep the data structures and algorithms class, because it makes you code, but not in Java.
    • Keep process modeling, make sure he at least knows what an FSM is, but no more.
    • Ditch anything that says UML because it’s for people who want to feel like they are programming but are too lazy to just write the code!!
    • Read all software development management concepts just for fun, but when it’s payday create your own.

    Programming Languages: C and Python are great to start, but be able to take on an arbitrary new one, or even create a new one, at any given moment.

    So speaks the old, wise one.

  7. I suggest that the new developer should start with the domain and work back to programming.

    There are no UI or web books in this list.

  8. Somewhere along the line – fairly early – there needs to be an introduction to the low-level concepts and systems architectures.

    CPUs (registers, memory, assembly language, IO)
    Data storage (file systems)
    Networking (the ISO model as concepts, TCP/IP as implementation)
    Networking protocols (HTTP primarily, but exposure to the fact that the whole world of networking does not revolve around the World Wide Web!)

    I can’t count the number of programmers I’ve encountered who don’t understand the difference between what happens on a server (PHP, Java, etc) and what runs in the browser (JavaScript) – and how that affects the data being used on both sides.

    I’d also drill on basic math estimation techniques for off-the-cuff estimates regarding capacity planning and throughput calculations. (“You want to move 10Gb of data through a T-1 line every night???”)

  9. I’d tell them to make writing code their priority, not reading books. I read lots and lots of books, but I spend more time coding than reading. Participation in open source projects is highly recommended. Reading code is highly recommended. Learning to ask smart questions is highly recommended. Most everything else is about time/experience. You can get a heads up on some things from books, but you can’t really internalize and fully absorb things without experience.

  10. A colleague sent me this email. I thought it was worth posting as a comment.

    The comment about The Pragmatic Programmer is spot-on. This book, (the success of which launched a publishing company) is twelve years old (!) yet still provides the best advice (in my opinion) for a young programmer.

    The reason why it remains current is that it doesn’t focus on technologies, but instead on the craft of software development. This is the important stuff they don’t teach you in school, which I can attest to, having interviewed many fresh-out-of-college candidates.

    Some of my favorite pearls of wisdom from the book (the book elaborates more on each topic):

    Care About Your Craft
    Why spend your life developing software unless you care about doing it well?

    DRY—Don’t Repeat Yourself
    Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

    Program Close to the Problem Domain
    Design and code in your user’s language.

    Always Use Source Code Control
    Source code control is a time machine for your work—you can go back.

    Don’t Panic When Debugging
    Take a deep breath and THINK! about what could be causing the bug.

    Refactor Early, Refactor Often
    Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

    Test Your Software, or Your Users Will
    Test ruthlessly. Don’t make your users find bugs for you.

    Don’t Gather Requirements—Dig for Them
    Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.

    Abstractions Live Longer than Details
    Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.

    Don’t Think Outside the Box—Find the Box
    When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”

    Don’t Live with Broken Windows
    Fix bad designs, wrong decisions, and poor code when you see them.

    Design Using Services
    Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.

    Test Early. Test Often. Test Automatically.
    Tests that run with every build are much more effective than test plans that sit on a shelf.

    Find Bugs Once
    Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

  11. Regular Expressions! If you ever deal with text, you’re going to need to know how to find and replace stuff with concise maintainable code.

    XML — I’m not a big fan but it’s hear to stay. Know how to serialize and deserialize objects to and from XML, and how to query an in-memory representation of XML.

  12. No books, just tell them to spend some time in program maintenance then write every program like you have to maintain it!

    – Paddy.

  13. Scott Meyers, “Effective C++.” This is *the* book to read to learn C++, and OO generally.

  14. Terry Halpin, “Information Modeling and Relational Databases”, Second Edition, Morgan Kaufmann

    Read everything you can about Haskell (an advanced, purely functional programming language; http://www.haskell.org); there are many good books and papers on Haskell.

    Bo Sanden, “Systems Programming with JSP”, Studentlitteratur AB, Chartwell-Bratt Ltd. (Here, JSP abbreviates “Jackson Structured Programming”)

    Rabhi and Lapalme, “Algorithms: A Functional Programming Approach”, Addison-Wesley

    Michael Jackson, “Software Requirements & Specifications”, Addison-Wesley

    Michael Jackson, “Problem Frames”, Addison-Wesley

    Daniael I. A. Cohen, “Introduction to Computer Theory”, Wiley

    John Cameron, “JSP & JSD: The Jackson Approach to Software Development”, 2nd Ed., IEEE Computer Society Press

    Various books on discrete mathematics

Comments are closed.