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.
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.