In the first fourteen years of my career in Information Technology, I worked for a half-dozen companies, but I basically did three jobs. I started out a Cobol and JCL programmer on IBM mainframes. In this job, I learned not only a programming style, but a programming philosophy. We'll come back to this.
There are two traditional career paths for a mainframe programmer, at least if he desires to continue in Information Technology. One path is technical support, which involves building and maintaining a company's IT infrastructure. The other path is called systems analysis; this path consists mainly of serving as a liaison to the business users and translating their needs and requirements into technical specifications that can be used to build applications, which drive today's businesses.
This career path scenario simplifies, indeed largely ignores, several current realities of Information Systems/Information Technology, such as sufficiently flexible PC software that savvy business people can use to create very sophisticated applications, outsourcing, and the rise of the independent corporate IT subsidiary that has replaced many internal IT departments. My work environment is largely a mix of the last two, "competitive sourcing" and the IT subsidiary. There are opportunities because of this that I wouldn't otherwise have. I work on applications across several platforms, including mainframe, Unix, Windows client-server, and the Web; these applications span multiple companies in North America and Europe.
As I faced this branch, I determined that I get much more enjoyment and satisfaction from writing software than from detailing the functionality that someone else should write. Or put another way, I'm a bit of a geek who enjoys cutting code. I would have actually been very happy long term to continue mainframe application development in Cobol. It's not a cool language by any stretch of the imagination, but it's a darn satisfying workhorse of a language, and I'm good at it. But, it was pretty much a given ten or fifteen years ago that programmers didn't stay programmers. You were expected to become either more technical or more business. Otherwise, well, there must have been something wrong with you.
Since I knew I wanted to remain on the more technical side, I began to look for opportunities in technical support. As it happened, there was a very attractive opening as systems programmer supporting mainframe database management software at my then employer. I posted for the position, and I felt very positive about my chances to get the job. I had very good relationships with the people in tech support, including the hiring manager, and I knew I could do the job. It may have even worked out that way, if I'd already had experience supporting mainframe database management software. I didn't get the job, and that was a blessing in disguise. Mainframe technical support turned out to be mostly installing and configuring software packages, lots of troubleshooting performance issues, and tons of after hours and weekend trouble calls. There was basically no software development in that line of work.
Shortly after this, my company ran into business troubles and began a long cycle of downsizing and layoffs. I made it through the first round of layoffs and decided it was time to change jobs. What did I end up with? My second IT job, the one I hadn't wanted, systems analysis. Turns out I'm not too shabby at this, either, but I still wanted be the guy writing the programs.
During most of the next four years, I did get to do a little programming, but more and more, I was writing program specifications and test plans for other programmers, and then testing their programs. I do like the design side of applications, but not as my full time gig. And I definitely didn't care for the on-call and planned overtime parts of that job, the parts that made it feel as if I worked two-and-a-half full time jobs, while getting paid for one.
I moved to a new company again, and I ended up in the third of my three discrete IT jobs. For a little over two years, I was a DBA, a database analyst. This job was actually a move away from programming, even more so than systems analysis. I didn't install database software, but I used it extensively. My job was to design the data structures that programmers needed to hold the business information their applications had to have to do the business work, to maintain the integrity of the data (for example, if there's a credit card account, there has to be a cardholder), and to ensure that the applications got acceptable performance from their databases. A poorly designed or implemented database can kill computer performance; how long do you want to wait on your online banking, or to buy a concert ticket? Yep, that's what I thought.
Now, there are dozens of database managers on the market. I worked primarily with DB2, IBM's mainframe relational database manager. Truthfully, for my purposes here, it doesn't matter which topography of database comes into play, be it relational, hierarchical, or network. What matters is that I was in an infrastructure support position, I was professionally challenged, and I strongly considered staying in that career path. In the end, I didn't like where the office politics were taking me, and I decided to change jobs again. I very happily got back into application development, programming again. This time, though, I stayed at the same company, and I have now been there for a bit over 10 years.
I haven't gotten around to explaining the title of this post, nor have I touched on programming philosophy, yet. I'll get to those in Part 2.
