Monthly Archives: January 2014

The Three Modes of Programmers at Work

Over the years I have been able to observe how software developers do their jobs in a variety of circumstances, and I have come to the conclusion that developers operate in three distinct modes. These modes I call from principles, from cookbook, and trial and error. An individual developer often has a preferred mode, but will switch between modes depending on the complexity of the software being created, the developer’s own depth of skill, and the perceived pressure of the delivery deadline.

In sequence from most to least desirable, here are the three modes:

Small hall of learning with Greek architectureFrom Principles. This is how you were taught at school to do things. You learned the fundamentals of the programming languages and tools, and you learned good processes for turning a design into a software product. Later you sharpened those skills with practical experience. Programming from principles is what we have come to associate with being professional.

A skilled carpenter learns the characteristics of all different kinds of wood, and therefore is able to select the right wood for any project, whether it is a dining-room table or a doghouse. Similarly, a skilled developer knows different design approaches, and understands the capabilities and limitation of various software languages and libraries, and can so choose those that are best suited to a project at hand. During construction, the skilled carpenter uses his knowledge to make decisions along the way that may not seem obvious but which affect the quality and durability of the finished product. For example, what is the best way to join two pieces of wood? Choices range from a simple butt joint to a traditional mortise and tenon, to a sturdy-looking dovetail, to simply nailing. The decision is influenced by the type of wood, how much stress will be on the joint, whether the joint will be visible, and on how much effort he is willing to commit. Similarly, during the course of building a piece of software, the developer must make many small but non-trivial decisions that together determine the quality of the delivered product. The developer uses her professional insights to guide those decisions.

Raymond Chen, a software design engineer at Microsoft, writes an extensive blog in which he often relates problems submitted by clients. Many of these problems seem to stem from incorrect decisions made because of gaps in the knowledge of programming principles. For example, using a global solution to a local problem is a common misstep. If you want to prevent users from printing the contents of a particular window, the thing to do is find a way to flag only that window as unprintable, not disable the PrtSc key which affects all windows. In another recent entry, he shows how an understanding of fundamentals helps you make serious headway in analyzing a program failure. There, understanding the underlying memory model of the system helped Raymond make sense of the application data he saw, and informed his choices of next steps, despite being unfamiliar with the specific application.

Applications that we think are awesome usually come from programmers who have that deep understanding of the software platform, the application domain, and the professional practices. In other awesome apps are made by programming from principles.

Of course, in the real world, programmers often don’t have the time  — or inclination — to get a deep understanding of all the software platforms that they have to work with. Continue reading

Conference Call: a Project is Going Awry

Somewhere, today, an IT project is quietly going awry.  Or, perhaps it is going awry not so quietly, thanks to that bane of open-office workers, the speakerphone.

Some time ago, I was sharing a room with about forty people working on a number of projects. One day, a conference call got underway with two or three people and a speakerphone. I was too far away to hear what the local people were saying, but the voice on the phone was loud and clear throughout the office. The call went roughly like this:

Speakerphone: [volume is pumped up to the max] … everyone’s here? Great, how are we doing today?

Local team: [indistinct talking]

Speakerphone: Are we still on track to deliver the code to the testers next Friday?

Local team: [indistinct talking]

Speakerphone: So are you saying we’ll miss this date?

Local team: [indistinct talking]

Speakerphone: So why are we slipping the schedule yet again?

Local team: [longer indistinct talking]

Speakerphone: You know guys, it’s gotten to the point that when I hear another one of your excuses it sounds like fingernails being dragged across a chalkboard. I don’t understand what … [becomes indistinct as volume is rapidly pumped down]

I didn’t overhear any further conference calls from that area. I don’t know if that’s because the team got smart about speakerphone etiquette or because the project got canceled.

Giveaway Calculators Then and Now

In my previous post, I described how to calculate a cube root on an ordinary calculator. Ordinary calculators are so inexpensive that they are given away as promotional knick-knacks. Here is one I received a few years ago at a university’s Campus Day – it’s not only a calculator, it’s also a ruler with inches and centimetres:

Digital calculator given away as promotional knick-knack

Now you might think that giveaway calculators first appeared around 1990 when advances in integrated circuits brought down the cost of a calculator microprocessor to less than a dollar. And you would be wrong. Here is a giveaway calculator from the 1950s, over half a century ago:

Slide rule calculator given away as promotional knick-knack

Like its modern counterpart, it’s not only a calculator, it’s also a ruler with inches and centimetres. Like the digital calculator above, it is shown just after someone worked out the cube root of 10 – and quickly too. Slide the cursor (the window) so that the red line is over the 10 on the K scale, then see the answer on the D scale directly above – 2.15 – accurate to three digits. What the digital calculator loses in speed (because you have to poke all those buttons), it makes up in accuracy (with an extra four or five digits of precision).

Reverse of giveaway slide rule calculator showing company advert

Back of giveaway slide rule calculator.

One difference between then and now: lots of people use digital calculators today, but analog calculators were mainly aimed at tech-heads like engineers — this one even came with a soft plastic case perfect for engineers’ shirt pockets.

Slide rule showing calculation of 2 times pi

Calculate 2π. Line up 1 on the C scale to π on the D scale. Now, 2 on C lines up with the answer on D: 6.28. Bonus: follow the red line to the A scale for 2π squared, 39.5.