“I, 33 years of computer science, can make a living in the software industry without writing code”

[CSDN Editor’s Note] Since 1989, Jim Grey, who has been working in the software field, has accumulated 33 years of valuable experience and has witnessed the changes and development of the software industry. If you look at how software engineers worked in the past, you may be able to see how happy the work is today.

Original link: https://ift.tt/g7Pm5fp

Disclaimer: This article is translated by CSDN, please indicate the source when reprinting.

Author | Jim Grey Translation | Peng Huizhong

Editor-in-Chief | Tu Min

Produced | CSDN (ID: CSDNnews)

The following is the original text:

I have been working in the software industry for a living since 1989. I wrote code a long time ago, but my career has been largely built on testing, technical writing and managing releases, projects and people.

Today, allow me to tell a long story.

My 33rd anniversary working in the software industry was just past Sunday, July 3rd. I will remember this date because my second day at work was a paid vacation. I want to tell you how far our industry has come and how much we have learned.

When you first enter the workplace, someone will do

This is the company logo for ACD, the first software company I worked for, and since the company disappeared in 1996, the low-res logo below is all I could find online.

The first software company I worked for was Applied Computing Devices in Terre Haute, Indiana, and it was a joy to work with smart colleagues. We make software to manage telephone networks, and our customers are AT&T, US Sprint (now just Sprint), GTE (now Verizon), and several regional Bell carriers (i.e. landline companies), including Ameritech (for Indiana State Services), BellSouth and Pacific Bell. These companies primarily provide landline (“wired” in business) services, but some are also beginning to branch out into mobile services. This is complex management, and our software products are correspondingly complex.

I’m not a software engineer, but a technical writer. I wrote numerous paper manuals and sent them out to customers explaining how to install, configure and use our software. The software industry was very small at the time, and when I graduated with a math/computer science degree, the economy was in recession. I didn’t get a lot of interviews for programming jobs, and even if I did, I didn’t get hired.

I lived on campus that summer looking for a job. But summer will soon be over, and then I’ll have to go home and live with my dad. And I didn’t want that at all, so I decided to look for other jobs at a software company instead, including QA, support, IT, security, whatever.

A professor at my school knew people at ACD and recommended me to them. This company needs a technical writer. I said I would love to do the job, so they hired me for $23,000 a year (about $54,000 today). To my surprise, I found that I enjoyed writing, even more so than writing code, and I became very good at explaining technically-intensive software to users.

ACD Building, now home to Rose-Hulman Ventures

How the software industry used to work

What I’m really trying to tell you is what it’s like to work there, aside from the respect I have for my super smart colleagues.

The software industry was very different then, and many things that are now taken for granted didn’t exist at the time. Although there is the Internet, there is no network. Software was delivered to customers on tape or floppy disk, and CD recorders were still a few years away. Java, JavaScript, .NET also don’t exist. The languages ​​in common use at the time were C/C++, FORTRAN, Pascal, Ada, Perl, Tcl, Lisp, and of course COBOL. I had a summer job in college as a Pascal programmer. Although object-oriented programming exists, it is still a niche. The main object-oriented language at the time was Smalltalk. One of my college roommates is very well known in the Smalltalk community and has even written a few books on Smalltalk.

There was no software subscription at that time. At that time, as long as companies paid the full cost of the software up front, they could use the version of the software they purchased forever, but then they had to pay again for major software upgrades. Some smart companies install their payments over several years, but the license is still perpetual.

When you mail a new version of your product to your customers, most of them won’t install it right away, and some will never install it.

Often they’ll say, “The version we’re using right now is fine for us.”

This sentence is one of our nightmares when it comes to software support. After some iterations, our company finally decided to only support the latest four versions of the software, a decision that was very frustrating to our customers, but the IT support team was grateful for.

The best SDLC (system life cycle) at the time was waterfall, and none of the problems involved in this model went unnoticed by us. The industry is doing long-term projects like two months for requirements gathering and design specification, then nine months for coding, then three months for testing. Looking back now, even though we saw at the time that small-scale, frequently-released projects could benefit in many ways (but mostly didn’t), we couldn’t really do that. Because, the cost of delivery is expensive, and for our customers, frequent installations can be disruptive.

We believe that software development projects should be managed like manufacturing or construction projects. So we built a giant Gantt chart, which we stuck to a giant wall and used to keep track of what was planned and done. During the first week of coding, we would discover things we hadn’t thought of during the design phase, and we had to re-plan the entire project and reprint new Gantt charts. We were never immune to this situation at the time, and we are on every project.

By the time the code finally reaches QA, the testers will be wracked with hundreds of bugs. Before the software reaches the testers, they have hardly seen the software, and are only reluctant to participate in the design and development stages. Due to so many bugs, the testing phase always takes longer than planned. But by then we had committed a delivery date to the customer, and in order to meet the promised date, each release would have a whole bunch of known bugs that we would fix in what we called a “fast track” release a few weeks later, and the clever Customers learned not to install previous versions until the “fast track” version came along.

