Monthly Archives: April 2024

Imagine a data processing system that takes advantage of local computing resources to provide a rich user experience and robust data validation while offloading a central computing system. It presents complex forms composed of smart fields that prevent entry of invalid data. Much of the validation is done locally, based on attributes applied to the fields to provide prompt feedback. However, when necessary, input can be validated against lists of values retrieved from the central system. When the form is complete, the user submits the data to the central system as a package that gets processed all at once before returning a success indicator or a failure indicator with a possible list of error messages to guide revising the data for resubmission.

Some readers will think it obvious that the data processing system is the World Wide Web. HTML forms — especially when souped up with modern web frameworks — support complex data validation and submit fields to a web server to update centrally stored data. If you’ve ever bought anything from an eCommerce site, you’ve used this technology.

However, as I was writing the first paragraph, I was not thinking of PCs running web browsers and data centers full of web servers, I was describing mainframes and their terminals. Undoubtedly, the web browser provides a more rich and responsive user experience than a 3270 terminal (which, among other things, lacked graphics), but diagrams of communication between parts of the old and new systems are identical in all but details.

I can’t say if the designers of HTML modeled their form system on mainframe data entry but it kind of looks like it. If they didn’t, they might have made their job easier had they done so. The suggestion that a programmer should not reinvent the wheel is often interpreted as applying to recreating other contemporary technology with similar features. However, it also means being aware of the history of computer science and technology in sufficient detail that you can learn from historical systems to make your job easier and your system stronger.

I once worked with a great programmer who had a sign on his wall that said:

The Three Qualities of a Great Programmer: Laziness, Impatience, and Hubris

All of those sound like negative attributes but considered in the right light, they are very insightful. I’ve thought of them often in the years since I read them on his wall.

Laziness

A great programmer is too lazy to perform simple, repetitive tasks and would rather spend two hours writing a script to do a task than 10 minutes doing the same task. (This always reminded me of a short story I once read about a young student too lazy to do their homework so they invented a machine to do it for them.)

Of course, if the task is only done once, automating it is not very practical. But if it’s preparing a weekly report or something, the scripting time is very well spent and pays for itself fairly quickly. And that ignores the fact that someone else can now run that script, can read it to learn about the process, etc.

Impatience

A great programmer is too impatient to wait for a slow-running program to finish, especially if that program does a repetitive task (see above) the programmer wants it to be fast so they can review the output and get on with other work.

Human interaction with a computer is incredibly sensitive to delay in response. If you’ve ever worked with a laggy mouse with a low battery, you know how it feels to have your actions take too long to take effect. Similarly, if you’re running a spreadsheet macro or small program it has to respond in well under a second or you lose flow and get frustrated. If the code originally took 1.5 seconds to run, making it run in 8/10 of a second may not seem a big improvement but it is the difference between a smooth work flow and a frustrating one, the difference between a tool you’ll come back to and come to rely on, and one you’ll set aside and not use.

Hubris

Maybe a great programmer isn’t hubristic. Maybe this is the humorous entry in the list. On the other hand, good software can save bad hardware. And it can do it after you ship. I’ve heard it said, “you can do anything in software” and I almost believe it.

A great programmer is likely to see a challenge and say, “I can do that!” Hubris? Confidence? Optimism? Maybe some of all of those. A meek programmer may look at the same problem, think it impossible, and not dive in. Without a certain measure of hubris, some of our greatest software systems might not exist. Their creators saw a challenge and believed they were up to it, and we all benefit from that.