Chapter Nine. Building the Community

If any human being earnestly desires to push on to new discoveries instead of just retaining and using the old; to win victories over Nature as a worker rather than over hostile critics as a disputant; to attain, in fact, clear and demonstrative knowledge instead of attractive and probable theory; we invite him as a true son of Science to join our ranks.

FRANCIS BACON

In 1984, I started my first full-time programming job as an analyst for a consulting firm with about five employees. The job paid well. We got free diet Pepsi. And I got to work on IBM PC projects, which were a lot more interesting than the mainframe projects I'd been working on in school.

The projects were much larger than my school projects, lasting anywhere from a day to a month. I learned a set of skills that I hadn't learned in school. I learned to coordinate my work with others. I learned to contend with a boss who constantly changed his mind about each project's requirements. And I learned to work with customers who depended on the software and actually complained if it didn't work the way they needed it to.

My second job was on a large mainframe aerospace project a stereotypical document-laden government project. The inefficiency was astounding. I was convinced that three or four of the programmers from my old company could have written in three months what this 30-person project team took three or four years to create. (I still think that's probably true.) One of the people on the project had a copy of Niklaus Wirth's Algorithms + Data Structures = Programs,^[1] and he was regarded as the project guru, from all appearances largely because he had read this one book. I didn't like this job very much, and by the time I left work each day, I happily stopped thinking about computer programming.

After the aerospace project, I went back to working in a small company environment as the only programmer in the office. I began work on an exciting year-long DOS shrink-wrap project in C that pushed the PC to its limits. This project didn't provide free diet Pepsi, but I was happy to be working with microcomputers again. The only hitch was that the new project had renewed my excitement for computer programming, and I couldn't find anyone else who was as excited about computer programming as I was.

By this time I had been working full time in the industry about three years and, aside from programming language and machine manuals, I hadn't yet read any programming books or subscribed to any programming magazines. (Though I had bought a copy of Algorithms + Data Structures = Programs.)

The small company I was working for presented itself to the public as "The A Team" of programmers. I was told during my job interview that the company had a lot of trade secrets that enabled it to be "The A Team." After I started, I said I wanted to learn the "trade secrets," and my boss handed me a copy of Philip Metzger's Managing a Programming Project.^[2] I read the book immediately, and was amazed to find that Metzger seemed to have had many of the same experiences I had been having. I had struggled with the planning for my new year-long DOS project. Metzger's book cleared up many of my problems, and I used it as a basis for the planning I did for the rest of that project.

Shortly after reading Managing a Programming Project, I found a copy of Ed Yourdon and Larry Constantine's Structured Design^[3]. In skimming it, I saw an explanation of why I was having such a hard time with the design for my DOS program. I inverted my module calling hierarchy, as Yourdon and Constantine suggested, and the whole design fell into place. I started to realize that there might be more information available to help me do my job well than I had previously realized.

About this time I foggily recalled some letters my professors had mentioned a few years earlier: A-C-M and I-E-E-E. I didn't have a computer programming degree and didn't feel like a professional programmer, but I decided to apply for membership anyway. I began receiving Communications of the ACM,^[4] IEEE Computer,^[5] and IEEE Software.^[6] IEEE Software quickly became my favorite. I discovered articles that addressed the issues I needed to learn about to do my job more effectively: how to help customers make up their minds about requirements; how to control complexity on large projects; how to create maintainable code; how to coordinate the work of multiple programmers; and so on. The articles weren't as fluffy as the articles in some of the popular magazines I was reading, and I felt they might even help me throughout my career.

This was a watershed event in my growth as a software developer. Prior to joining the community of IEEE Software readers, I had viewed programming as just a job. I went to work. I got paid. I went home. I stopped thinking about software. After joining the IEEE Software community, I began to see that, even if I worked in an office by myself, I wasn't just a lone programmer. I was part of a community of software developers who cared about software development and took the time to share their experiences for the benefit of other software developers.

Considering the extreme variation in education and skill levels in the software world, a person could argue that there currently isn't any meaningful software development community, but I think this variation makes it all the more important to build one. Every community is made up of some more skilled and some less skilled practitioners. A community must address the needs of both young and old practitioners. It must address the needs of practitioners with strong educational backgrounds in computer science, software engineering, and related topics, but also of self-taught programmers scientists, engineers, accountants, teachers, doctors, attorneys, and others who find that they are now writing programs for a living, even though they never consciously set out to become software developers or software engineers.

Professional associations such as the IEEE Computer Society are an important part of any mature profession. They provide opportunities for like-minded professionals to congregate, exchange ideas in person, in books, in articles, in interest groups, and at conferences. Professional organizations support numerous structured ways of exchanging the valuable tips and tricks of the trade that software engineers need to be on the A Team.