Programming in the Real World

Software Careers Fall 1997 Dr. Dobb's Journal

by Allen Holub

Allen, a contributing editor to Dr. Dobb's Sourcebook, can be contacted at http:// www.holub.com/.

When you have little real-world programming experience, a computer-science degree is your ticket to an job interview. But the fact is that many of the classes you sweated over have little relevance outside academe. As a working application-development programmer, for instance, you probably will never see an integral sign, compute a determinant, or formulate a mathematical proof. The same goes for the theoretical computer-science classes-more than likely, you will never have to prove NP completeness or use O(n) notation. While there are some (though not many) parallels between the problem-solving process in math and programming, once you get beyond programs of a trivial size, the parallels in process are essentially nonexistent. Writing high-quality programs is a form of writing, not a form of mathematics. If math had anything to do with programming, all the best programmers would be mathematicians (which is not true), and people trained in the liberal arts would make lousy programmers (which is also not true). In fact, some of the best programmers I know have degrees in sociology, Russian literature, or English.

Furthermore, many of the skills you desperately need to be productive in most programming shops are often not taught in universities. Do you have experience working on a program of, say, 100,000 lines of code? Have you worked as a team with other programmers for extended periods of time? Have you ever designed a program that will take five programmers a year to write? Have you ever done a "complete" design-requirements documents, problem and goal descriptions, user interfaces, manuals, documentation, static-model and scenario diagrams, data structures, and the like-of even a small program?

Have you ever had to find a bug in code written by someone 20 years ago in Cobol and then translated by someone else to C? Have you had to integrate existing, poorly designed code into a new program? What do you know about human-factors engineering and user-interface design? Have you done any formal testing? Have you ever productized a program, written the user manual, written installation and configuration programs, and the like? Do you document your code adequately, choose variable names that form complete words in English (so that they can be understood by non-native speakers), and format for readability? Do you know SQL, or how to design and normalize a database properly?

What nearly 20 years as a design educator, author, consultant, and programmer on projects ranging from operating systems to embedded robotics have taught me is that there's a huge gap between what you learn in school and the work that goes on in the software-development trenches. The real world of computer programming is more like what I've just described than what you learned in Computer Science 101. Luckily, most employers are prepared to train you.

How Did We Get into this Mess?

