After finding a couple of minutes over the past couple of nights (tough when you have two young children), I finally got the survey/poll component put together, as you can see from a couple of the entries with attached surveys. Obviously these are mostly for entertainment purposes, and will only marginally track with reality (e.g. the motivated are more likely to vote, and they're more likely to encourage like minded people to vote, etc). Although none of the samples demonstrate it, the surveys allow for a multi-question format, which would allow for statistical correlations (e.g. "90% of the people who want to work for Google also say that Google is definitely not evil").

In any case it's a nice little multi-tier project with a Microsoft Access backend (as that's what my host provides), though I need to put together a SQL Server plug-in data module as well, which will be trivial (actually I'm using the OLEDB provider and a config file connection string, and technically the queries are all standard SQL, so with the same schema the same module should work. It's late and I'm tired, so I haven't really thought this through). It uses copious caching, so it's actually fairly performant (especially for a relatively low volume blog like this). Anyhoo, after I clean it up a bit, and add a basic administration page, I'm considering releasing the source. I'm sure there are plenty of craptacular competitors that do the same thing, but I think it's pretty elegant.

One of my goals with the survey component was to ensure that it was extremely lightweight, consuming the absolute minimum of resources. Doing so requires not only a good database design and access patterns, but also necessitates the addition of potentially error prone caching and optimization code: Building a little survey component is trivial, but trying to do so while ensuring that you hit the database as seldom as possible, all while personalizing for each user and avoiding "vote stuffing", gets a lot more interesting (and, quite honestly, fun. Straightforward projects are never fun).

I mention this because it's always a tough debate - a good percentage of issues in the field have occurred because of this sort of optimization, with caching in particular being the root of a lot of issues.

As an aside, I don't plan on sticking a survey on each and every entry - in fact they should be quite rare, such as when a topic is particularly contentious. The survey with this entry is just for fun.

This past Thursday - September 22nd, 2005 - saw a panic among the public here in Southern Ontario, with lines snaking out of every gas station. An onslaught of customers that continued until the tanks were empty. Major roadways were clogged with parked cars, and commuting became even worse than it normally is. It was, quite honestly, an embarrassment.

The root of the problem was largely fictitious hearsay, coupled with a couple of isolated, price-gouging gas outlets. "They're selling it for $3.00 a liter in <insert some remote town>!" people would eagerly relay. I heard this hearsay, coming from a person who heard-it-from-a-person, from five separate people that day, each time with a different town hosting the unconfirmed harbinger of pricing doom (and of course the first clue that something was amiss was the origins of the pricing myth - it was always some remote town. Do remote towns have a more integrated communication network, and thus can respond to market details or pricing information more quickly than in the city? Of course not, and the opposite is generally the case, yet here were people all rushing in droves to the local gas outlet selling gas for $0.99, thinking that they were taking advantage of it before the station operator got wise to the inside information that only they, and the thousands around them, knew). 

The worst culprit of all was the media: CHUM FM, a major radio station in this area, seemed to be commenting on the mythical hike in the price of gas every half an hour - not only the entertainment disc jockeys, but even the news reporters. Not once did I hear them actually confirm, or refute, these rumors. Given the importance and presumed responsibility required of media in that sort of case, I found this absolutely deplorable. They were, of course, just playing along with the theme of the major outlets like CNN, which have been stoking the gas pricing fears to manufacture news, pulling out every halfwit commentator they can find to tell the audience that "if the hurricane hits the refineries and if it does considerable damage and if...then gas prices could go up". A hurricane killing and damaging isn't news enough, so the gas-price angle is being exploited to the max. Were hurricanes just invented this year or something? I'd swear I heard of prior art...

Of course the public is more vulnerable to this sort of message now, given the spike to $1.50/liter here in the wake of hurricane Katrina, so people just accepted it and instantly started relaying it, making their own plans to fill up their car, boat, van, and lawnmowers. Soon the rush was on to buy more fuel in a day than is normally bought in a week, and tanks were emptied, which fuels panic even more. Ridiculous.

