My training up to this point has been terribly lax, I’ve been running 7km in about an hour. At this pace it’ll take at least 3 hours to break 20kms - Ouch!

If you're interested in donating (or better yet, joining the run too), then follow these steps:

1. Visit The Canadian Diabetes Association
2. Search for Adam Kahtava
3. Donate

Anyhow; life isn't just about geeking out. I've got to run. :)

The topic of our discussions reminded me of something David Heinemeier Hansson said when talking about software development:

You don’t need to be a f***ing genius to make any of this stuff work, it’s not rocket surgery! - David Heinemeier Hansson at Startup School 08

DeMarco and Lister also echoed this outlook back in the 80’s, and publicized: the High-Tech Illusion:

the High-Tech Illusion: [is] the widely held conviction among people who deal with any aspect of new technology … that they are in … high-tech business. [These people] are indulging in this illusion whenever they find themselves explaining at a … party, say, that that they are “in computers” … The implication is that they are part of the high-tech world. [These people] usually aren’t. The researchers who made the fundamental breakthroughs in those areas are in the high-tech business. The rest of us are appliers of their work. - Peopleware : Productive Projects and Teams

If we were in the High-Tech business, then we’d be the bottom feeders (the parasites, the grunts), because our daily activities revolve around consuming other peoples research and work (programming languages, platforms, frameworks and the like). We are consumers, we’re not on the cutting edge nor are we in the high-tech world.

Perhaps building software could be much like outfitting yourself for a day in the snow. You head off to the local shopping mall, you acquire the functional items to keep yourself warm, but brands and store choice don’t really matter. Whether we’re buying winter boots or choosing a programming language, technology doesn’t really matter. There are an infinite number of ways to solve any problem, as well as an infinite number of technical permutations to form a solution. If we can solve the problem within the constraints of our problem domain then we’ve succeeded.

The High-Tech Illusion often permeates my world - I work as a Web Developer in the Microsoft realm. I continually see the High-Tech Illusion manifests itself in these situations:

• Colleagues talking in vague opaque high-level metaphors that patronizingly shield you from the inter working of what they assume is beyond your comprehension
• Fixations on specific tools, hardware, platforms, and methodologies while the problem that needs to be solved is diluted and any combination of these items could solve the problem
• Colleagues that assume superiority and can’t acknowledge that knowledge is acquired through research and a continual efforts to improve

Pretentiousness in the software realm (in teams, organization, and so on) is usually the byproduct of someone that’s living the High-Tech Illusion.

I’ve been guilty of subscribing to the High-Tech Illusion. How does the High-Tech Illusion permeate your world? How can we get back to reality?

Steph (my wife) and I had been toying with the idea of getting a dog, we've been looking at different breeds, visiting shelters, and emailing breeders - I have to give Steph all the credit, she did most of the research. Anyhow, we came across a post on our Kijiji for a mature Soft Coated Wheaten Terrier. Now we have a dog.

Being a Geek and all, I wasn't sure if I was a dog (or cat person), but Belle is a great dog. Her constant need for a walks is a great reminder to take a micro break while working from home.

Belle, our dog.

My highlights:

• The session on Agile Project Planning With User Stories, and Refactoring Automated Unit Tests Using Test Smells and Patterns presented by Gerard Meszaros. I’ve been on a couple projects that could be characterized as “Bad Agile”, so Gerard’s presentation hit many chords, one of the comments he made really stuck out. He said something like: “it’s not about the Agile process, it’s about the results, it’s about delivering…don’t be dogmatic”. Sure it’s obvious, but it’s nice to hear it from someone else.  I’m currently in the process of purchasing Gerard’s book: xUnit Test Patterns: Refactoring Test Code.
• Mock objects with Rhino Mocks was another great session (by Shane Courtrille). I’ve been using Rhino Mocks for a couple months now, but there’s always so much to learn from someone with more experience.

I’m trying to make it a point to attend more of these events in an effort to expand my community.

Some of the types of interviews I attended:

A pop-quiz / quiz show type interview, where the interview shook my hand, sat down, and proceeded to run through lists of questions procured from the internet - afterwards, I was able to find the question list the interviewer had quized me via the internet. This went on for an hour or so, when the interviewer ran out of questions he abruptly stood up, shook my hand, and left me to find my way out. 

Reflections: from what I observed, their corporate environment differed significantly from what was presented on their corporate webpage. In addition their interviewer and interview style contradicted their corporate statement of values and corporate culture. I should have been better prepared, but without a specific job description it was difficult to prepare. Many red flags were raised - most large companies should have a formal interview process or an HR department, shouldn’t they?

The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means “knows a lot of facts.” They just ask a bunch of trivia questions about programming and give points for correct answers. - Joel Spolsky: The Guerrilla Guide to Interviewing (version 3.0)

A write the code first interview, where I was greeted by a nice HR lady, shown to a room with a computer and given a test with a one hour deadline. In the second interview I was met by two developers, I was given a couple white board questions, and asked resume related questions.

Reflections: this company seemed to have many different job descriptions for the same position, the nature of the work didn’t vary, but the educational requirements did - their job descriptions individually targeted a High School, a College, and a University Grad. Their job discription was vauge, and wide - it seemed like they were trying to pull anyone in. From what I observed, the staff looked exceptionally young, the interviewers looked tired, and the computer I wrote my test on was old. I did like that I had to write code through the interview process, but again many flags were raised - mature employees are a sign of a healthy work environment, tired interviewers with transparent skin don’t give off good first impressions. 

the behavior of interviewers influences their decision to accept a position, … despite the fact that companies are increasingly desperate for talent, many are becoming their own worst obstacles when interviewing qualified candidates. Among the sort of behaviors that adversely affect job seekers’ willingness to work at a company are interviewers who are aloof … - http://www.management-issues.com/2007/8/9/research/poor-interviewers-driving-away-talent.asp

Anyhow; I’m now happily employed, and working with a great bunch of developers on an exciting Agile project based around Test Driven Development (TDD)  / Unit Testing, Continuous Integration, and the .NET Framework!