Looking back on Twenty-five years in I.T.
By David M. Woods
Published September 19, 2006, 1:57 pm in News.
I've been a software designer / developer for over a quarter-century now. It's been an interesting career. Much has happened. Many things have changed radically, others haven't changed at all. I still greatly enjoy designing creative I.T. solutions to business problems.
In these paragraphs, I will summarize some of the highlights and the low points of my career. I will put down my take on some of the challenges and opportunities facing software developers today, plus my humble opinion on the state of things, a little advice for folks looking for employment in I.T., and where I think things are going.
In the beginning . . .
The beginning is always a good place to start. I started out with a bachelor's degree, but my degree was not in technology. (Footnote: many years later, I went back to school and got an MBA.)
One day I bought myself a computer - Radio Shack TRS-80 model 3. What a machine it was! It had not one but two floppy disk drives, each capable of storing a whopping 128 k of data. (Yes that's k, as in kilobytes, not gigs, not even megs.) It also had a Z-80 chip that crunched data at a blazing 4.77 mhz. I was on top of the world! I also picked up a book on Basic programming, opened it up to page one, and starting writing programs.
My first full-time I.T. job was writing accounting software for a taxicab company, using a now-extinct version of Business Basic. Our system was what could be called a mid-range. All of the terminals were of the "dumb" variety; networked PCs had not yet been invented. I had a lot of creative freedom in that position, especially for a neophyte. The most important lessons I learned was the value of keeping things simple and putting out software that was rock-solid dependable.
Good jobs and bad jobs
I've worked at dozens of companies over the years, big and small. Some of my jobs have been fantastic; others, well, not so great.
Probably the worst job I've ever had was made awful by the jerk of a boss we all had to work for. He was a pretty smart guy, an awesome salesman, a man-about-town who rubbed elbows with lots of important people. He had started his business on a shoestring and had built it into a multi-state empire with hundreds of employees. But he was a tyrannical, meddling micro-manager who refused to delegate one iota of decision-making authority to anyone. I, and much of his work force, all got out of there as soon as we could.
Some companies I've worked for put me in with small groups of other programmers. In others, I was all alone. I've had jobs where I was a one-man I.T. department, responsible for hardware, programming, desktop apps, everything. In a way, being the project manager, analyst, designer, coder, tester, installer, trainer, and help desk, all rolled into one job was advantageous because I did not have to go through any committees or anything; if I decided the software should work a certain way, I just did it. The flip side was this nagging feeling that I had no idea if the way I was doing it was indeed the best way.
It has always amazed me how company cultures can be so different. In some companies, everything is so formalized, so regimented, with a hierarchy of management, and everyone's job is so compartmentalized. In other companies, everything is wide open, and as long as you can justify your paycheck, we'll keep you around. In some companies, money was no object when it comes to improving productivity and efficiency, and in other companies, getting funds for the tiniest I.T.-related expense was nearly impossible.
I worked for several years for a very friendly, cozy little financial company with an office just minutes from where I lived. But their hardware was antiquated, the network was not up to the task, and the boss could not be convinced to spend a dime to upgrade anything. My career was stagnating; it was time to move on.
One learns that there is a world of difference between "corporate" and "public" programming. In the former, one works in the I.T. department of a company who's product or service is not I.T. I find corporate programming much more interesting; your job duties tend to be much more diverse, and you have daily contact with lots of friendly non-I.T. people. Corporate programming also tends to be less stressful; you don't have major deadlines for project releases and such. Public programmers, on the other hand, work in the I.T. industry. I have found that work in these types of companies tends to be harsher; everyone is always uptight and stressed out, there's always a crisis to be solved, and the daily routine is monotonous.
Programmers themselves can vary widely. Some like the human element in their jobs. Others are pure coders who want nothing more than to write program code, all day long.
Programming, incidentally, is not the only I.T. job I've every had. I worked for myself for a few years, running a one-man consulting shop out of my home. My flagship product was a small accounting system that I wrote myself, which I installed and customized for clients, who were mostly small mom-and-pop operations. I partnered up with some hardware vendors around town and we sold complete systems. Here is what I learned from this endeavor: you could have the world's greatest product, but if you didn't have a good plan for marketing it, it was all for naught.
I also spent a year or so teaching programming classes full-time. I greatly enjoyed the challenge of teaching, but it was tougher than I dreamed. We in the programming business probably have no trouble understanding the purpose of a line code like the following:
X = 4But trying to teach the concept behind an assignment statement such as the above can really try the patience. Here are some typical student comments: "Why do we have to write assignment statements? What good does it do us? How do we know what to assign something to, and why is it such a big deal if we do it wrong?"
(Actually though, teaching assignment statements was a piece of cake, compared to declaration statements!)
Once I looked into a position as a Tester. A Tester does nothing all day long but examine programmers' output and try to break it. A company I worked at once (a "public" programming outfit) had a team of Testers. I think it takes a special kind of person to do that for a living. My hat goes off to those people; to me, that would be the ultimate job from hell.
Challenges & Opportunities
Without a doubt, the toughest challenge of being a programmer is just keeping up with the constantly changing technology. No other occupation that I'm aware of requires the level of constant retraining that programming requires.
It's maddening when I work hard to learn some technology well, only to find the very next day that it's obsolete. I still fondly remember those days when I considered myself a top-notch Foxpro guru. That's not worth a dime today.
I still clearly remember the year 1995. That was the year that Microsoft released Windows 95. To be specific, it was released in August of 1995. But it was in February of 1995 that employment ads began to show up for W-95 programmers. A full six months before the product would be released to the public, and with no Windows 95 experience, already I was hopelessly behind the power curve.
Programming has also definitely become much more complex over the years. When I started my career, I was able to get my foot in the door with just some rudimentary programming knowledge. That's impossible nowadays. (Note to anyone just starting a career in I.T.: don't even think about trying it.)
To succeed in the I.T. world today, programmers must know a staggering quantity of languages and systems, from a plethora of vendors. We must know compiled languages, scripting languages, operating systems, networking, databases, spreadsheets, desktop apps, UI design, source code control, security, and so much more. Plus, programmers need to know all the intricacies of whatever industry they support (accounting, engineering, etc.) And we better be pretty good at web surfing, so we can research how to do things and diagnose problems. Oh, and let's not forget we must also have good inter-personal skills (unless you're one of those head-down coders I mentioned earlier).
Object-oriented programming (OOP) has evolved from a buzzword to a veritable requirement for any coding language to survive. Granted, OOP gives programmers a world of power and flexibility that previous generations never dreamed of. That's the good news. The flip side is: no matter how you slice it, OOP is tough. After years of working with OOP, it still befuddles be sometimes. In the old days, to learn a programming language, you simply read the book (you know, the printed book that actually came with the system) and presto, you were an expert. No more! With OOP, you must develop expertise with any classes any programmer anywhere in the world has written any time in the last decade or so. Or at least clever enough to know how to find a class out there somewhere that does what you need, and then figure out how to use the blasted thing.
The explosion of the World Wide Web was another paradigm shift of the our profession. Programmers today are expected to be expertise in web development, also. Web development is fundamentally different from other types of development that previously existed because it runs on multiple tiers. That's a radical concept that takes some getting used to.
Open-source software is the next wave that will take over the world. Twenty years ago, who could have dreamed that something you could download for free would actually be good enough to actually use. And that open-source systems comprise a viable business threat to giants like Microsoft.
The good news, however, for those of us who have been around the programming block a few times, is that general experience still counts for something. It takes time to learn how to write good software, how to design a good database, how to lay out a good user interface; and some of these things just can't be learned in a book.
Some other encouraging news is that the days of the clueless user are going away. Two decades ago, it was common to find employees who had never seen a computer, and were terrified to touch the thing. Likewise with upper managers, who for the longest time were of the opinion that operating a computer was far beneath them, that it was the secretary's job to print out emails, reply to emails, etc.
Also, this doom and gloom about the outsourcing "threat" is all hot air. The number of programming jobs outsourced to India and China is insignificant, and anyway is overshadowed by the growth in U.S. technology companies brought about by increased demand from Asian businesses. Besides, even for the hard-core head-down code writers, there will always be some element of human interaction and communication involved, and a programmer on the other side of the planet will always be at a major disadvantage against a programmer in the next room.
IMHO
In My Humble Opinion, here are a few I.T. issues where everything would go smoother, if everyone did it my way:
To begin with, the KISS principle has flown out the window. (That's keep it simple, stupid.) Too many programmers either have never heard if it, or ignore it. I see way too much code, too much complexity. Early in my career I learned - the hard way - that the more complicated you make things, the greater the likelihood that it will fail. Plus, simpler apps are just easier to maintain.
Sometimes making things simpler goes all the way back to the user requirements. Formalized system specs need to be negotiated; too many programmers just take the users' wish list like it was engraved in concrete. This is a touchy subject - we programmers and analysts must convince the user community that it's in our own mutual best interest if we can simplify things.
Here's a typical scenario: The users say the software must satisfy the following list of 100 items. Of those, 99 are simple and doable, but one of the items is terribly complex, and by itself would comprise a sizable chunk of the total project programming effort. We, the I.T. guys, need to inform the users of that fact, and find out just how important that one nasty requirement actually is. If it is found that it isn't all that mission-critical, then we must make every effort to "sell" them a less-expensive alternative.
Another gripe of mine is the reluctance of many programmers to write things down. Producing programmer's documentation should be a mandatory requirement, but in my experience, it never happens. Database structure documentation, in particular, is extremely useful.
Next on my list is the issue of "home-grown" systems versus "off-the-shelf" systems. Which path to choose should primarily depend on the size of the company; the larger the company, the greater the advantages of developing in-house. What I have observed, however, is a trend for larger companies to buy off-the-shelf systems.
This is a terrible management decision! Commercial applications are simply not designed for large, complex organizations. It either doesn't do what you really need it to do, or it's loaded down with way more features and clutter than you'll ever need ("bloatware") in a vain attempt to write a "one-size-fits-all" app that still doesn't fit. The argument that "accounting is accounting" doesn't fly; a sales invoice from one business won't look a thing like the sales invoice from another. And no large business should have to modify it's fundamental processes just to conform to their accounting software. It should be the other way around! Furthermore, development software today is so powerful that programmers can build truly awesome applications.
Small businesses, on the other hand, are a different story. If your company is small, it's generally much less expensive to just change your methods to conform to the system than to hire a team of programmers.
The last item on my list of issues is to tell the world what my favorite development tools are. For desktop applications, I like Microsoft's Visual Studio. I use Visual Basic .Net (although I really need to bite the bullet and learn C#). For databases, my favorite is Sql Server. I've worked with MySql; it's fairly solid, but it's just not a mature a produce as Sql Server, and the tools to use with MySql are buggy.
For web development, I'm not sold on the Microsoft suite; it puts too much emphasis on server-side controls, and it's hard as heck to apply styling. Thus, my pick is Php, used in tandem with a templating engine called Smarty. Smarty allows the developer to effectively separate server-side "back-end" and client-side "front-end" components.
Job-hunting tales
Throughout my quarter-century in I.T., I've spent more hours that I like to think about hunting for employment. I've been laid off probably dozens of times - I lose count. The worst years were from 2001 till around 2004, when a combination of a faltering national economy, terrorism, hurricanes, and Enron put thousands of us I.T. people on the street.
But I certainly learned much about job hunting, HR, and the recruiting business during that time, and here I will share some of what I learned.
To begin, it should come as no surprise that the Internet is where it all happens. If any employer out there has a job opening and wants to spread the word, chances are it will be posted on the Internet, in some shape or form. There are three or four national job search sites out there that you should become very intimate with. (The local job search sites tend to not be very useful.)
Actually, there are two ways to use the Internet for job hunting, which I will call the "passive" and "active" technique. In "passive" job searching, you simply post your resume out there, then sit back and wait for the calls to start coming in. In "active" job search, you, the candidate, actively hunt for job posting that you qualify for, and then you, the candidate, take appropriate action to get your foot in the door. If you're serious about finding a job, then don't put too much faith and hope in the passive method. You need to get active!
The nice thing about active use of the Internet for job hunting is that it is deadly efficient! Sitting at my desk, in the comfort of my home, I can search for qualifying openings, verify them against my database, and send out dozens of resumes per hour.
I kept a detailed database of all my job hunt-related activity. At its peak, my database had well over a thousand employers and agencies, with probably several thousand instances of correspondence or contact (resumes sent, emails, phone calls, meetings, interviews, etc.) over a multi-year period.
Recruiting agencies, a.k.a "head hunters" have always played a major role in I.T. employment, and that arrangement probably will not change anytime soon. Remember that those guys and gals are on your side; you are the "product", they are the salesman, and they work on straight commission. The downside of having a recruiter as middle-man, however, is that it lowers your bargaining flexibility. If there's a job out there that you would just die to have, and are willing to negotiate a lower salary, recruiters won't give you the time of day; they only care about one thing: finding that one candidate who can demand the highest salary, period.
On a related note, never ever agree to pay anybody a dime to place you in a job. If the employer won't commit the resources to advertise an opening, read resumes, and arrange interviews, that is NOT a problem for you, the candidate. The instant an agency asks you for money, walk out the door and do not look back.
Finally, a few words on programmer certification. From time to time, I hear talk about forming some sort of nationwide organization or "guild" of professional programmers. The purpose would be to advance our trade, establish standards, and communicate to potential employers some level of competence. This is probably a good idea, and I do hope it happens one day.
But in the meantime, ignore those vendor-specific certifications. I made the dreadful mistake of spending a rather large quantity of time, money, and brain cells to become a Microsoft Certified Solutions Developer (MCSD). Turns out, it was a huge waste. For one thing, the tests are simply awful. Writing a "challenging" exam is one thing, but on this point be clear: the Microsoft tests were carefully designed to keep that exclusive club very small. And then, employers weren't impressed with my MCSD in the least.
Furthermore, technology changes too rapidly. To get through the tests, I memorized every last detail of Visual Basic 6, only to have it become obsolete practically the next day.
Looking to the future
In Business school, they taught us Moore's Law, which states: the power of the computers we use doubles every 18 months. Moore's law was written back in the early 1960s, when the first digital computers were invented. The amazing thing is that this principle has held solid for well over four decades now. When you think about what that means for the future, it's mind-boggling.
Or will the mad pace of I.T. progress eventually level off? It's a question I ponder daily. I've heard some say that you can only push so many electrons through a wire, and those wires have shrunk down to nearly the size of electrons now, so maybe the top of the plateau is near.
Meanwhile, new languages and development systems continue to spring up so fast that I don't even know the language name yet, let alone know how to use the darn thing. So I don't even try to memorize language syntax anymore. (Lemme see, how do I declare variable names in the latest language-of-the-month?)
But there's always that faint glimmer of hope that the furious pace of development might slow down one day, and give us old programmers the opportunity to rest on our laurels and get real good at some language, instead of dreading having to start all over again!
Comments & Trackbacks
No Comments for this post yet...
This post has 99 feedbacks awaiting moderation...
Leave a comment