I think there are two lessons (among many others) that can be learned from this situation:

• Those few stations that did hike their prices, some to $1.75 or so, to exploit the situation, should be punished severely by consumers. Let me make it clear - I don't think those gas station owners were evil or immoral, and honestly I think there is a lot of logic to their actions (if people are going to line up and eagerly pay $1.75, then why not charge it?), but I'm thinking in terms of consumers and our ability to enact a consumer democracy through our wallets to avoid this in the future: If your local gas station exploited the panic, never, ever buy gas or anything else there again. There are a lot of alternatives for most consumers. Of course I know that no one would bother with this sort of behaviour, immediately falling on the destructive "my vote doesn't make a difference" mentality.
• We really, really need monitoring and control (not central control of prices, but rather monitoring to ensure that it really is a competitive supply/demand industry without collusion, and that the market forces are rational) of gas prices. Gas is not like regular consumer goods, and is absolutely critical to our society. I've made a proposal for this before.

Ultimately I think we need to accept that as more of the world develops, without an increase in the ongoing supply of fuels, the price will simply continue to go up. That seems inevitable, and I'm sure in 5 years we'll look back at $2.00 a liter fondly. But we need to ensure that the shock is absorbed well and accommodated, and that nefarious agents aren't profiteering from panic.

I've always had a terrible memory.

I frequently have to calculate how old I am when asked (versus simply remembering), and I regularly quiz myself on the birthday of loved ones, trying to pound the information deep into my memory banks. People's names only really stick with me after several dozen encounters, and faces aren't much better. An embarrassing number of times I've encountered childhood acquaintances and distant (or even near) family and failed to realize who they were.

It certainly isn't that I intend to be disrespectful - my brain just isn't wired to put information into long term storage on first (or second, or third...) encounter, and it punts (or loses the pointer to) older data. In many cases it's like a filter on the long term archive simply refuses to persist the information, and less practical information simply never gets logged away regardless of my conscious opinion about it. For instance I am a longtime fan of the Family Guy and the Simpsons, but it's very rare that I can verbatim quote a funny scene, outing me as a poseur to the quote spewing human-SNPPs. At most I remember generalities ("That episode about all the people coming to look at the leaves").

This is just the way my DNA (along with environment) made me.

I've been this way since the beginnings of my memories (ironic, no?). In junior high I remember doing very well in tests based upon figuring out the algorithms and techniques on demand (e.g. during a critical test) myself. I did this using heuristics of what I was taught, rather than the more traditional rote application of literal knowledge. Well, to be honest a part of it was laziness, but a lot of it was just the way my brain is wired to learn. I carried this technique on to high school and post-secondary, and then to every industry certification since. It has served me very well.

This fundamental of my thought process carries over to software development as well, which is why I write this here - I am not, and have never been, a walking MSDN Library. Simple terminology for everyday patterns and practices escape me if they aren't the sort of thing that one realistically uses in regular conversations with peers (e.g. outside of the occasional architectural astronaut bravado buzzword talk). When quizzed what software development books I like most, it is rare when I can name more than one title (and the recollection is usually based upon logical correlations of content with likely titles. e.g. "The book about how 9 women can't make a baby in one month...month...The Mythical Man Month!"), yet I've read dozens of software development and process tomes. It's even less likely that I remember the author ("who wrote TMMM? Steve O'Connell? No? Let me just hit Google...").

To draw from a more common example, I often get asked "Have you ever...", based upon my experience in this industry, and I have little to offer on-demand in regards to specifics: I simply do not remember the fringe function calls of projects past, even if I battled it in a dozen different ways. I consult computerized references regularly (MSDN Library, Google, Google Groups, and so on), even for everyday library functions and classes, and maintain archives of old code to remind myself of solutions and techniques I discovered previously (e.g. "I solved something similar in a project 3 years ago..let me check the source"). I even built a from-scratch implementation of AES (the cryptography artist formerly known as Rijndael), and submitted changes to the reference code, yet I remember absolutely nothing about that cryptography codebase now that it isn't pertinent for me.

