Computing Ethics

As a software engineering student at MSOE, I was informed that I’d have to take two soft courses with the word “Ethics” in the title, and that they were both required for graduation: HU432: Engineering Ethics, and CS409: Ethical and Professional Issues in Computing. Sadly, the latter is no longer taught at MSOE.

While Engineering Ethics was more broad and applied to both managers and engineers in all fields, Computing Ethics (as it was called by the students) covered specific topics of ethics as applied to the world of software and computing (along the lines of Google’s “Don’t Be Evil”).

Continue reading


Architecture Abandonment

While perusing the Internet, I came across an article by Curbed which explores the head house of the old TWA terminal of the John F Kennedy International Airport in New York City. Unfortunately abandoned (but slated for conversion into a luxury hotel), the TWA terminal is the final work by famed neofuturistic architect and designer Eero Saarinen, who died in September of 1961 of a brain tumor, just prior to the terminal’s opening in 1962.

Image stolen from

Look at that; it’s beautiful! So why is it abandoned?

Continue reading


Is your job fun?

Most people, especially outside the software industry, would answer “No, but it’s just a job. It’s something I need to do in order to pay the bills.” It’s perfectly normal for a job to not be intrinsically satisfying, not especially extrinsically rewarding, and just around for the purely utilitarian exchange of goods and services for money. Just look at the service industry, retail, fast food, etc.; these are jobs which people hate.

Some (even within our profession) would answer “Well, there are aspects of it which are rewarding, but I don’t know if I’d call it fun.” These are the people who either (a) find value in the work they do, even if the work environment itself isn’t rewarding or fun, or (b) find value in some aspect of their work environment, but don’t especially like or understand the value of the work they do.

Continue reading

Save Early, Save Often

sesoBy now, most developers (and computer users in general) know the mantra “Save Early, Save Often”. During a heavy storm a week or two ago, I was reminded of the importance of this, and its implications for software development. However, in addition to never having a file go unsaved during catastrophic failure (such as the power outage which trashed our designer’s latest Photoshop work), the concept of save early, save often can be applied in several other areas of the software process, and often with beneficial results.

Continue reading

Extreme Casual Day

In honor of the long holiday weekend starting tomorrow, our company announced earlier this week that today would be an “Extreme Casual” day. This is just our fancy way of saying that instead of, say, khakis, nice shoes, and button-ups, we could wear things like blue jeans, shorts, T-shirts, sandals, and hats. I like wearing hats, and I just got nifty new shoes that I really like. Also, because of the holiday, there were only about half as many people in the cube farm, and it was a lot quieter. My boss had taken early vacation for the day as well, so it was only me, the project manager, and the other developers.

I can’t tell you the last time I’ve been this productive at work.

Continue reading

The Importance of Good Tools

Let me just say this, to start: I’m a big fan of good, functional, effective software development tools. On the flip side, I can’t stand being forced to work with a tool that makes it harder for me to work. Where I am now, I do Java EE development with Struts; I have a few tools that make this easier (and a few which do nothing to help).

A good software tool doesn’t get in your way, does what you expect it to do, and makes it easier to do common tasks, which allows you to be more relaxed, focus more, get more done faster, and in the end, create better software. In other words, it makes software development not suck. A bad tool, on the other hand, does the opposite; it takes too long to run, or it gets in the way, or you can’t quite tell if you’re supposed to be using it the way you do, or whatever. It just makes software development suck more than it should. Developers shouldn’t have to fight with their tools just to make good software; their tools should help them by conforming to their concept of what should be done, and never surprising them.

Continue reading