As a result of all this, the project always turned into a horrific “death march,” with lots of late nights and weekend overtime in the weeks leading up to the release date. Despite the high level of burnout, very few people quit because we thought it had to be done. Anyway, there are not many other software companies to rely on, and other companies also have a “long march of death”.

ACD’s technology stack (we didn’t have the term at the time) was based on two UNIX versions of C++: Digital Equipment’s Ultrix and IBM’s AIX. Our software runs on DEC and IBM RISC-based microcomputers, machines about the size of a bar fridge. We’re in a big, cold room with a bunch of machines, working on open source. Because the job site is on the outskirts of Terre Haute, our electricity is provided by a rural electric cooperative, which is not very reliable, which also causes power outages almost every month. The microcomputers were connected in sequence and had to be booted sequentially, it took 10 minutes for one machine to start up, and more than three hours for all the computers to finish booting up. If the power flickers after 2pm, we all go home for a day off.

But no one can work from home because microcomputers are only available on the network in the office. I don’t think it’s technically impossible to connect them to the internet, but at home we all have dial-up access. This leads to not only speed being an issue, but also that family members don’t like the phone being occupied by your work for hours on end.

Everyone has a terminal on their desk for work. At first, all the engineers used the old VT100 terminals, but then the company bought them huge graphics terminals for $2000 so they could build user interfaces in X Windows. At the time, UX design was still in its infancy, and there was no distinction between front-end and back-end engineering. Our software engineers design our user interface, but most of them are not good at this.

As a technical writer, I have a Macintosh II computer running System 6 on my desk. (System was the old name for MacOS) It had 8MB of RAM, which was a screamingly good machine at the time. I write manuals with a program called Interleaf and use a terminal emulator on a Mac to connect to a microcomputer.

There was a “holy war” over text editors at the time. IDEs didn’t exist yet, so we all coded in text editors. I’m firmly in the Emacs camp, but most of my colleagues prefer Vi.

Our terminal is on a token ring network connected to a microcomputer. A Token Ring network only works if the chain of nodes on it is complete, as information flows through each node on the network. I didn’t know it the day I decided to rearrange my cubicle. When I unplug my terminal to move it, I break half of the network. That day, I was “disgusted” by everyone.

AIX and Ultrix and their underlying hardware are very different, our code is a mess of IF AIX and IF ULTRIX statements. Sometimes we had to write separate AIX and Ultrix versions for whole subroutines and functions. We had to compile the code twice, once on AIX and once on Ultrix. When Java came out in 1995, it completely changed the game. Are you saying that we can write a codebase with no OS or hardware dependencies, no separate routines, and run on any machine that can run a JVM? This is pure witchcraft!

The culture of the software industry back then was far less diverse than it is now. Every software engineer at ACD is white, and most of them are under the age of 35. There are no people of color and no immigrants. It was not safe to work anywhere outside at that time. I know one of the tech writers on my team is gay, but it’s only because we’ve become friends that he decided to take the risk and confess to me.

The software engineering team has two titles. Software Engineer and Senior Software Engineer. This was typical in the industry at the time. You must have at least 10 or even 15 years of software engineering experience to be considered for promotion to senior software engineer. At that time, the advanced standard was also relatively high. The skills and experience of senior engineers back then were more like that of chief engineers today.

All in all, I am very happy at ACD and enjoy working there. However, since there were only so many phone companies at the time, we probably had a dozen or so customers. Our relationship with US Sprint has been rocky and one day we pissed them off and they canceled the contract and made us sue them for it. This loss of revenue got us in trouble and was the beginning of ACD’s decline. I didn’t want to lose my job in Terre Haute, so I got a job in Indianapolis and moved. Then, as now, most software development in Indiana was concentrated in Indianapolis.

Wisdom work

Let me tell you one last story about ACD, which involves US Sprint. US Sprint is outraged that our software has released too many bugs. They sent us a list of all the bugs they wanted fixed, they wanted to fix by Monday, or they would buy a competitor’s product and abandon us. The engineering team worked around the clock trying to fix these bugs. They worked through the weekend, but by Sunday morning, they still hadn’t fixed a couple of particularly tricky bugs.

At the time we had to ship the code in cassettes. The FedEx deadline is again on Sunday, and the engineers still haven’t done it. Someone’s eyes lit up and came up with a brilliant idea: We’d send US Sprint a blank tape with our usual letter listing the changes in the release.

On Monday, we got a call from US Sprint, who said they couldn’t load the software from the tape we sent them, no matter what they tried. At this point, our support department is ready. “Oh! We’re so sorry, something must have gone wrong! We’ll send you another tape today.”

The text and pictures in this article are from CSDN