Software engineering and me

Filed under: Programming
3 Comments

I've been programming, one way and another, since I was about eleven years old.

I taught myself a lot, and learned from my father and from friends, and then in college I took Computer Science classes.

And some of those classes weren't just about programming per se. I took a Theory of CS class (which felt more like math than like computers), and a Compiler Design class, and so on.

But I was never actually trained as a software engineer.

And it's finally beginning to get in the way of my work.

The first time I noticed this kind of issue was when I took a graphics class the year after I graduated, while I was working for the college. One of the things the class tried to do was create a graphics library, which made me nervous because (at the time) I didn't have a clear idea of what a library was, despite having been writing code for ten years.

I eventually figured that out. But I've been noticing more of this kind of thing in the past few years.

Possibly the most important thing that I was never formally taught was the idea of a function as a first-class object. When I first encountered callbacks, sometime post-college, I couldn't figure them out. Reading Intermediate Perl a few years ago was my first real exposure to a lot of related concepts, including anonymous functions. I'm still struggling with the idea of closures.

There are a bunch of other common and widely used programming concepts and practices that I haven't had much exposure to and haven't used much. For example:

  • I've done very little object-oriented programming, though I understand the concepts.
  • I think the first time I encountered the term “unit test” was four or five years ago, at my current job.
  • I think I get the general idea of design patterns, but I've never knowingly used one.
  • I understand the idea of the Model-View-Controller architecture, but I haven't actually implemented it.
  • Every so often, I try again to teach myself about the lambda calculus, but my attention seems to just bounce off of it.
  • I have only a vague understanding of interfaces and factories.

And I've never worked on a significant multi-author software project, which may help explain why and how I've never really learned how to do any of the following:

  • Exception handling (error-checking, sure, but I've never written code to throw or catch an exception per se)
  • Instrumenting code
  • Using an IDE (or even using a non-primitive debugger)
  • Using version control for code (I've used it plenty for documentation, but somehow never thought to use it for my own code until Sumana suggested it recently)

I'm sure there's lots more I could say along similar lines, but that'll do.

In short, though I've written probably a few thousand lines of code in my time (which I know is not a lot by professional standards), in probably a dozen different programming languages, I don't have the training or the knowledge to engage in really good software engineering practices.

I'm gradually learning. I've now written a couple of unit-test-like tests, and I'm slowly trying to add a sort of an abstraction layer to the SH story-tracking database system, and I keep reading up on stuff when it comes to my attention. Wikipedia and Stack Overflow and a mailing list set up by friends of mine have been invaluable resources.

But I do kinda wish I had, at some point in college, taken a class on good software engineering practices. It would've made me a much more effective programmer.

I doubt I have the talent or the temperament to have become a professional software engineer even if I'd taken such a class. But learning earlier about how to do this stuff would've made me a better tech writer, and it would've made various code that I've written (especially the SH database) a lot more powerful, robust, and testable.

Wrote most of this entry about a week ago, didn't get around to finishing it ’til now.

Some disclaimers:

I should note that none of this is intended to beat myself up, nor to lament how woefully nontechnical I am (and it's definitely not intended to fish for compliments); I know more about programming than most non-programmers, and I'm not a programmer so it's not surprising that I don't know everything they know.

So nothing here is meant to be a complaint; it's more that I would like to (a) be able to write better and more effective code when I need to, and (b) have a better grasp of the kinds of things that engineers are doing in code that I'm documenting.

I'm also a little concerned that this entry might come back to bite me if at some future time I'm applying for a job somewhere. (I have no plans to leave my current job, but things can change.) So I should explicitly say that in this entry I'm focused entirely on what I don't know; there's lots that I do know, but I'm not talking about that here. And I'm working on learning more about some of the things I don't know.

3 Responses to “Software engineering and me”

  1. Bruce Chadwick

    Jed,

    Remember that a lot of these concepts really developed and flourished (even if they were first imagined earlier) after we graduated from college. So it can be harder to know what is worth keeping up with over time. I see this when I do statistics courses, where people keep mentioning that they tried using some technique which didn’t even officially exist when I was learning stats in grad school. One thing I’ve noticed is that just because younger people have been told about some technique doesn’t seem to mean that they have mastered it any better than I could by picking up a book and concentrating hard for an hour on the subject.

    What would be nice is to go to some place and get a mid-career schooling update on new techniques. Like a professional sabattical but involving something structured for learning rather than just some time off and/or the occasional night course.

    reply

  2. irilyth

    Did our college actually offer classes in software engineering when we were there? I took almost every CS course in the catalog (as a special major, back before it was a standard major), and don’t remember one…

    reply

  3. Nathaniel Smith

    I took a small handful of CS classes in college (like… 2, I think), but mostly learned from hacking on free software stuff online and the occasional foray into a reference book. Comparing my knowledge to that of my peers has left me somewhat skeptical of college CS training in general — it seems like they mostly teach the stuff that you can find in books, and if you can find it in books then there are lots of ways to learn it, it doesn’t require a structured investment of 4 years taking classes, no? But all the “softer” skills of how to think and talk about code that a group of people will be poking at and rearranging and making plans for over a long period of time, and finding effective habits and tool sets… these seem very hard to learn piecemeal, and best learned through more of an apprenticeship model.

    Some of the things that I value the most:

    • Reading code (much more so than writing code) — e.g., given an unfamiliar code base, how quickly can you find and decipher the algorithm it uses to do X?
    • The break-it-into-pieces-and-test-all-of-them mentality (i.e., unit testing)
    • The ability to envision and *then describe* an overall system in such a way that other people will be able — feel compelled, even — to go implement the pieces.
    • Closely related, the ability to lead a technical culture. This is hard to describe, but what I mean is… setting technical values, like “around here we worry most about robustness”, or “around here we worry most about having a clean OO design”, etc. This requires having ‘taste’, which is also hard to teach…
    • Editing. Just as important for code as for prose. (They call it “code review”, but we know the truth.)
    • YAGNI.

      Not sure if this brain-dump is helpful — I’m mostly thinking out loud. If I were giving advice to someone whose goal was just to be the best programmer they could — so this may or may not be applicable — then probably the most important point would be the first one. I’d say, go read as much code as you can! Pick a small bug in some random OSS project and figure out where it is, pick some project that does something you find vaguely impressive and ‘above your pay grade’ (like a database or something) then go figure out how it actually works, figure out how one writes a wireless driver or a library linker, whatever, just read as much code as you can.

      I guess basically that’s the same advice people give to writers, now that I think about it…

      reply

    Join the Conversation