Author: Ed

Every now and again, I’m asked to judge a technical contest of one sort or another. Let us assume, for the purposes of this discussion, that you are participating in such a contest and I’ve just begun to look at your entry…

Rule 0: Send a PDF

The contest rules will tell you what document files they expect; typically, it’ll involve some version of Microsoft Word. Why they do that, I cannot say, but Word documents aren’t really suited to read-only document distribution. Not to mention, some of us don’t have MS Word installed…

In addition to those files, also include a PDF of your final document file so that when I open it, it’ll look exactly the way you intended. MS Word documents tend to look weird on any PC other than yours, particularly if you have any odd fonts or formatting options turned on. If you can’t figure out how to produce a PDF, install OpenOffice and use the direct PDF export; that’ll also show you how weird MS Word can appear in a different word processor.

Don’t waste time on a fancy layout, but do pay attention to the basics:

• Images must fit inside the margins of a single page
• Use simple fonts that are large enough to read
• Avoid complex tables and drawings: use PNG images instead

Hint: ask a friend to review your submission, ideally a few days before you plan to submit it. Take any comments you get very seriously.

Rule 1: Tell Me What You Did

The first two paragraphs of your documentation must tell me:

• What your project does
• Why that’s a great idea

That should take, at most, half of the first page.

You have two paragraphs to catch my attention; sweat bullets over those words!

Hint: If you can’t summarize what your project does in one sentence, maybe you don’t have a good project.

Rule 2: Let Me Judge How Easy (or Hard) It Was

Going on at length about how easy the project was produces the impression that maybe there’s not enough effort in there to justify a few kilobucks of prize money. Conversely, kvetching about how hard you worked indicates that you bit off more than you can chew.

Let the project tell the story. A good project requires more than a few evenings of effort and, believe it or not, the amount of effort will show up in your description, even if you don’t mention it at all.

Hint: If you’re trying to be funny, it probably won’t work.

Rule 3: Use Good Pictures

Examine all the pictures with a hyper-critical eye.

• If they’re blurry, delete them and take them again.
• If you think a picture might be out of focus, it is.
• If there is the slightest trace of doubt in your mind about the quality of a picture, delete it and try again until you get it right.

When you get the focus right, ruthlessly crop your pictures. Hint: I don’t need to see the crap on your workbench or the dirty laundry in the corner of your room. Devote all the pixels to your project!

When you don’t care enough to invest a few minutes getting a good picture, the rest of your project is probably sub-optimal, too. Don’t bother to submit it, OK?

Crisp pictures can’t sell a weak project. Blurry images rarely accompany a good project.

Hint: That big LCD on the back of your camera is there for a reason. Use it!

Rule 4: Support Your Claims

If you claim to have built a multi-node, RF-networked, high-bandwidth, vibration sensor measurement system, then you must include data supporting your claims. Otherwise, I’ll assume you don’t know what you’re talking about or haven’t actually gotten it working, should my back-of-the-envelope calculations indicate there’s not enough RF bandwidth / range / compute power to pull it off.

You must convince me that your project does what you claim!

Hint: Should you claim to have built a snake-armed robot that balances atop a ball while serving drinks from a refrigerator, a video demonstrating it in action is worth a thousand words.

Rule 5: Don’t Hide a Skeleton

You may encounter a serious problem that simply can’t be fixed before the contest deadline. When that happens, explain what you intended to have happen, what the problem is, and what you propose as a solution. As long as the problem is secondary to the project’s intent, that’ll be fine.

For example, if your project involves half a dozen different sensors and you just can’t get the humidity sensor working, explain your debugging efforts and the results.

Conversely, if it’s a networking project and you can’t get the Ethernet code working, then your entire project just went down the drain and you shouldn’t submit it. I can generally tell when a project simply isn’t going to work, so your efforts to hide the corpse won’t gain you any points.

Hint: Start your project early enough so that when something goes wrong, you have time to fix it.

Rule 6: Use the Specified Hardware and Use It Hard!

The contest is generally about using some particular microcontroller or chunk of hardware. Your project should fully utilize that chip: make sure you read the manual and exploit a whole bunch of its unique features.

Hint: a project where all the action takes place in a Javascript routine or another, entirely different microcontroller probably isn’t making good use of the specified chip.

The Bottom Line

If you’ve got a good project and describe it well, you’re probably in the money. Plenty of other entrants will ignore these suggestions and wind up on the bottom of the pile.

Fair enough?