Engineering route to accounting

In a discussion on Google+, Daniel Lemire argues that engineers end up essentially being accountants.

Engineering, at least how it is practiced in North America, is hardly very exciting. … By the time you have your degree, you have 5–10 years to go before, if you have any ambition, you end up a manager of some kind, doing more or less what your friends who went into accounting do. … No, you don’t get to build anything, technicians do that … you only approve their expense reports …

Of course there are exceptions, but the career path Daniel describes is common. And it’s not unique to engineering. It’s a sort of variation on the Peter Principle. Many people find themselves approving expense reports for people who do the work they enjoy doing, or used to enjoy doing.

What can you do if you want to avoid going into management/accounting? Here are a few ideas.

  • Be content with a lower salary.
  • Work for smaller companies.
  • Work for specialized companies, e.g. an engineering firm.
  • Go out on your own (but watch out for the e-myth).
  • Spend a lot of time searching for a job.

Related posts

New programmer’s survival manual

A computer science degree doesn’t prepare you to be a programmer. Here’s an excerpt from a blog post I wrote comparing computer scientists and programmers:

I had a conversation yesterday with someone who said he needed to hire a computer scientist. I replied that actually he needed to hire someone who could program, and that not all computer scientists could program. He disagreed, but I stood by my statement. I’ve known too many people with computer science degrees, even advanced degrees, who were ineffective software developers. Of course I’ve also known people with computer science degrees, especially advanced degrees, that were terrific software developers. The most I’ll say is that programming ability is positively correlated with computer science achievement.

How do you bridge the gap between obtaining a computer science degree and becoming a professional programmer? For years I’ve recommended that CS grads read Code Complete. Now I’d also recommend New Programmer’s Survival Manual by Josh Carter. This new book has some similarly to Code Complete. However, Code Complete is about good programming technique, not programming as a profession.

The Survival Manual has four parts:

  1. Professional Programming
  2. People Skills
  3. The Corporate World
  4. Looking Forward

The first part has the most similarity to Code Complete, though even there the two books are complementary. The second part, people skills, has some great advice, though I imagine most CS graduates will skim over this part because they don’t realize it is important.

CS students may do well to read the Survival Manual, especially parts one and three, to find out whether they want to be programmers. Some who find abstract computer science fascinating will find a typical programming sorely disappointing. See Mike Taylor’s post Whatever happened to programming.

A few of these may be able to find refuge as computer science professors, but not many. If you want to become a professor and think you’ll be able to get an academic job, watch So you want to get a PhD in theoretical computer science and read No, you cannot be a professor.

The Survival Manual assumes the majority programmers will be working in cube farms on enterprise software, which is true. But there is a small middle ground between enterprise development and academia, jobs that will give you a chance to use advanced computer science without having to write papers about it.

One reservation I have about this book is that it may be overwhelming. If you have a friend who is starting a new career as a programmer, maybe you could buy a copy of the Survival Manual and rip it into chapters. Then mail your friend one chapter a week.

Another reservation I have is that new CS graduates may not benefit much from the book because they won’t believe it. They may deny that the real world is as Josh Carter describes.

The people who may benefit the most from reading the Survival Manual are programmers with some experience who want to improve their skills. They may have learned through hard knocks about some of the challenges Carter writes about. Also, Carter describes life in a software shop with fairly high standards. Those who are used to producing lower quality software will do well to read about life in an organization with higher standards.

Related post: Where does programming effort go?

Here’s to the sane ones

I’ve been thinking about unsung heroes lately, the behind-the-scenes people who make the world go around. I’d like to tell some of their stories here, but they probably wouldn’t want that. They’re not “the crazy ones” romanticized by pop culture. They’re the sane ones who take responsibility.

Here’s my rewrite of Apple’s Here’s to the Crazy Ones commercial.

Here’s to the sane ones,
the responsible, the mature,
the unsung heroes,
the pillars of society,
the ones who see what needs to be done and do it.
They’re not fond of recognition,
and they know the world is a messy place.
You can snub them, make fun of them, or ignore them.
About the only thing you can’t do is live your life without them.
They make the human race survive.
And while some may see them as the boring ones, we see love.
Because the people who are humble enough to serve
are the ones who hold the world together.

I’m not saying we don’t need “crazy ones.” We do. But we also need responsible ones. It’s not just talkers who “make a dent in the universe.” It’s the behind-the-scenes doers too.

I’d love to see someone take this and make a video like the Apple commercial.

Three views of Windows and Unix

