I’m Old, Part LXII: College CS Value

I recently saw this tweet from Stephanie Hurlburt:

I have a 4-year CS degree, it helped me get my 1st job (via referral from my professor), but the actual education was not useful or worth it

And I won’t argue with her on that. Her experience was her own. More than anything else, I would like to hear more detail of her experience and how it could be improved.

I went to Oberlin for CS. At the time, it was a very young program and only became an actual major while I was there. I was the 5th student to declare.

Up until my third year, I would agree with Ms. Hurlburt. The classes that I took during that time were only putting names on things that I invented myself or encountered in the wild. That changed more in the 300 level classes and some of the 200 level classes. Some of the classes have been no use to me. Discrete Structures was super cool – I really liked the notion of being able to treat programming language elements as mathematical entities and subject to proofs of correctness. For day-to-day engineering, I’ve had no application of that.

There were some game changers (in no particular order):

  • Compilers – this class kicked my ass, but I learned a hell of a lot from it including how to design a decent, easy-to-parse Domain Specific Language. I learned how to write a tokenizer, scanner, and parser. As a professional, I’ve implemented compilers/interpreters for 4 languages, including one that was specifically not subject to the Halting Problem. It also taught me how to decompile assembly back into a high level language on sight. In my current job I need this skill frequently.
  • Theory Of Computer Science – this was a class on automata theory. Finite state automata have been hugely useful in my professional career. A decade ago, I wrote a PDF parser that included an FSA running the tokenizer and another running the interpreter. At one job, I designed an AI scripting language for a game engine that used a state machine as the central control flow.
  • Algorithms/Analysis – making something work is only part of the job. Making it work well is where this comes in and needs to be in the wheelhouse of every software engineer. It also reminds me of the time I was reworking some code in Acrobat and I found a chunk of code to do string comparison that was O(n2). That was an easy fix.
  • Functional Programming – one of the professors did a seminar class on functional programming based on Simon Peyton Jones’ book The Implementation of Functional Programming Languages. Having the background in FP made it much easier to make the decision to use F# as the main language for creating a pure managed, performant .NET graphics library port of a C++ version.

One thing that wasn’t in my CS program, is practice in communication and writing. If you’re going to work in a group or have your work made public, you need to be able to write clearly.

I don’t think that any particular class got me a job. In fact, I know that even the things in my CV had little impact on my first full-time job out of college at Adobe. I had a boatload of Macintosh coding experience and figured that was what I was going to be brought in to do. Nope. PostScript printer engineering – embedded systems. I didn’t know PostScript. I didn’t know what an ICE was. I didn’t really know hardware, but I ended up doing/working with all those things.

I’m Old, Part LXI: Feed Your Troops

When I was teaching/running district tech, the principal at the school had a piece of paper taped to the file cabinet next to his desk which had a list of things to do to help build a team. One of the items was “Feed Your Troops”.

At Atalasoft, that was a thing that we did figuratively as well as actually. The picture above is a cake that Christina Gay got for the office for my birthday one year. I returned the favor by making her a cake for her birthday with a hand turkey on it, since her birthday is close to Thanksgiving.

We also routinely had pizza lunches, beer o’clock on Friday, and the occasional bacon day (I’ll save that story for another day). This is the actual feeding of the troops. The figurative was another thing entirely.

Lou Franco and I had a problem in that he and I were the most highly experienced engineers at the company and we had a decent number of talented junior engineers and a few moderately experienced engineers. The problem with that is that we needed more engineers in the moderately and highly experienced bins. The solution to that is time and opportunities. Not every engineer has the time (or thinks they have the time) nor are there are always opportunities.

Lou had a great idea, which was to do some lunchtime seminars. He chose the topic of the GoF design patterns and rather than do a presentation each week himself, he assigned a pattern to one of our junior engineers. The engineer would have to explain the pattern and how it worked and also where it was used in our code base. Some engineers took the task seriously and presented in depth. Some engineers clearly had just copped the wikipedia page. The fun part was the “where is it in the Atalasoft code base” portion. After the junior engineer did their bit, one of the more experienced engineers would list off the other places it was. Funny thing, before these presentations, I had never known the GoF patterns under their names. This is partly because I independently invented most of them at some point in my career or encountered them reading someone else’s code. They didn’t have names; they were just what you used when you had certain classes of problems. Nifty!

Later, I set up an independent study program where junior engineers picked topics of study and I would would work through it with them. Some of the topics included Scheme, C, and ray tracing in F#. Anything coding related was fair game.

We also did regular company staff meetings where we had a rotating schedule of people who ran the meetings. Very often, the choice of the curator of the next meeting was a game of “not it” but hated or not presenting for a group of people is a valuable work skill. We also tried to set aside time for work or non-work presentations. Sometimes they were technical, sometimes they were show and tell. They were always valuable.

One thing that I remember talking about with Lou about the overall process was that in a small company like ours, we were free to make our own rules. What do you mean you can’t take time to teach and mentor your cow workers? How can you not? One of the things I liked about Atalasoft was that I felt like I had the opportunity to make it into an engineering organization that I most wanted to work in. Certainly, it had room for improvement and we actively tried to steer things in that direction.

If you take the time to thoughtfully create a structure that is engineer friendly, then your engineers will want to be there, even through the inevitable slog work. If you are actively involved in professional development, you will build a better, more capable team. How do you achieve that? Feed your troops.