DIY Calendar – Compact Year Version

This calendar was inspired by a small problem I have with traditional year-at-a-glance calendars like the one here. I like having a calendar that shows the entire year on one page, but there’s so much data that when I try to look up anything, I get lost in a stew of tiny numbers.

So, what could be done to make the year-spanning calendar more readable? I applied two ideas: (1) reduce the amount of data that is presented and (2) present it with a more graphically intuitive layout. If nothing else, this should at least permit the numbers to be a bit larger.

Reducing the Data

A typical calendar month fills, in essence, a 7 by 7 grid – seven columns for the days of the week, and five rows for the weeks plus two more for the month name and weekday headings:

       JANUARY
 Su Mo Tu We Th Fr Sa
     1  2  3  4  5  6
  7  8  9 10 11 12 13
 14 15 16 17 18 19 20
 21 22 23 24 25 26 27
 28 29 30 31

The first idea came from a schedule I happened to see many years ago for a set of educational seminars. Those seminars took place only on workdays, so the printed schedule omitted Saturdays and Sundays. This idea shrinks the calendar to five columns wide:

    JANUARY
 Mo Tu We Th Fr
  1  2  3  4  5
  8  9 10 11 12
 15 16 17 18 19
 22 23 24 25 26
 29 30 31

This led to two further refinements. First, it’s noticeably easier to infer which column is which on a five-column grid that on a seven-column grid, so I decided that the row with the headings for the days of the week could safely be dropped. Second, if I abbreviated name of the month, I could tuck it into the vacant zone that appears in either the first or the last row of the number grid. Now the calendar is down to five rows high:

  1  2  3  4  5
  8  9 10 11 12
 15 16 17 18 19
 22 23 24 25 26
 29 30 31 –JAN-

With a little thought, you’ll see that the day numbers of every possible month fit comfortably into a five-by-five grid, with a bonus that we avoid the problem that conventional calendars face with months that spill into six weeks. For these months, a conventional calendar either has to add a sixth row, or more commonly, squash two days into a single cell on the last row, leaving you with what appear to be fractional dates: 23/30 and 24/31.

Presenting Graphically

Putting a frame around each month, adding light grid lines, and choosing a nice font turns the calendar into what I think is an attractive visual image. Some people think it resembles a bingo card.

The fact that the month name almost always occupies a larger cell sets it off visually from the day numbers; showing the month name in a different font style completes the effect.

From time to time there is no large cell to hold the month name. In fact this happens whenever the month starts on Tuesday and has 31 days. In 2018, the month of May is like this. This calls for a bit of creativity – maybe abbreviating the month name more severely or showing it in a smaller font.

Making the Year

Finally, I assembled the months and decorated with headings to produce the year-at-a-glance calendar. Of course it’s necessary to show the year, “2018”, but it’s also helpful to include a text like “Mondays to Fridays” to explain what those month grids are all about.

DIY Calendar – 3D Version

As a small do-it-yourself project, I wanted to make a three-dimensional calendar to sit on my desk. I decided to try a polyhedron design because that would be reasonably quick to make from cardboard.

As there are twelve months in the year, the obvious choice for the polyhedron is the regular dodecahedron with one month on each of the pentagonal faces.

But this has been done often enough that it’s looking ordinary, so I thought it might perk things up a little with another shape. One option is a 14-sided polyhedron with two hexagonal polar faces and twelve trapezoid faces for the months.

This shape should make for a good advertising give-away: the polar faces could carry a corporate logo, and the polyhedron can be contrived in such a way that it folds flat for mailing. Advertisers ought to like calendars because, if they can persuade the customer to use the calendar, the advertiser’s logo stays in the customer’s sight for a year.

However, I decided to go with another 12-sided polyhedron, the rhombic dodecahedron:

I chose it because it has a pleasing symmetry – all the faces of the polyhedron are identical, and the faces themselves are one step away from full symmetry – and those faces are four-sided which seems to suit the rectangularity of a calendar month grid.

Making Faces

The first step for this DIY calendar is to create the faces. There are templates out there that you can use, but it’s not difficult to make your own. I decided to make the face images in PowerPoint.

Lay out the rhombuses with dimensions in the ratios shown here. For accurate dimensions in PowerPoint, the Format Shape> Size dialog pane is your friend. In my case I scaled the rhombic face to be 12cm wide by 16.96cm high (4.72” by 6.68”), with each side of the face being 12.72cm (5.01”) long.

The upside of painting the month faces this way is that you can format them however you like. In my case, I adjusted the colours of the months to match the seasons – icy blue for winter, garden green for spring, sunny yellow for summer, and harvest red for fall.

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:

From 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.

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.