Wednesday, 7 September 2011

Tiger Stripes

Guthrie and I settled in at Tigerland fairly quickly. We were given a number of small problems to solve, and these would be rigorously code-reviewed by the senior developers before we could check them in. Sometimes they'd send me back two or three times before I solved the problem to their satisfaction.

I subjected Meggs, who sat nearest to me, with a constant barrage of questions. How should I implement this? What did it mean? What was the best approach? What impact would it have? He answered all of them with patience, and I sucked the information up like a sponge.

Guthrie and I had a few problems when I came to procedure. Neither of us had worked in a commercial coding environment before, and with a home-grown version control system things had to be done a particular way. I actually broke the version control system a couple of times, until Meggs made me fix the holes I found by using it incorrectly. That's right: I had to actually code part of the version control system, which was a horrible mess of batch files and command-line C applications that called into each other recursively.

Meggs and Amos had more stringent procedures of any place I've worked since. Eventually they set down a formalized work procedure, and Guthrie and I were told that failure to comply was a 'sackable offense'. It went something like this:

  • Code until the problem is solved.
  • Execute the automated regression test scripts to make sure that nothing has broken.
  • Write new scripts to test what you have just written or fixed.
  • Merge down any changes that other developers have checked in while you completed your task.
  • Code review.
  • Adjust solution as per review.
  • Merge.
  • Run scripts.
  • Code Review.
  • Checkin.

It was a laborious way to work, but it did have certain benefits. We didn't have 100% coverage in the test scripts, but it meant that we could cut a release straight from version control and be assured that the greater portion of the software still ran properly. And we did have Jing writing scripts full time, so the coverage was always improving.

I learned a lot of things in that first year, particularly from Meggs. Meggs very smart and very volatile guy, but certainly it the best programmer I had ever met at that stage. He had a lot of ideas and techniques that I didn't see put into practice elsewhere for a good five years. He was very quick to leverage advanced features of the language and very keen for me and Guthrie to learn about them. Despite being the rawest of junior coders, I was exposed to the Standard Template Library well in advance of the majority of programmers in the field.

Meggs also taught me the primacy of design; of keeping the big picture in mind no matter how far down the rabbit hole of implementation went. No design is perfect, but it's better to have a design that's wrong than to have no design at all. You can fix a design that is obsolete, inappropriate or invalid, but if there's no design the chances are that you will have to throw out the codebase and start over. That was the best lesson about software development that I ever learned.

I'll go further: I learned more about programming from Meggs in that first year than I did from anyone else, at school or in the workplace.

Senior management decided that they wanted the software to start running on top of a third database engine. Meggs took some meetings with a consultant from the DB vendor and, when the vendor delivered us software, I asked if I could have a copy to play with on my work machine. Meggs ignored my request and assigned me a different task: to upgrade the database connectivity to be in compliance with the ODBC 3.0 standard. It wasn't an easy task, but it gave me a good look into the guts of the application and I took to it with relish. I didn't realize that it was a test.

Once I had successfully completed that task, Meggs gave me the CDs for the new database engine. "You asked for it, you got it," he said. "Your new task is to the database port."

I spent two solid months on it. The new engine was quite unlike the two we already supported and getting it to work sent me chasing all through the codebase. I learned a hell of a lot about how the software really worked, under the covers. Eventually, I cracked it. There was one case where the test scripts didn't report the same information due to an in-built behaviour in the database engine, but the behaviour was still correct (just a little different) and Meggs agreed that everything was honky dory. I modified the test scripts to allow it and checked it in, happy as Larry.

I'm pretty sure that not even one client ever bought the product for use on the new engine. Certainly, the support documentation was never updated to reflect the third engine and none of the project managers ever came to ask me how to set one up. There was a fourth engine that customers did want to use, and which had long been promised to them, but that was simply not on the schedule. The most important thing, as far as management was concerned, was that we could put the logo of the new database vendor on the packaging. We could boast some kind of a formal partner relationship to them.

But I didn't give a hoot. I knew I'd earned my stripes. I had about one year of solid experience and for the first time I felt as if I was a competent programmer. I couldn't have asked for much more out of my first year on the job, and I was looking forward to seeing what new challenges would arise.

I had no idea those challenges would be social, rather than technical.

No comments:

Post a Comment