What Software Engineers Don’t Learn in School

[youtube http://www.youtube.com/watch?v=6vqfcr6YeKk&w=560&h=315&wmode=window&h=315]

If you’re just starting out as a software engineer, you probably have a college degree. You’re probably a reasonably good coder and know something about software systems.  But: There are a number of skills they don’t teach you in school. Here’s some of them.

12 Responses to “What Software Engineers Don’t Learn in School”

  1. You mentioned: ” There are a number of skills they don’t teach you in school. Here’s some of them. “However, you did not list a single one!

    Also, it should be “Here are” some of them. WOW, a manager who does not know how to differentiate plural from singular. Contractions are not good writing either; instead of “don’t” is better to write “do not”.

  2. Great Job! I really like how you through design in there! I recently started learning objective -c and went build out my first mobile app and wow – I am not as good at design as I had thought. I am now taking the steps to learn basic design principles as you had mentioned. Great job, I look forward to Dice TV more and more these days.

  3. As an experienced software engineer I think you are dead on. People also need to leave their egos behind and accept new ideas to create the best product possible. Focus should always be on what your customer wants.

  4. Cat Miller

    @CICUTA – There are indeed a number of skills they don’t teach you in school and the ones that are the focus of this video are listening, testing, working in teams, and design. They’re not listed in the copy below the video, but they are listed and elaborated on in the video itself. Speaking of the copy below the video, you are correct! It should be “here are” and that’s our mistake! Oops! As for contractions, I “don’t” mind using them at all! I think “it’s” a matter of style, but as long as “they’re” grammatically correct I “can’t” see a problem! Thanks for tuning in!

  5. Listening is a great skill for anyone, not only “software engineers”.

    “Testing is finally gaining importance …”. ROFL. Did no one ever test the code written in school? Apparently I, and most of the folks with whom I have worked since the early/mid 1980s, was/were ahead of the curve. We tested the living daylights out of code.

    I can only conclude that the rise of the MEllenials, who are too frequently plugged into their iPuds to listen, and probably convinced their code is error proof, have led to the demand to learn how to listen, and to test code.

    • Mike, I am sure everyone did basic testing of code in school and on the job for decades. However, all of that testing has historically been done by people. The growth of automated test infrastructure like unit test frameworks and continuous integration build servers are an important change to the art of software engineering. They certainly did not exist when I was in school.

      For accidental overwriting, that does not happen nearly as much with good, modern version control systems (GIT, SVN, etc). However, users still have to merge the code more or less manually, so there is room for error, especially if you have not checked in recently.

      A related problem is making design decisions that don’t work with other peoples code which can’t really be fixed with technology. At least not so far.

      • “A related problem is making design decisions that don’t work …”

        A related problem is persons describing software, or making decisions, with no idea how an existing app, or system, works. More than once I sat in meetings listening to clueless describe a process, or claim changes could be made with no problem.

  6. Thanks for the video. I think it’s dead on. I progressed from Technical Writer to Sr. Software Engineer (systems analysis / database) by virtue of the skills you listed more than technical knowledge. My degree is an MA in Communication, although I did well in programming courses. Along the way I’ve met many engineers (young and old) that fit your description.

  7. Carl Lorentzen

    For 40 years, I preached and practiced “If you haven’t tested (whatever) you must assume that (whatever) doesn’t work”. Simple. Straightforward.
    This works equally for house keys, credit cards and automobiles.