10 years, and never missed a day

On May 31, 2000, I formally left United Technologies Research Center and joined the Golden Consulting Group (now BIT Advisors) as a full-time technical trainer.  I’m posting now to celebrate the fact that, having just passed my 10th anniversary at a technical trainer, I’ve still never missed a day. 🙂

I spent almost 12 years at UTRC.  The first eight were as a research scientist, where my specialty was theoretical and computational analyses of the aerodynamics and aeroacoustics of jet engines.  It all sounds pretty impressive, at least when it worked.  If you look, you can still find some papers I wrote or co-authored, through Google Scholar.  My work at the time consisted almost entirely of lots of math and lots of FORTRAN (shudder).

I was never that wild about research.  I liked the actual investigating part, and I liked presenting results and explaining what they meant, but I hated all the begging for funding.  That’s actually how I wound up at UTRC in the first place — I planned to be a professor, but I thought if I went to a research laboratory I could build up my resume and publications list and then later join a university somewhere.   Unfortunately, the market for professors fell apart soon after I joined UTRC.  A year later I was married to a local girl, too, so I wasn’t able to move to wherever the opportunities might be.  Sigh.

I was always an awkward fit in engineering.  I never took things apart or put them together as a kid.  I liked the science aspect, but never really felt comfortable as an engineer.  I always wanted to move away from FORTRAN, too, which was problematic because I naturally didn’t want to write my own numerical analysis libraries.  Eventually, though, I discovered Java back around version 1.0.6, and started learning that.

Around the same time, I made a friend at UTRC who ran an Artificial Intelligence group.   After some discussion (and the fact that the acoustic funding dried up), I joined his group and started learning about neural networks and genetic algorithms.  Unfortunately, I also realized that about fifteen years of coding in Fortran hadn’t taught me anything about modern software development.  So I went back to school at night at Rensselaer at Hartford and got my MS in Computer Science.  I also became a Sun Certified Java Programmer along the way.

During the spring of 2000, when I started interviewing, I found that I could either work for a consulting firm as a developer (back then having the SCJP certification was hot), or I could join a training company and teach technical training courses in business and industry.  It came down to two job offers at the time.  I’ll always remember my dinner-table conversation the night I made my decision.

Me: I’ve decided which job to take.

Xander (my son, age 8 at the time): Did you take the one that had more money, or the one that you liked?

Out of the mouth of babes. 🙂  I’ve always been pleased to say that I took the job I liked, and I’ve never regretted that decision.

After five years with Golden, I eventually went out on my own.  I’ve now been an independent trainer for five years as of last March, as the owner (and sole employee) of Kousen IT, Inc.  I’ve learned a ton along the way (sometimes I shudder to think about how little I knew when I started) and still love what I’m doing, especially when it involves Groovy or Grails.

One notable achievement, as I mentioned at the beginning of this (way too long) post, is that I still haven’t missed a day.  There are roughly 20 or so training days available in a given month, and a typical trainer tries to schedule between 10 and 15 of them.  How many depends on the length of individual classes (a two-day class often wipes out a week, because it’s very hard to find a three-day class that will fit into the remaining slot), but you don’t want to teach too many in a given month or you get tired and nothing good comes of that.  I tend to average about 120 to 150 days a year, so conservatively I’ve taught about 1200 days during that time.

Some of that is luck, of course.  I’ve certainly been sick enough that if I’d had a class scheduled, I couldn’t have made it.  Also life tends to intervene, with family illnesses and the like.  But so far, so good.  I’m rather proud of that, actually, and hope to keep the streak going as long as possible.

My wife is very happy I made it, too, partly because now I’ll stop obsessing over it.  Over the last few months I grew increasingly paranoid that something would happen to cause me to miss a day, but fortunately it never did.

Maybe I’ll see you in a class someday.  If so, the odds are very good that I’ll be there the whole way. 🙂

My approach to academic teaching

I recently read a fascinating post by Joel Spolsky entitled “Capstone projects and time management”.  It’s highly opinionated, as usual, but makes several interesting points about teaching computer science in academia.

He basically claims that academic computer science doesn’t teach you to use modern tools, or do version control, bug tracking, teamwork, planning, etc., etc., etc.  He repeats his frequent assertion that the academic world is almost completely divorced from the real world of software development.

