Well, 21 postcards later, I'm back a bit early from Spain. More on that some other time, but I promise not to bore you with a play-by-play recap. Instead, here's something I learned from Europe:

The System vs. the Flow

When I met up with pphaneuf in Spain, he complained for awhile about the level of beaurocracy in France. Just for example, it's really complicated and difficult for someone to start a business, rent an apartment, hire someone, fire someone, get a job, rent an apartment, get a bank loan, and so on. It's almost impossible for an outsider to do, because getting anything done depends on who you know, not purely who you are.

Put in those words, North Americans might be tempted to label that "corruption," but it's not, at least not in the usual sense. I didn't have much to say about it so early in my trip, but after spending more time in the middle of European culture, I think I understand it now: they might look kind of similar on the outside, but the fundamentals of American and European civilizations are completely different.

The System

The American system is very mathematically clean, reproducible, and scalable. The ideal they^(*) aim for is a culture in which you can start new companies easily; accept unending supplies of immigrants; fail cheaply; switch tasks, jobs, houses, cities, or specializations quickly. To do this, they built a system based largely on not getting to know people personally; instead, they use detailed statistics and rules to determine what's good and what's not. Borrowing money is easy if you're a "good credit risk"; immigrating is easy if you have the right skills; bankruptcy laws are lax; venture capitalists are everywhere, desperate to give you money, and then they mostly expect you to fail. Most cities are mass-produced based on the scientifically determined ideal road layout and endless copies of identical suburbs and strip malls. The American system is a fundamentally unstable system with controls.

The Flow

The European system, on the other hand, is not really a "system" at all; I'll call it the flow. It never needed to be scalable, because European countries grew slowly over hundreds or thousands of years. Mass immigration was never really an option; there was never a time when most people didn't know most of the other people in most neighbourhoods. And so you don't need the mathematical models of the American system. Should I lend you money? Well, sure, if I know you and you seem like a reliable kind of guy. Bankruptcy? You mean not even trying to pay back the money I lent you? But I trusted you! Well, that's it then, I can never trust you again as long as you live. Not paying back right now is one thing, but not ever trying is just plain anti-social. And hiring someone is okay, as long as you're sure you'll treat them properly and never, ever leave them without a job. After all, your employees depend on you now; you wouldn't want people to think you're unreliable.

If, like me, you're used to thinking about American-style systems, your brain isn't configured to understand the European-style flow. What exactly are the rules they use to determine whether it's okay to start a business, hire someone, fire someone, lend someone money, or build a new building in a certain style and place? It's impossible to answer that question, because it's the wrong question. In the flow, decisions don't need to follow a simple set of rules; you just do what feels right. Your intuition, trained by years of experience, will do the rest.

The flow is a fundamentally stable design; it doesn't need a "control system" to make it work. It just keeps on flying by itself.

France's not-so-imminent collapse

azrhey also told me about the ongoing theory that France's economy is on the verge of collapse - but that people have been saying so for the last hundred years. The "system vs. flow" theory explains this paradox easily: stable designs are never "on the verge of collapse." Only unstable systems are (and they always are!). If you're trying to analyze your stable system as if it were unstable, all your equations will be wrong before you start.

Programming and the flow

Note that "the flow" is another name for the zone; this isn't a coincidence. In the zone, programmers just write the right program without having to think too much about it. No matter what they claim, they're not actually following a bunch of learned rules, but instead just letting the program write itself, intuitively, with their intuition trained by experience. This is exactly how the European cultural flow works. And if you know the feeling of programming in the zone, you can understand why Europeans have higher satisfaction with their quality of life than Americans.

Epilogue

Although they do crash more, unstable systems are usually more leading-edge, more exciting, and more flexible than stable ones.

(*) I would classify the Canadian system as a hybrid of the system and the flow. Whether or not that constitutes a compromise or an improvement is an interesting question to think about.

More on Project Scheduling

cpirate's livejournal has an interesting discussion about project scheduling and specifically Schedulator. I should probably get around to packaging Schedulator up a little better sometime. And somehow I forgot, but just now remembered again, that there is now a mailing list for discussing it.

