What goes on in the mind of a programmer? Think deep-real deep.
From the perspective of a programmer, it’s a tad amusing when a professional athlete says, “It’s a mental game.” Sure it is, after a decade or two of developing the body and reflexes. For programmers, it’s a mental game from start to finish. I’m not saying that programming takes place only in your head; obviously, something happens outside your head when you program a computer. However, if you don’t think of it first, the computer does nothing.
In the first part of this series I wrote about the programmer’s environment–types of jobs, where to work, who to work for. In this article I’ll tackle something much more abstract–what goes on in a programmer’s head. I suppose this sounds odd, but if you’re setting out to become a programmer, you need to know about the mental and intellectual part of the profession. It’s always present, and you have to like it that way.
As you probably know, programming is done with languages. The parallels to learning and using a foreign language are appropriate, to a point. I won’t say that people who are good at learning languages make good programmers, but they are kindred spirits.
Programming is also intensely procedural; by that I mean that no matter what the type of program or programming language, it is still constructed one piece at a time and (for the most part) executes inside a computer in sequence. The ability to think of a program as a series of small, discrete steps is a necessity.
Still, there is more to programming than learning a programming language and procedural thinking. For one thing, you have to learn what a computer can do with a language, and through that, learn what happens to people who use your programs.
Most of the time, programming has two key aspects: the underlying logical and procedural use of the programming language, and the less logical but no less important effect of the program on the user. In short, most programs have a user interface, which can require artistry. Combining these two aspects of programming to make a successful piece of software is a creative endeavor that is unique and very satisfying.
Not just logical, Mr. Spock
So what goes on in a programmer’s head when he’s programming? There’s a popular tendency to think of programming as a matter of logic. Certainly much of basic programming does involve logic, and it’s important to have some affinity for it. If you study computer science in school, you’ll spend a great deal of time with subjects like Boolean logic, procedural structures, and above all, programming algorithms. In a sense, this is the hard core of programming that lies at the root of almost all programming languages. Programmers use words like elegant and cool to describe the neat, tricky, and complex things you can do with logic. Algorithms are the expression of this logic.
From logic to intuition
In the business world, where most programming jobs are found, most programmers don’t write algorithms. They develop all or parts of applications. Applications are to programming what a trilogy is to novels–the same basic story but more of it. Most applications are based on specific functionality–accounting, document management, spreadsheets, and customer relations, to name a few. They contain a number of components such as database management, reporting, access security, and a user interface–all of which intensify and complicate programming tasks. These days, almost any program you write is considered an application. Application development is so fundamental to programming as a profession that most programming languages are packaged to provide the necessary tools. Companies such as Microsoft, Borland, and IBM compete vigorously on their application development systems.
Inside the head of a programmer, application development is its own world. Not only do you need to know a programming language, but also an application development system, and typically a database management system, as well. Instead of thinking about some nice, elegant algorithm, your head is filled with the demands of a user interface, the necessary functionality of the application, and such mundane (but necessary) things as help systems and documentation. Very few programmers ever develop an entire application; it’s just so complicated and laborious, even for relatively small applications.
For some programmers, the ultimate challenge is programming large-scale applications or systems. This can be called programming in the huge, such as a communications system to bind together a worldwide enterprise, or a complete Web-based accounting program. In these cases the intellectual challenge isn’t any single piece of the programming, but making the whole thing work–fitting all the pieces together.
When you put a large-scale application together with the demands of an effective user interface, you come up with programming that is so complex that even the rules of logic don’t seem to apply. Every programmer who debugs applications learns that there are problems so complex and vague in origin that you can’t fix them; instead you program around them. Complex software interactions produce effects for which there is no clear explanation. Welcome to the world of programming–not by logic but by intuition.
If you were to sit in on a bull session with some old-hand programmers, I’m sure one of the topics would be how many times each of them has had to re-educate himself to stay in the profession. Granted, veterans of all kinds reminisce, but in programming, this amazing need to periodically retrain is no tall tale. The computer industry has made a lot of major transitions: from mainframe to minicomputer, to personal computer, to local-area networks, to the Internet. At each transition (and there are more), the specifics of programming have changed (languages, programming models, application development tools). Keeping up with change is a helluva lot of work, and sometimes people just don’t get around the bend.
It’s a bit like telling a professional soccer player that soccer is no longer commercially viable, so go learn hockey. With programming, it’s easier to retrain your head than your whole body, but it’s still difficult. You’ve become accustomed to certain patterns in the code, certain ways of locating and solving problems. Learning new programming languages or methods means learning new patterns and solutions. Worse, the new stuff looks just enough like the old stuff to throw you off track.
Those who have made it through a big transition tend to brag and put “change” on a pedestal. It’s tempting to dismiss the attitude as grandstanding. After all, it’s a fact that people are still gainfully employed programming in languages such as COBOL that were popular 40 years ago. However, there aren’t many COBOL programmers; it’s no longer mainstream. For COBOL programmers, that means that at any time the software they maintain may be replaced, and few companies want new software built with COBOL. If you stay in the programming profession for more than a few years, you too will probably be faced with the need to retrain. It’s the ultimate head game.
Get an education
Despite being such an intellectual occupation, programming is odd because people have succeeded at it without any formal programming education. I can’t conceive of doctors or lawyers practicing without specific education for their profession. Yet I’ve met more than a few programmers who did the whole bootstrap routine. Maybe this means that not all programming is difficult. It might also mean that experience is at least as important as formal education.
Before I get labeled as anti-scholastic, a degree in computer science provides a rounded, systematic background. It’s also a requirement for many advanced jobs in computing. From a practical perspective, some of the most interesting and challenging projects in programming are easier to figure out quickly if you have a solid background in computer science.
With or without formal education in programming and computer science, there is one constant: learning. If you don’t like to learn–and I don’t necessarily mean learning because of change–then you are going to have a tough time as a programmer.
Life as a series of projects
The good news: A professional programmer always has new projects to look forward to. The bad news: Old projects never die (you’re lucky if they just fade away). Believe me, the life of a programmer looks quite different with the perspective of 20 years in the profession. This is true of most things, of course, but in this fast-moving, high-rolling business of computing we tend to have very short vision. I would argue that it helps to take the long view: Life as a programmer is a series of projects. Projects come in many shapes and sizes, but you’ll know one when you see one.
A career has a finite number of projects, maybe only one, maybe a hundred. The important thing is that each project is unique and yet related to other projects. There is only one first project. There are good, bad, and routine projects, and the more you do, the better you can distinguish between them. If you’re lucky there will some great projects, but maybe only one. Cherish it like an NFL football player cherishes playing in a Super Bowl. If you find yourself repeatedly not looking forward to the next project, get a new employer or maybe a new line of work.
What does a programmer do?
My mother first asked me the question, “So what is it you do all day?” You know, that question is hard enough to answer for somebody in the business. Answering with “I write programs,” just isn’t good enough. If you get this question from your mother, here’s what you can say:
Most of the hours in a working day I sit at a desk. On the desk is a computer. The computer is connected by a network to other computers in the building and also to the Internet. The computer is loaded with all kinds of software, and if I’m lucky the computer is one of the fastest and most powerful available. The most important piece of software for my programming is called an application development system. Every day I turn on my computer, and the first thing I do after reading e-mail is launch the development system software. With this software I use a programming language and many other programming tools to create, fix, and maintain more software.
What I do on any given day is work on a project. How I get to work on a project and what kind of project it is depends on where I work. Since I work for myself, I go out and hustle clients who want software written for them. I get paid for working on and completing application software–like an accounting program. Some of these projects take only days, but I had one that lasted four years. In some cases I may be working on more than one project at a time. This can be hell, but it pays the bills more rapidly.
Every project has a life cycle, with a beginning, a middle, and an end. In writing a piece of software–one project–the beginning is the time where I find out what people want the software to do. This is called analysis. Not all programmers do analysis. Once you know what the software should do, you figure out how you’re going to make it work. This is design. Most programmers do some design, although they may be working from a master plan. In theory, if the analysis and design are good, the work of programming should be easy and the software good.
It doesn’t always work like that. I spend most of my days writing or fixing programming code. The code tells the computer what to do so that the software will do what the users or clients want. Some days I discover that what I thought the client or user wanted isn’t what they wanted. Then I fix or rewrite the code. There’s usually a period when the program is tested (called beta testing). This involves a lot of fixing–debugging–that is sometimes more of an art than computer science.
Eventually, the software becomes good enough to use. Not always, though; in fact, not usually. Only about one project in five or six is completely successful. Some projects are abandoned. Software that works is finally given to end-users, which usually means that it must be documented and training must be provided. All software has to be maintained. Sometimes there are things that need to be fixed, or things users want changed. Maintenance is the end of the cycle, and it can go on for years. If a programmer is lucky, somebody else will do the maintenance.
Most days, I work on some part of the software development cycle. However, I don’t spend all day programming (unless I’m really lucky). There are meetings: meetings with clients, bosses, co-workers, team members, project leaders, etc., etc. On any given day, I attend one or two informal meetings. In addition to meetings, I spend time reading industry information (print or online); writing reports (for bosses or clients); learning (new) programming; and dealing with hardware and software problems. Sometimes a hard disk dies or the network goes down; then I spend just as much time scrambling as anyone.
In the head and maybe a little heart
Some professional programmers start out with a lot of chutzpah. What keeps programmers going is an interest in (and sometimes a passion for) programming. The most successful programmers have a passion for learning in general. They adapt to change. They try to increase their knowledge and improve their skills. This is not unlike many other professions, really; but few professions can match programming in its requirement that you keep your head in the game.
Editor at large Nelson King also writes Enterprise Pursuits, a weekly look at the life and times of enterprise programming, every Tuesday on ComputerUser.com.