The dichotomy between academe and the computing profession is not unnoticed; see, for example, "Revisiting the Industry/ Academe Communication Chasm," by Robert Glass (Communications of the ACM, June 1997). The core problem is that computer science, as taught at most universities, concerns itself with the analysis of computer programs, not the creation of them. (I'm making a distinction here between "computer science" and "software engineering," which, to me, are different disciplines.)

For instance, many, though not all, computer-science professors have little experience in putting together high-quality production code. Consequently, many of them don't really understand the real-world software-development process at all.

I ran into this phenomenon when working on Compiler Design in C, a book that teaches how to put together a C compiler and the tools that you need to build a compiler by actually implementing them. In the book, I included and discussed full source code for lex, yacc, and a C compiler. One of the peer reviewers, a full professor at an well-respected school, didn't like the book because it contained code, and he couldn't understand why the code was important. His comment was that code "has no place in a book of this sort." Compilers, in his view, should be taught by "presenting the underlying mathematics." "The implementation," he said, "is trivial." Clearly, the reviewer had never implemented a compiler. The point here is that the attitude that the coding is a trivial matter not worth real study is widely held in the academic world. The end result is that many people get out of school knowing a lot about computers, but almost nothing about the process of programming.

So Now What?

The $64,000 question is, given that you'll be competing with thousands of other new graduates, what's the best way to stand out of the crowd when entering the real world of computer programming? How do you best prepare yourself for work as a programmer in the real world? For what it's worth, here's my advice:

Get some experience in a work/study or internship program. This way, you'll have some real experience doing a real job before you enter the market. A solid recommendation from a previous employer counts more than your GPA when it comes to hiring. (I have never been asked for my GPA. Unless you're going for grad school, it's irrelevant.)
Skip the math and concentrate on building skills that are useful. Classes that actually involve programming are typically better than theory classes. The bigger the programs you write, the better. Compiler and operating-system classes in which you actually build a compiler or operating system are good examples. (Although one university class recently taught an undergraduate compiler class that used Lisp to write a Lisp compiler. I'd skip that one.)
The practical classes in the core curriculum-languages, data structures, algorithms, computer architecture, and so on-are the real foundation of our profession, and you should understand this material thoroughly.
Most programming in the real world is done in Cobol, C, C++, and, more recently, Java. You might add Fortran to this list if you're doing engineering or scientific programming, though C is making inroads. Similarly, Visual Basic is used for a lot of business applications. Make it a point to get good at at least two of these languages. You can't go wrong learning Java or C++. If your goal in life is to write UNIX CGI scripts, you might also consider learning Perl or Tcl, though Java is beginning to supplant these languages. Languages such as Lisp, CLOS, Pascal, Modula, Smalltalk, and Eiffel have little real-world significance outside niche markets.
If possible, learn about databases and learn SQL. The majority of programmers work for large corporations doing mundane things, mostly with databases. Most databases are accessed nowadays using SQL.
Learn about networks. The trend is toward distributed computing with pieces of a program scattered all over the place. Learning about TCP/IP, sockets, CORBA, Java RMI, and so forth, is useful. If you'll be programming in the Microsoft world, learning DCOM and Microsoft's variant on DCE could be useful, though Java might render a lot of that irrelevant in the long term.
The ability to communicate clearly and write well is important too, so take a few English composition classes. A well-written cover letter is often the difference between getting an interview and not.
Read code. Writers often learn how to write by reading, and programming is really just a form of highly formalized writing. Read as much code as you can, wherever you can find it. If it's bad code, read it thinking how you'd improve it. If it's good code, read it to learn from it. If nothing else, you'll learn how to write code that can be read by others, an essential skill in a profession where the vast majority of programming is maintenance work.
Join professional organizations to get their publications, then read them-IEEE's monthly IEEE Software magazine and the ACM's Communications of the ACM are both worth reading. Both organizations have student memberships and can be contacted at http://www.ieee.org/ and http://www.acm.org/, respectively.
Develop a real program that's useful to someone other than yourself, distribute it on the Web, and use the feedback to improve the program. In other words, create a product. Don't worry about recreating Microsoft Word. Create something small, but useful. This sort of experience is exactly what employers are looking for. You can go to your interview armed with something real to show off. Bear in mind that a typical freeware hack doesn't count for much in this department-create your code as if you had to convince someone to pay real money for it. If your product is good enough, maybe you can skip the job search entirely and form your own company. Yahoo! started out as a student project.
Take a business class or two so you understand how businesses work, how schedules are actually used, how software projects are managed, and so forth.

While I'd like to say that understanding formal-design methodologies and software engineering is essential, it remains that many companies don't use even the most basic practices that would improve the quality of their code and time to market. Many companies just work their employees until they burn out, then hire a new batch to replace them. It turns out that this is probably the worst way to put together a product-it takes longer and costs more-but there it is.

On the other hand, many (not all) large corporations take quality seriously, and a solid grasp of software engineering is a plus. Some industries (like defense, medical, and aviation) stand out. Companies such as Boeing, IBM, Motorola, Schlumberger, Bull, and Siemens all take software engineering seriously. Most of these are multinational companies; excellent smaller American companies exist, but are less conspicuous. No matter where you work, though, you'll be able to write more code in less time than your coworkers if you design and construct your own code carefully.

Conclusion

I don't want to give the impression that you learn nothing of value in school. For example, the ability to live on Jolt cola working 20-hour days, week after week, is a definite plus. And of course, following my advice won't guarantee you a job or elevate you to programming guruhood, granting infinite bliss and complete fulfillment. You will have a step up when moving from the cloister to the outside world, though, and every little bit helps.

DDJ