Rob Pike gave a presentation in 2001 entitled “The Good, the Bad, and the Ugly: The Unix Legacy.” His main point is that diversity has been bad for Unix. He opens his presentation with a couple of quotes to set this up.

‘‘The number of UNIX installations has grown to 10, with more expected.’’ — The UNIX Programmer’s Manual, 2nd Edition, June, 1972.

The number of UNIX variants has grown to dozens, with more expected.

He discusses much more than diversity, and I believe the more interesting parts of his talk are on other topics, but he begins and ends with diversity. One of his last slides says

Microsoft succeeds not because it’s good, but because there’s only one of them. … Unixes of the World, Unite!

Joel Spolsky has a different take on the differences between the operating systems in his article Biculturalism. Spolsky says that Unix software is programmer-friendly but Windows software is user-friendly for the vast majority of users who are not programmers. But Spolsky does touch on the diversity issue that Pike raised.

For example, Unix has a value of separating policy from mechanism which, historically, came from the designers of X. This directly led to a schism in user interfaces; nobody has ever quite been able to agree on all the details of how the desktop UI should work, and they think this is OK, because their culture values this diversity, but for Aunt Marge it is very much not OK to have to use a different UI to cut and paste in one program than she uses in another.

Just to throw in my two cents worth, I’ll mention my blog post Where the Unix philosophy breaks down. The Unix philosophy is to write little programs that do one thing well, then sew these little programs together to do your work. The problem is that many people lack the desire or skill to do the sewing. They want to avoid the transaction costs of switching software applications. Pike alludes to this problem, dismissively saying that people want “hand-holding” rather than pipes.

I don’t think this desire for integrated applications is necessarily a problem for Unix, only for the Unix philosophy that Unix doesn’t follow too strictly. The emphasis on orthogonal programs is a laudable ideal. It just needs to be tempered a bit for the convenience of mortal users.

Type R error

Andrew Gelman added a couple more types of error to the standard repertoire of type I and type II errors. He suggests using type S error to describe a result that gets a sign backward, reporting that A is bigger than B when in fact B is bigger than A. He also suggests using type M error for results that get the magnitude of a result wrong.

Maybe we could add to this list type R for reification error: treating an abstraction as if it were real, forgetting that a model is a model and stretching it beyond its limits.

Related links:

Avoiding distraction

My previous post gave examples of how David Souter and Donald Knuth chose not to use some common technologies. John Venier left an insightful comment.

I think the avoidance of technology in these cases is really an avoidance of distraction. These same fellows would probably not keep a parrot in their office if it screeched every couple of minutes, regardless of their affinity for birds.

I believe he’s right. My intention was to write more broadly about how tools influence our thinking, but the examples I gave were only about one kind of influence: distraction.

Related posts

Selective use of technology

In his book The Nine, Jeffrey Toobin gives a few details of former Supreme Court Justice David Souter’s decidedly low-tech life. Souter has no cell phone or voice mail. He does not use email. He was given a television once but never turned it on. He moves his chair around his office throughout the day so he can read by natural light. Toobin says Souter lives something like an eighteenth century gentleman.

I find it interesting that Justice Souter would have such independence of mind that he chooses not to use much of the technology that our world takes for granted. He made it to the top of his profession and had a job for life, so he could afford to be eccentric. But he wasn’t born on the Supreme Court. I would like to know whether his low-tech work habits developed before or after his legal success.

I imagine most readers of this blog could more easily relate to Donald Knuth than David Souter. Knuth obviously doesn’t reject technology, but he is selective in how he uses it.

I had the opportunity to see Knuth speak while I was in college. Much to my surprise, his slides were handwritten. The author of TeX didn’t see the need to use TeX for his slides. While he cares about the fine details of how math looks in print, he apparently didn’t feel it was worth the effort to typeset his notes for an informal presentation.

In 1990 Knuth decided to stop using email.

I’d used email since about 1975, and it seems to me that 15 years of email is plenty for one lifetime. Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things.

I believe I’ve read that Knuth does most of his work on a Linux box with no network connection. He also has a Mac for creating graphics and using the Internet. He has a secretary to handle his correspondence, including email.

If you’re reading legal briefs by sunlight, your thoughts will not be exactly the same as they would be if you were reading by fluorescent light. If you’re writing a presentation by hand, you’re not going to think the same way you would if you were pecking on a computer keyboard. And if you do use a computer, your thinking is subtlety different depending on what program you use. Technology affects the way you think. The effect is not uniformly better or worse, but it is certainly real.

Related posts