Robert Stackowiak - Remaining Relevant in Your Tech Career

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the book's product page, located at www.apress.com/9781484237021 . For more detailed information, please visit http://www.apress.com/source-code .

I have had the good fortune to work for about 40 years in technology-related roles. You might have picked up this book because you wonder how this is possible. I was reminded of attitudes that some possess about aging in such roles recently while riding my commuter train from work in the Chicago area. I overheard a conversation where one of the technology specialists said to his friend, "When you reach the age of 50, you should not be in information technology." Since I am well beyond the age of 50, it occurred to me that the position that I hold and the value that I still provide might be unexpected by some. Yet, I know there are many of you who continue to believe that you can make a positive impact in technology careers and that you have valuable experience that you can bring to new jobs as you age.

I realize that some of you might believe that the rate of change in the future will accelerate and that lessons from the past might be of limited usefulness. However, rapid change is nothing new (as you are about to see as I describe my career path here). I believe that many of the lessons that I share in this book will therefore prove useful in the future.

I encountered a lot of changes in technology and what was expected of me over the years. My career path included jobs in the government and in commercial technology companies. I advised government agencies and small, medium-sized, large, and multi-national commercial companies in these roles, helping them define strategies and information technology architectures.

My undergraduate degree is in civil engineering and was obtained from the University of Notre Dame. In the 1970s, the computational tools that civil engineers used evolved from slide rules to electronic calculators and computers. Input into computers was most often by using punched cards. The engineering programming language of choice was Fortran. The experience with computing that I gained at Notre Dame started me in a direction I hadn't anticipated.

Upon graduation, I was hired by the U.S. Army Corps of Engineers to focus on hydraulic (water-related project) engineering. Being the young member of the team, they assigned me to projects that included technologies still in the process of being proven as useful. Survey data in the Chicago District was analyzed using software, and both software and data were loaded into a programmable calculator via magnetic cards. At the St. Paul District, I used Fortran-based software developed by the Corps' Hydraulic Engineering Center (in Davis, California) to analyze river flow and flooding and predict the impact of flood control projects. I was also trained on how to use finite element software for structural analysis and design.

The Corps was ahead of its time in many respects when I worked there from 1978 to 1986. They were early adopters of minicomputers (from Harris Corporation). Programming and input was possible through Texas Instruments terminals (with thermal paper to display input and output), Tektronix graphics displays, and later through CRT terminals and PCs. Lock and dam traffic data was captured on CPM-based PCs that were loaded with 8-inch floppy disks.

It was during this time that I made the transition from being a hydraulic engineer using computers to programming software to make my job easier. Later, I began writing code to provide software solutions for others. In 1982, I developed Habitat Evaluation Procedures (HEP) software in Fortran for the Harris computer under guidance from the Corps' headquarters in Washington, D.C. This software was used to report on the potential impact of projects on wildlife habitats.

About this time, the St. Paul District began exploring the value of AT&T 3B2 Unix-based computers and the C programming language. I attended training at AT&T in Santa Clara, California. Upon my return, we used the AT&T 3B2s that we had in St. Paul to set up networked e-mail among the engineers. I rewrote the HEP software in C. I also developed training and documentation for the engineers using these platforms and collaborated in development of critical path method (CPM) software for managing construction projects.