I imagine he’ll get a ton of responses to his post, which is fine.  Somebody needs to whack the beehive every now and again, and I’m glad this time it won’t be me.

(I’ve been bumping into beehives lately, which is unfortunate.  I like causing trouble, but I hate getting into trouble, and I’m doing way to much of the latter.  Maybe it’s my premature entry into curmudgeon-hood.  Ginger thinks it’s way too early for me to be turning into such a grumpy old man.  But, you kids, get off my lawn!)

At any rate, most people who follow my blog are aware that my regular job is teaching software development training courses.  Roughly once a year, though, I get to play at being a professor at Rensselaer Polytechnic Institute in the Education for Working Professionals program in Hartford, CT.  That’s formerly Rensselaer at Hartford, formerly the Hartford Graduate Center.  In the late ’90’s I got my MS in CS there, at night, while I was transitioning from my career as a research scientist into my current business.

I teach a class called “Developing Enterprise Applications”*

*So all of our programs work on the library computer on a starship (rimshot).

The basic idea is that I try to show the students the current state-of-the-art in software development, based on my experiences.  Since I teach a lot, I can travel to 20 to 40 different companies a year.  That gives me a decent sense of what’s going on around me, along with blogs, podcasts, twitter feeds, and participating in the Groovy and Grails open source projects.

I’ve taught my Rensselaer class about half a dozen times so far, and it’s been completely different each time.  Most recently I taught it last spring (2009).  We talked about Spring and Hibernate, used a Subversion server to check in code (actually a Google code project, but that’s the same thing), ran lots of JUnit tests, added Ajax capabilities with prototype and script.aculo.us, and briefly went over, of course, Groovy and Grails.  I write code during class which the students are free to use, and I keep notes on Google Docs, which I share with them.

Here’s the cool part, though.  There are no assignments, no exams, and no homework of any kind, with one exception.  At the end of the course, the students have to present an application they’ve written to the rest of the group.

The choice of project is completely up to the individual student.  I do give them a list of requirements, which are negotiable until about half-way through the semester.  Here’s a portion of this years’ list:

• Use a framework (Struts, Spring MVC, JSF, Grails, RoR, or other)
• Create an ORM layer (Hibernate, JPA, roll-your-own)
• Test as much as possible (unit, integration, functional)
• Ajax capabilities are a plus
• Do something with web services (REST or SOAP; at least consume, generate if possible)
• View templates are optional but preferred (Velocity, Freemarker, Sitemesh, whatever)

I’m quite flexible on the actual implementations, as long as the student clearly learned something and the implementation has some value.  Students can write in Java (most of my demos are in Java, so that tends to be a favorite), or .Net, or anything else they prefer, as long as they try to fulfill the requirements above.

My favorite requirement, however, is the Design Document.  This is very important to me because I want the students to tell me what worked, what didn’t, what they liked, and what they didn’t.  I want this to be a low-pressure opportunity to experiment, and if they’re truly experimenting, then not everything will succeed.  I want to know what they tried, even if it failed.

I do ask that one use case has to work.  I’m fine with experimenting, but there’s nothing like working code to motivate you.  Students (like most developers) tend to way overestimate how much they’ll actually finish, though, so I only ask for a single case to function correctly.

Regarding teamwork, I allow them to work in groups of one or two only.  My experience has been that groups of three or larger don’t finish in time, or one student winds up doing too much of the work.  I like the idea of doing a team project, but I haven’t figured out a good way to manage it yet.  Two person teams tend to work, both in scheduling and production.  Most students prefer to work by themselves.  I’m fine either way.

During the last class, each student (or group) hooks up their laptop to the projector, demonstrates the application, and then walks through the code.  I bring the donuts and coffee, and we all watch together and ask questions.

Then I give out the A’s.  If you clearly tried something ambitious, and you clearly learned something, and you fulfilled the deliverables above, then why not?  I only give out A’s and F’s, and the latter only happens if a student clearly left everything until the last minute, never came to class, and then tried to snow me with a rushed project.  My rule of thumb is that if I could do your entire project in a couple hours, you didn’t do enough*.  I get a student like that about once every other year.

*Of course, I have to pretend I don’t know Grails when I say that…

I find this a very easy, successful way to teach, and the students seem to like it too.