NiR: The magic of co-op students

Here's my (edited) response to an interviewer who wanted to write about NITI's slightly infamous co-op recruitment and management processes in Montreal, notably the Human Cannonball and Evil Death Ray. As far as I know, NITI no longer uses these job descriptions in their hiring processes and of course I can't speak for their current employment policies, but here's a bit of funny historical information. The format is a bit weird because I'm actually answering some questions that I've cut out of the text. He specifically asked for some "funny anecdotes," so I did my best to comply.

...

In the very beginning it was just two University of Waterloo roommates, me and Dave Coombs, along with the Corporate Dog. We designed the basic functionality of Nitix (now NITI's main product) as a fun side project and we ended up selling it to a few people. They told their friends, who told their friends, and so on, and it became reasonably successful (for a student-run business) but the time needed to do sales and support was distracting us from our studies. That's when the other two co-founders of what is now NITI, Ozzy and Greg, got involved to handle the business side (including seed financing and our new head office in Markham, Ontario). At that point Dave and I managed the technology development (in between classes and exams) while they handled sales and support. In 2001, about three years into the project, we both graduated, opened our R&D office in Montreal, and started hiring additional developers.

...

We started our experience with co-op students on exactly the day we opened our Montreal office. In fact, we had to ask our students to skip the morning and show up at a restaurant for a "welcome lunch" around noon because that was when the landlord of the new office was supposed to come by to drop off the key. I had to run out during lunch to pick it up. That was when I found out the restaurant we were eating at was a 6-minute brisk walk from the office, a fact I used frequently when calculating my meeting schedules in the future.

That afternoon, Ikea delivered the first round of unassembled furniture, which we all spent the rest of the day putting together. The next day we got a load of computers shipped from our Markham office so people could actually do work.

At that time the total set of employees in Montreal was me, Dave, one other full-time developer, and four co-op students. I think having them assemble their own furniture was probably when we started getting our reputation as an interesting workplace for co-ops :)

...

Inside the company Ozzy and Greg took a hands-off policy towards our R&D. In Ozzy's words, "If you keep delivering the right software, I'll stay off your back. If I keep delivering the numbers, the investors will stay off my back." So while we discussed the idea and people thought my job descriptions were a bit crazy, nobody really objected. Besides, those were the days right before the dot-com crash, so people were pretty willing to go for any kind of quirkiness to get people's attention. And it worked, of course.

The technique was surprisingly effective. Despite our tiny size, we were as well known among Waterloo co-op students as Microsoft, Amazon, or Google. They had the big names, but we had the only job descriptions that were fun to read and talk about. I heard at least one story of someone finding the Evil Death Ray job posting printed out and taped to his dorm room door, with a hand-scrawled note that said, "This is you exactly. Go apply, right now!" We ended up hiring him.

That was the real magic of the job postings - they were quirky and they sounded difficult, so they attracted a certain kind of person that was much more likely to be the kind of person we wanted. That meant sorting through fewer, higher quality resumes. A huge company like Google or Microsoft couldn't really do that because they can't afford to reduce their pool of applicants so much, but we were hiring slowly so it was easier to just have the group be self-selecting.

...

We tried to keep our co-op to full-time ratio to about 1:1 (basically a mentor for each student). I think that's a higher ratio than most companies, except for the really exploitative ones (like web design companies, which have mostly co-op students, underpay them, then contract them out to their customers at a much higher rate).

Basically we had a different perspective on co-op than most companies, because the two people organizing the R&D department had just finished being co-op students a few months earlier. So we knew for sure that co-op students are capable of doing great things with minimal supervision - we were living examples!

At most companies, people jump to the conclusion that younger workers are simply unreliable and inexperienced and will do bad work, so you can only give them grunt work or simple tasks they can't possibly screw up. This isn't really true. Students are certainly inexperienced, which means they'll tend to make the wrong assumptions about what needs to be done and how to do it. That's the part you have to watch. But they're also really fast, really energetic, really flexible, and really eager to learn. So the trick is to use a soft touch, make sure they have all the guidance available that they want, but give them big, difficult things that keep them motivated.

