software engineering.

During my final semester of college, I took four high level math classes and one computer science class. No class got the attention it really deserved. My last period as a student was a shoddy one as I coasted by doing only as much as I had to to keep my grades up. I really didn't care anymore.

The one computer science class I took was Software Engineering, a lone practical course in a curriculum full of theory. It was boring, full of homework, and seemed pointless. Or maybe I just had a poor attitude.

We were divided into groups of four to complete a part of a larger class project. We were given the coding task, but before we could do it, we had to define it in a big document. And then after we did that, but still before we could start writing code, we had to design what we were going to and write a big document about that. And finally, we could start writing code, but along the way, we had to stop and have meetings about our code and review the code of our partners. We also had to stop and make changes to the documents we'd written, because the other teams would make changes in their plans and so we had to adjust accordingly. Finally, when we were actually done writing code, we had to have another meeting about our code and what was good and bad about the project, and of course, there needed to be a document about that, too.

Poor attitude or not, does that sound like much fun to you?

We had been learning how to write code, how to program, but this was about engineering software. It had a process which had been developed after lots of people had lots of meetings and wrote lots of documents about how projects had gone badly in the past. Those people determined that this process was the most effective way to develop software quickly and with as few bugs as possible.

As I went through this class, I mostly thought it was a lot of bull. How could anyone hope to get any coding done if they had to have all these meetings and write documents and then have meetings about the documents?

Of course, you've figured out by now, as I did by the end of my first month in the industry, that this class was the most accurate in terms of how programming is in the real world. I don't think my being a better student would have really improved how I applied the lessons of this class in my working life. But I just wish they'd been more explicit about the whole thing. "Hey, you dumb kid. You don't have to listen. You don't have to agree with all of this. But know that you will have to do it every day. You think I'm teaching for the pay?" I didn't feel unprepared to do the paperwork and the meetings, I felt unprepared to be assigned to do it. It's like I was surprised that I wasn't going to be assigned to write programs that drew triangles made of asterisks or played Yachtzee!.

And so, because I feel a need to fill the gap in the education of many young and naive computer science students (and also because I like to write in a bossy tone), I'm going to tell you what software engineering is all about.

You will have to work with other people. In college, everyone is assigned a Yachtzee! program. And so everyone has to produce their own version of Yachtzee! People don't work together. You don't have one kid write the dice roll part and then another kid write the scoring part.

While I knew some kids in my classes who would have been happy to have a few teammates, I'm hear to report that it's not all riding on coattails. There are three possibilities here. One is that your teammates are smarter than you are, in which case you can't pull your weight and you're going to have to get by on working really hard and being charming to make up for your natural deficiencies. The second is that your teammates are idiots and then you're going to have to make up for them, because 99% of the time, they do not know they're idiots and they won't be told. The third possibility is that you're equally matched. And whether you're both idiots or both geniuses, you're still not going to think the same way.

Those other people will not think the same way, they will assume the bugs are yours instead of theirs, they will change your precious code, they will write code in a weird style, they will not put spaces around their equals signs and they will never write clear comments explaining what is going on in their ridiculous, obfuscated code.

You will not necessarily be working on anything even remotely interesting. Think about the software you use every day. Somebody wrote that, obviously. How do you picture that person? When you use Excel, do you imagine someone really passionate about spreadsheets? Even worse is when you start getting into niche software, like, oh, truck diagnostics. The disillusioned and frustrated programmer who wrote the routine to test your gauges may not even care about your truck. Not even a little bit. How do you stay interested in your job when it's about something you don't understand, nor desire to understand? I don't have the answer to that.

Requirements Change. What if, about halfway into the Yachtzee! project, your professor comes by and said that she wants you to use a set of dodecahedron dice instead of your regular six-sided variety. Of course, that means the rules are going to change in the game, and you'll have more rounds, which will affect scoring.

"You can't do that! You already made the assignment and I've already started working! What's the point of not waiting until the last minute if you're just going to change your mind?"

In school, you could probably make that claim. But your boss will just advise you to bring a picture of your wife into work so that you don't forget what she looks like while you're working all these long hours. Requirements change at any time and you have to deal with it. Sometimes it's because of poor management or overzealous sales members, but sometimes it's because Microsoft just released a new service pack.

Meetings and paperwork are part of the job. A common question to ask when you're applying for a job is the percentage of time that you'll spend coding. They'll probably lie to you about the answer, but the fact that it's a question used at all is pretty telling. I have friends from college who don't code at all. It seemed pretty ironic to me at first that a job so based in technology would have so much paperwork. I don't hate the paperwork itself, as I paid enough attention in software engineering to see how it's useful when properly applied. But sometimes it's BS. Different projects require different amounts, and more paperwork is not always the answer.

And meetings are the same way. You'll have to attend meetings that have very little to do with what you're working on. You'll have to attend meetings where people spend an hour arguing over something like the color of the Yachtzee! dice. You'll attend meetings and sit there thinking about all the work you could be getting done. But then you'll attend meetings that are useful and productive and maybe helpful in attacking a task that you were unsure about.

I say I wish someone had told me these things, but I know I wouldn't have listened. I wonder sometimes why they don't tell you before your last semester what being a professional programmer is really like; then I realize that everyone would change their majors. It's not so bad. If you find a good place to work where there is a high genius to idiot ratio, a reasonable boss, high coding time percentage, and work that you're interested in, you'll probably be pretty happy with your situation. No career is perfect. Even the Ben and Jerry's testers get headaches sometimes.