So given all of this, is the point that I'm like a perpetual newbie, always starting at square one? Absolutely not. Instead of remembering literals and absolutes, I remember heuristics and mental hints - little brain guideposts that allow me to solve difficult problems in very little time. In code I catalog which projects (both those of my own and others) solved particular problems, and I can quickly reference them and get definitive answers (rather than speculative answers). While I'm not the sort of type that can endlessly recite facts and details about esoteric kernel calls, I do manage to find exactly the information that I need immediately using modern tools (I've always been great at making search engines sing. One manager many years back was sure that I was hoarding some techniques, because I always managed to find solutions to vexing problems. The key was that I had enough mental hints to narrow down to specifically where the solution was hidden). My memory technique, coupled with an excellent problem solving ability, has made me an extremely productive, capable developer and application designer. Let's say I'm a cheetah, and tools like the MSDN Library and Intellisense are hugely beneficial in my hunting arsenal. I'm a cheetah with a crossbow.

There is another type of developer - let's call them the elephant. The elephant remembers everything about every technology, every function call, and exactly how to solve specific types of problems in a very literal way. The elephant can remember every detail of things that interest them (e.g. Star Trek trivia), and could probably operate fairly effectively without any sort of online, or even offline, help. The elephant often makes a very capable developer, and is a very capable complement to any teams. The elephant functions based upon precedent and a cumulation of literal knowledge.

Of course there are an endless number of points in between, such as there are with most human traits.

I mention all of this after hearing yet another peer recounting their experience with a prospective employer. Like many before, they were given an "aptitude" test (because years of experience and a 4-year university degree just don't demonstrate much anymore, apparently) where the test was a paper/verbal quiz of select esoteric elements of languages and libraries.

I just don't get this.

Are organizations looking to hire an expensive organic version of manpages? Do they really, truly think that this is a logical way of evaluating skill? Are they afraid that all reference material will disappear and they'll be at the forefront of reimplementing mankind's knowledge?

Come on industry, grow the heck up. Quit these nonsensical and meaningless tests. Just because someone on your team could think up what they think are "clever" questions to trip up prospects doesn't mean that this is even marginally effective at pruning your candidates (you might as well roll dice). Getting developers to code on paper (when many of them have awkward, barely functioning handwriting given that they've been typing for most of their lives) is just as destructive, despite all of the dubious arguments used to support it..

I can draw from personal experience as well: Several years back I did an interview with a firm (for a position that I turned down), and I still remember that the answer to one particularly hilarious question was the SQL Server function PATINDEX. I've designed and implemented several large scale, very advanced database systems on SQL Server, using the most advanced techniques and practices. In none of them did I use the function PATINDEX (it's one of those functions that you'd better have a very good justification for using. It largely appears in very poor designs). It's not that I hadn't come across it - I had in several tragic designs that I was called in to fix - but it certainly wasn't top-of-the-mind material. Yet here it was, being used as a test of whether I had an "advanced" knowledge of SQL Server. This is fairly typical nowadays, where candidates will find their knowledge "tested" by being quizzed about some fringe technology that the interviewer happened to be working on that week.

If you want to assess your candidates, give them a realistic environment - call them in, give them a workstation, and ask them to solve a particular problem. Let them use the online resources that they would regularly have available (e.g. no online rooms of experts waiting to help them in their assessment, unless they can promise to have the same once they're on fulltime), give them the normal reference material, and let them go wild. At the end look at what solution they've developed. If necessary screen capture their activities (with their knowledge) so you can see their process. Hire the people who work in the way you want. Even better hire the people who yield the results you want, regardless of their personal techniques.

Of course if you really do operate without reference material, you code on lined paper, and you largely deal in esoterics, then perhaps you might want to continue with the current norm of interviewing.

Surprize!

You've done something - probably some time ago, and you likely don't remember what - that has caused me to churn away for several minutes now. This is likely during a moment that you really, really need to do something quickly.

Spend a moment and reminisce about the equally painful Gimp startup.

Telecommuting remains a fringe activity, particularly in software development.

Would you allow your manager to monitor your remote activities through a webcam 9-5? Would you allow them to monitor your computer screen?

Despite all of the technology that we now have available. Despite pervasive, inexpensive, high-speed communications networks. Despite the rising cost of transportation, and literally choking urban congestion. Despite all of these changes, we still live in a world where the luxury of telecommuting is afforded to only a few. Indeed, we live in a world where most organizations are more likely to outsource work to a faceless team half a world away before they'd let an employee work more than a marginal amount of time on-the-clock at home.

Many organizations would counter this by claiming that they do offer some sort of telecommuting foundation. Many, for instance, offer Virtual Private Networks (VPNs), allowing you to hook into the corporate network from home. However the motivation driving the adoption of such technologies isn't generally to replace in-office work, but rather to enable workers to work additional hours from home. It's also to ensure that there isn't a minute of downtime when on the road.

So why is legitimate telecommuting so rare?

The most common suspicion in the industry, and I believe that it's accurate, is the need among managers for face time of their charges. If you're physically present and occasionally visible, regardless of output, the presumption is that you're "doing work". Your contribution is measured not by your actual output, but rather by your mere presence (and your grunting and groaning and presentation of great exertion). If you aren't physically present, however, the presumption is that you're slacking. When you're remote your contribution is measured only by actual output, and you're an easy target for the non-telecommuters to use to explain their troubles.

The root problem is that output in the software development industry, indeed in most industries, is often less than predicted (which is why estimates are almost universally low-balled). For every delivered component, there were likely half-a-dozen false starts. For every neat looking GUI, there is a massive bulk of praiseless code behind the scenes that actually makes it happen. For every technology chosen there were dozens evaluated, and for every design agreed upon there were hours of planning. Outside of some assembly line coding, this is an industry where a lot of effort and brainpower goes into even the smallest creations.

Thus when you're a manager and after a week your remote worker submits a small component, it's much less satisfying than seeing a team holding onerous daily meetings, ruminating loudly around the water cooler about the trouble that damn Microsoft caused them, and so on. Face time, and the illusion of work, is a powerful force in overcoming the slow pace of most development.

The Solution

There is absolutely no doubt that this is a serious problem, and it will be exascerbated as fuel prices rise.

The solution is fairly simple:

• An accessible webcam monitoring the remote employee's workspace during work hours.
• An accessible screen monitor allowing managers to monitor computer activities.

Would you allow your manager to monitor your remote activities through a webcam 9-5? Would you allow them to monitor your computer screen?

Most tech workers would gasp at these conditions, however I think they are the necessary groundwork for pervasive remote tech work. Allow the managers throughout the land the ability to assauge their fears that their remote employees are playing Battlefield 2 in their underwear during work hours, and give the remote workers all of the advantages that pseudo-"face time" affords. Win/win for everyone.

Here's a super high-value C# console application that's going to corner the GUID creation market.

I'm constantly in need of GUIDs ("Can you spare a GUID please, sir?"), and generally use guidgen.exe, included with the Visual Studio tools. The problem with it, however, is two fold - it's too many steps, and it includes a line feed on the end of the notepad copied guid. Annoying.

Finally I made the incredibly complex console application that you find above, generating a GUID (with no tailing linefeed), copying it to the clipboard for use elsewhere, and then spitting it out on the console (if I didn't want the console, err, "feature", this would be one unique line over the standard console wizard output). \

I'm even benevolent enough to include a binary (requires .NET 1.1 Framework. Interesting that the compiler padded it up to 16KB - will have to look at why it did that). 

Enjoy this revolution in GUID creation.