Ironically, we found that our co-ops often did some of our best work, sometimes putting full-timers (even me :)) to shame. The thrill of changing jobs every four months means that everything a co-op student does is always interesting to them, while motivating full-timers is actually much more difficult. I don't believe in asking people to work 12-hour days and weekends, but co-ops get excited and do it all by themselves, then they go back to school and tell all their friends to apply with us next time because of the great flex hours. You can't lose with logic like that!

...

My favourite part of our funny job descriptions was that they implicitly gave people permission to send in funny job applications. I have to admit that, even though it wasn't really fair, we always gave special attention in interviews to people who had funny cover letters. One person wrote us a cover letter entirely in perl. I think Dave kept some of the funniest ones.

One student showed up for the interview wearing a tuxedo, wings, and blasting the Star Wars Imperial March from a portable stereo. At Waterloo, there's a big hallway with a bunch of rooms where different companies are interviewing simultaneously. He missed our interview room by accident and walked right past us looking for it. Our interviewer leaned out of the doorway, pointed at him, and said, "Uh, you're probably looking for NITI, right?" He was. He got hired, did excellent work, and (along with another of our former co-ops) has gone on to found his own new software company in Waterloo.

In more questionable news, our past co-op students have also been responsible for the Waterloo Pantsless movement.

If everyone else jumped off a bridge...

"This is sort of the counterexample to what Mom always told you: If everybody else jumped off a bridge, then it is probably okay to jump off bridges." -- Raymond Chen

Lemon products disrupt the market

Bruce Schneier has an interesting article called A Security Market for Lemons, in which he discusses how in security products, bad products are actually more likely to sell than good ones.

The super-quick version of the story is that, if buyers can't easily tell which product is best, they'll assume that all products are worth the "average value." Bad products ("lemons") reduce the overall average value, so that the best products necessarily cost more than the average and nobody's willing to buy them. So people stop making those, lowering the average further, so people stop making the next-best ones, and so on.

It's a very interesting unstable system.

BarCampMontreal2: the (missing) women of tech conferences

On Saturday I went to BarCampMontreal2 where there was a presentation called "Where are all the girls?" by Martine Pagé.

I don't currently have an opinion on the whole issue and its direct relative, the "women in tech conferences" issue, because I don't really have enough information to form a considered opinion. But with that in mind, what information do we have, anyway?

We can start with some statistics. Martine quoted an article with statistics on male vs. female speakers at tech/web/design conferences. The number of female speakers varies, but is typically about 15-20% and is as high as 30% (at only one place). Now, what do those numbers mean? A couple of things. First, while the overall human population is about 51% women, the population of women speakers at tech conferences is... less. So tech conferences are biased, right?

Well, not exactly. Everyone knows that the tech industry is itself biased. According to a Stanford University study, 32% of the IT workforce in 2004 was female. This implies that speakers at tech conferences underrepresent, but not hugely, the population of women in technology overall: 20% speaking out of 32% overall.

But one statistic that's not given is how many women attend tech conferences. That number would help break apart two stats: the number of women who are interested at all, vs. the fraction of those who are willing to make presentations. At BarCampMontreal2 the attendees were about 10% women, while the presenters were about 20% women. That means women who attended were more likely to present than men who attended. How come? Now that's something worth discussing.

Furthermore, the majority of male presenters talked about technical or business topics. The four women that I saw present (I apologize if I'm leaving someone out; I missed about half the conference) talked about WikiTravel (technical), Travelling Alone (non-technical), Lucid Dreaming (non-technical), and Women in Technology (social issues). In other words, 3/4 of the topics were "geeky but non-technical" and thus were just fine at a BarCamp, but wouldn't have been found at a normal tech conference. What does that say about the reasons women don't attend tech conferences? What does it say about the social effect of BarCamps?

Footnote

We should probably be thanking sfllaw, who I suspect was single-handedly responsible for skewing the above statistics.