Monday, December 22, 2003

How to Be a Software Engineer When All You've Got is a Lousy English Degree

I just finished my master’s degree in software engineering from the University of Texas at Austin. It was an unusual program that allowed me to continue working full-time while I went to school. Although I’m happy to have the credential, the curriculum wasn’t all that I hoped it would be. If you’re not able or inclined to go to an engineering college, you can probably educate yourself just as well. In May of 1998, all I had was a lousy B.A. in English, but I was starting to become interested in software development. I spent a couple of years hacking together websites and databases on Linux. I knew there had to be more to software development than coding a tangled mess. I also had no real interest in the tedious religious conflicts over whose operating system or computer language is the best. When I read Steve McConnell’s After the Gold Rush I realized that what I was really interested in was software engineering. The title Software Engineer is handed out quite freely, and it was even more so during the go-go 90s. McConnell’s book convinced me that there should be a big difference between a code cowboy burning the midnight oil and an engineer. In the true engineering disciplines (civil, mechanical, chemical, etc.) the barriers to entry are set pretty high. You don’t want just any joker building a bridge. The importance of software systems is growing and more lives will come to depend on them. There isn’t yet a certification process for software engineers in the United States, but it’s probably only a matter of time. It turns out that the difference between a programmer and an engineer comes down to their time horizons. A programmer may only be interested in getting the next thing working, while an engineer wants to know how the system will be shaping up, say, 12 months from now. A programmer may work hard to learn today’s hot language or operating system or IDE while an engineer will study a core body of software knowledge that does not become obsolete in a year or five. This does not mean the programmer is wrong. Maybe the code really does just need to work for today. But society will increasingly demand programmers who know how to be engineers. So if you want to be a software engineer, the first step is to know what it means to be a software engineer. The second step is to take your education seriously. Read industry magazines and keep up with tech news. Maintain a steady supply of good software books. Step three is to chart a course for yourself. McConnell’s company publishes a career development ladder that uses the Software Engineering Body of Knowledge project as a template for its various competency areas. The idea is that you should acquire basic knowledge in all areas and specialized mastery of two or three. The ten areas are: 1. Configuration Management 2. Design 3. Construction 4. Engineering Management 5. Maintenance 6. Process 7. Quality 8. Requirements 9. Testing 10. Tools and Methods Step four isn’t really a step so much as an ongoing process: get as much experience as you can and constantly measure your progress against your plan. If your professional development is stagnating, take action. It seems like every month I read some letter to the editor by a veteran software developer who is upset because the demand for his FORTRAN skills is drying up. The demand for software developers is still huge, but this fact remains: you go to the market, the market doesn’t come to you. If you are keeping up with tech news and the computer section of your local bookstore you will be able to tell what the hot technologies are. One of the wonderful things about the thriving open source movement is that you can volunteer for any kind of project using any kind of technology you’re interested in. Check out the help wanted section at SourceForge. Software engineering is only going to get more interesting. I have my degree, but my education is just beginning. The next part of my plan is to make a habit of writing about my profession, starting with this article. I consider it an important aspect of professionalism to share what I know. Let me know how I’m doing at Recommended reading for software engineers: The Mythical Man Month, Brooks Rapid Development, McConnell Peopleware, DeMarco & Lister The Pragmatic Programmer, Hunt & Thomas Agile Software Development: Principles, Patterns and Practices, Martin Design Patterns, Gamma et al