When we’re on the job, we’re supposed to use the skills we have to solve business problems. But it’s not as cut-and-dried as that explanation; along the way, we’re suppose to improve those skills and develop new ones so that as time goes on, we can solve tougher, more complex problems, solve more of them, or solve them more quickly.
In a sense, this notion can be missed as one becomes a professional, given that a company typically hires someone first and foremost to solve a problem that is staring them right in the face. In college, it’s very clear that a co-op/intern is there to grow and help the company – almost as if the goals are reversed. It’s in that vein that a great growth project comes to mind.
As a co-op at an industry leader, I was in the test development group. We did software engineering, but with a lot of hardware knowledge necessary. Along the way, though, my manager had a little different idea for me to take on: he wanted to use our intranet to improve the status reports that engineers sent out every week. Rather than having them e-mailed, he wanted to be able to access them in an easier fashion, including sorting reports over time by engineer or project. (They could easily go by time of submission, but that was not deemed a necessary feature.)
He gave me those basic details, and I was off and running. I had never done anything quite like this or used the tools I would, but I had some ideas, so I wasn’t lost in the middle of the forest.
The first step was to design our department intranet page. Adjacent departments within engineering had such pages, but ours did not. I took the design and format of other departments and came up with one for ours. It was fairly basic, especially by today’s standards, aided by the fact that I did straight HTML – I was never one for a WYSIWYG tool, including back then. Then I knew I would link from the main page to what was needed for this: a form and a Common Gateway Interface (CGI) program.
At that time, I knew CGI programs were usually done in Perl, a language I had some knowledge of. But Perl didn’t have much in the way of library support for sorting that I knew of – it’s certainly possible it existed, but I didn’t know about it. C++, however, had the Standard Template Library, and I had been reading about C++ in addition to having dabbled in it before. While I had some exposure to sorting algorithms, I figured it made more sense to use something that was already well-tested instead of trying to roll one of my own, especially since the STL algorithm internally was surely one of the common ones like quicksort.
The decision was made. I would have two programs: a Perl script that would simply take in the form inputs and write them to a file, and a C++ program that would perform the sorting. The Perl script was straightforward; there was frankly nothing to it since its intended function was very straightforward and the form was very simple.
It was on to where this became the project through which I learned C++, as I have often told people. I had a book as my constant companion in this regard, but it’s not one that I suspect a lot of people are quick to recommend. It worked well for me, though, and if you can get it, I recommend it.
First, I had to construct a class for the status report. Each status report had several things: engineer, date, product and status comment. Because we would sort by name, I had to break up the engineer name into first and last names so that the last name could be used in the sorting.
I created the constructor and copy constructor, the latter of which to this day I admittedly have only a good, not great, grasp of. The destructor was relatively painless, even as it had to manage deleting memory that had been allocated. Along the way though, I ran into some pesky segmentation faults before I got all of this right.
The fun came in all of what was involved in doing the sorts. While part of it was as simple as calling the library function to sort, there was more work behind the scenes that had to be done. I knew about operator overloading, but now had to do it for a couple of the comparison operators – and I realized this after writing functions that would tell the program what we’re sorting by, as well as what to sort by in the event of two records that were equal in what was being sorted (i.e., upon finding the engineer last name to be the same, check the first name, and if that’s the same, check the project, etc.)
After much trial and error, including the fun of testing it without being a CGI program (how I concocted that test I surely can’t remember or fathom!), we had a functional online status reporting system. It was a great learning experience, as I learned so many concepts in C++ from the use of const (ironically, I had no idea for many years that C had this as well!) to operator overloading to the STL. About ten years later, I saw the person who at the time was my manager’s manager, and he told me the system was still in use with a tweak here and there. Naturally, that was nice to hear – it made me feel like I did even better than I thought with it.
If I did something like that today, it would be done quite differently. For one, I would surely use a database instead of the mechanism I used for storing status reports over time; I didn’t understand databases back then nearly as well as I do now. In addition, instead of a CGI script, some JavaScript would probably handle the form input. It’s entirely possible that I still have a C++ program for the sorting in that scenario, but not a given. If I did, I would probably manage through a few things that slowed me a little better now.
C++ is one of my strongest languages, right behind C, and this project got it all going.