Adam.Kahtava.com / AdamDotCom

Gross Generalizations: Software Evangelists, Rock Star Developers, Senior Developers, and Software Architects

2008-07-13T11:14:03.317-07:00

Generalization like rumors usually have some truth to them – at some point, someone formed a thought around a frequently observed piece of truth and… Viola! A generalization was born (or maybe a rumor). Generalizations are incorrect for every single possible case (the exceptions), but there is truth to them.

That’s my disclaimer; now let’s have fun with generalizations.

The Software Evangelist

The epitome of an Evangelist can be observed on Sunday morning TV:

"SHEBBA-WABBA-MULLA-MONEY-POWER-BOOYACKA-POW-BOW!!!!"

A congregation frying like bacon on the floor (being moved by spirits), 800 numbers requesting money seared into your TV set, and an Evangelist at the helm orchestrating the show.

Evangelists are a great source of inspiration, excellent communicators, and great leaders. However, they often present a one sided biased opinion, a narrow focus, and can be driven by ulterior motives (money, power, viewership, readership, etc). Listen to any Evangelists with a grain of salt.

Rock Star Developers

Rock Stars are on MTV, and featured in tabloids - they live hard and die young.

The lyrics of Great Big White describe the life of a rock star:

Well I'm a wasted rock ranger
I live the life of danger
On the road to find a higher high
I don't need no one's affection
All I need is my injection
The music of wild rock will get me by

Some companies seek out "Rock Star Developers", here’s an excerpt from an email I received:

are you a Rock Star? I have an opportunity for a rock star … I am reaching out to you in the hopes that you might the star I and the client are looking for!

So, what is a Rock Star Developer? My perception is a: narcissistic, self-centered, prima donna – someone who doesn’t work well in a team, doesn’t listen, does whatever they want, and lacks dependability. Hiring a Rock Star Developer probably isn’t recommended - unless your organization has a liberal guitar smashing policy, doesn't mind drunken belligerency, and is run by a one man show.

Senior Developers

Everyone wants a Senior Developer, but occasionally these developers are more senior than developers, and certainly not senior developers – often the developer's age (not experience) determines their title. Studies have shown that a developer with 2 years experience can perform at the same level as a developer with decades of experience. Still some Senior Developers have an unexplainable need to let the world know of their seniority through email signatures, resumes, business cards, LinkedIn profiles, and so on.

If you work for 10 years, do you get 10 years of experience or do you get 1 year of experience 10 times? You have to reflect on your activities to get true experience. If you make learning a continuous commitment, you’ll get experience. If you don’t, you won’t, no matter how many years you have under your belt. - Steve McConnell, Code Complete 2nd Edition

Software Architects

Software Architects can be glorified Senior Developers - an architect might be a developer who is senior (like a curmudgeon with a walker) that needed a new title.

Thoughts on generalizations:

There are two sides to these generalizations, the people who claim to be, and the people who are. The people who claim that they’re a Senior Developer are usually impostors, whereas the person who is a Senior Developer is collectively regarded as one by their peers.

Generalizations (like metaphors) are communication mechanisms, sure, there are edge cases and exceptions. Occasionally I encounter aversions to generalizations. Responses like: "Hey that’s not completely true, X,Y,Z disproves that", or "Naw... that’s just incorrect" seem to be made when we forget that we’re just using generalizations.

What generalizations stick out in your mind?

2008 Summer Reading List: What Are You Reading?

2008-07-01T11:04:05.339-07:00

Summer is finally here! Well... "here" as in, "here in Canada" where we have 8 months of winter, fall, and spring...

This summer I hope to finish up the following books:

Windows PowerShell in Action - PowerShell is a shell scripting language for Windows. I’m a command line / keyboard junkie, and I’m hoping PowerShell can further automate some of my day to day tasks inside Windows.
Domain-Driven Design: Tackling Complexity in the Heart of Software- From what I’ve read so far, this book is great. I’m also reading this for the Edmonton Computer Book Club.
Software Creativity 2.0- I’m a Robert Glass Fan boy (I'll read anything he writes). I've had this book on my must read list for a while now.
Inside Windows Communication Foundation - I make use of WCF every day, and would like to learn more about the unknown nooks and crannies that lie within.
The Ruby Programming Language- An amazing book (it even has illustrations). The Ruby language is fascinating, terse, and elegant, I’m curious to see how I can make use of Ruby in .NET since IronRuby has been released. This book also happens to be fun to read.
A Random Walk Down Wall Street- I'm trying to brush up on how to make better investments. The author starts off by telling you that most people working in the trading realm are crooks... :)

Books and reading are essential for personal and professional development. The more you read, the more you understand and the more resources you have to fall back on.

What books are you reading this summer? Do you have any recommendations?

Joining The Dual Monitor Club: Getting a New Computer: The Ultimate Developer Rig

2008-06-23T10:17:08.322-07:00

In this picture: My Charles Babbage mug, books: Domain Driven Design, the Ruby Programming Language, the Definitive Guide to JavaScript, my Evoluent VerticalMouse, and lots of Red Rain empties.

One of my biggest pet peeves is trying to efficiently complete development work on a slow machine. In my mind, trying to work quickly on a slow computer is like asking a marathon runner to wear snowshoes then demanding they WIN the marathon. What ensues, is painful for the runner, painful for all who watch, and reaching the end goal feels impossible - bottom line good equipment matters. However, many client's overlook the relationship between getting stuff done and a slow machine, or they don't care, or they can't do anything about it.

Maybe they find it thrilling (in some sick way) to watch your soul fizzle away as you spend 300 minutes a day compiling your application (or running your tests). :)

In great organizations slow machines aren't an issue. According to the The Programmer's Bill of Rights: "Every programmer shall have a fast PC", and from the Joel Test: "[Organizations should] use the best tools money can buy?"But reality is often a different beast, and in my experience you have to make the changes you want (or "be the change you want to see..." - Gandhi).

I'm sure in Silicon Valley, good computers would be mandatory for most organization, but I live in Canada - we suffer through black flies, mosquitoes, 8 months of winter, and organizations with poor resources. :) Did you know that Canada's population is roughly equivalent to the population of the state of California alone!?

Anyhow, I started working from home full-time this year - up to this point most of my work has been done onsite using whatever machine the client provided (some with outdated hardware). My home desktop was a six year old PC that would make Frankenstein look sexy - it was a collection of old and new parts. Since, I do most of my work in Virtual Machines (I typically have three VMs running) performance is absolutely critical. After spending a month working on my dinosaur of a machine, it was clear I needed a new computer.

Leave me a comment requesting the details, and I'll happily bore you with the technical specs of my old machine including a story of where I acquired each component. :)

I based my specs on Jeff Atwood's and Scott Hanselman's specs for the Ultimate Developer Rig. The machine turned out to be economical, the prices have come down significantly since the initial post was published, and to top it all off, I was able to chop shop my old machine and sell every single part through eBay and Kijiji - for a surprisingly decent price too (who would have thought a 6 year old Sound blaster Audigy would sell for $50?).

Contrasting my setups:

Then Now
Processors Two 32bit AMD MP 1.2GHz Quad Core 64bit 2.4GHz
RAM 3.5 GB 8 GB
Monitor(s) A single 17" Two 22" Samsung SyncMaster 226BWs
Personal Pain Points Excruciatingly painful Occasionally painful (only Vista induced)

Working on my new machine is enjoyable. I find myself more productive without being distracted by the frustration of a slow machine, and having dual monitors also contributes to my productivity (Does More Than One Monitor Improve Productivity?). My favourite parts of the new setup are the monitors, the Ergotron stand, the speed, and the Case. You really get what you pay for with LCD monitors, the SyncMasters are easy on the eyes when compared to my old economic Acer, and the case is dead silent.

In the future, if I'm provided with a substandard PC, you can expect to see me hauling my new machine into the office. :)

Take a look at my old desktop setup in my older post: Something About the Cobbler's Children Having No Shoes

Have you ever had to use an outdated machine as a developer? How does working on a slow machine effect your work? What are your thoughts on taking matters into your own hand (like purchasing your own computer to replace the slow one at work)? Have you ever installed additional resources in the computer you use at work?

Strange Interview Questions === No Job

2008-06-18T15:11:46.879-07:00

I was asked a series of questions during an interview that I'll never forget.

The interview was at a successful company in the process of growing from a start-up. They offered a fantastic work environment, the developers had dual 22" LCD monitors, state of the art machines, fooze ball, and to top it all off, they had a cafeteria with two gourmet chefs - I even had lunch there, it really was good food! It could have been a great place to work, but... the interview left me running for the door.

Some of the unnerving questions:

"Do you smoke? Does anyone in your family smoke?"

It turns out that they had a strict no smoking policy written into their contract. Yup... You had to sign, that you and your family will remain smoke free (including second-hand smoke) for the duration of your employment. While I don't think smoking is smart, and can see some benefits of having an explicit no smoking policy - still... this question took me off guard.

Potential benefits of a strict non-smoking policy:
More productivity (no cigarette breaks for employees), an odour neutral working environment, fewer employee sick days, cheaper corporate health insurance, and it could filter out potential drug users.
Draw backs:
Rapport with the interview team was immediately shattered, it's probably illegal to ask this question in the first place. It was an invasion of privacy (If you're demanding this, what's next?). It felt very Orwellian (Would they have Big Brother monitoring us too?), confusing (How can I control second-hand smoke?), and just weird (Would I be fired if someone planted a pack of cigarettes in my desk?).
"Do you play video games?"

There was another sigh of relief when I answered "No". I don't play video game - well... aside from playing Tony Hawk on my classic Play Station every 6 months or Pong on my cell phone. I have better things to do than play video games, even if it's doing nothing - like watching the paint peel off my wall (clearing my mind). Besides, isn't having a computer monitor (or monitors) larger than your CRT TV a requirement for entering true Geekdom? Seriously though, I've watched family members and friends drain their lives into video games, as a result I'm not crazy about video games (but the Wii is fun). This question, like the previous was another negative hit for my employment prospect.

Potential benefits of having non-gamers as developers:
Better rested and more productive employees (they wouldn't be staying up all night playing World of Warcraft), fewer sick days, and more focused employees (web surfing for game tips would not be an issue).
Draw backs:
Being a gaming doesn't say anything about your skills as a developer. I started to get the impression that productivity really matters to this organization. I felt confused (Why is this so important? Is there something they're not telling me?), and it was another blow to privacy (Who really cares if your employees play games?), and a blow to trust (Will I have to answer questions like this everyday? I'd like to maintain some freedom, what if I decide take up gaming?).
"Do you have a problem with being at work at 8:30 sharp every morning?"

Now scenes from A Clockwork Orange are flashing through my mind - I'm being strapped in a chair, eyes pried open, hands chained to a keyboard, I'm being interrogated on the events of last evening, followed by a nicotine breathalyzer. OK... they didn't embrace flextime. This organization was not a good cultural fit, too many weird questions, interview was officially over in my mind.

Potential benefits of a regimented routine:
Uhmm... I guess, you know when your employees should be at work.
Draw backs:
Going to work could feel like tree planting / boot camp / the army, demanding rigid hours could imply a lack of trust in your employees, demands like this would certainly engender turnover, and companies with high turnover are bad places to work (there's a cost for turnover).

Some smaller companies might like to know their candidate at this level, and if that's the case then take them out for a couple drinks or dinner - try to learn these questions, don't outright ask them. Questions like these might hurt the reputation of your organization, after this interview I was resisting the urge to run for the door, and since then they've asked me to recommend potential candidates.

What kind of interesting interview questions have you been asked in the past?

Living The High-tech Illusion: Software Development is Not Rocket Surgery

2008-06-15T12:50:02.199-07:00

#CalgaryBarCamp was swell. It was refreshing to meet such a diverse group of like minded people that all essentially do the same thing (create software), but do it in different ways using different tools, platforms, and languages. The ad-hoc discussions both in the bar and between sessions were my highlight. A reoccurring theme in our conversations was that technology, tools, and platforms don't matter that much. What really matters is: people, communication, ideas, taking risks, and motivation.

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?

How I Got Started In Software Development: Confessions of a Script Kiddie

2008-06-13T16:45:53.489-07:00

Ahh yes, the bowl cut. Simple to maintain, keeps the cold off the brain.

Me around age 12, and not much has changed. :)

Maggie Longshore (tweet: MaggiePlusPlus) posted her response to Michael Eaton's (tweet: mjeaton) initial post on: How did you get started in software development? I had fun reading the other contributions so here mine...

How old were you when you started programming?

Somewhere around the age of 8 or 9.

How did you get started in programming? What was your first language?

My dad went to College for robotics when I was around 8 years old, so he was really into programming (programming robots) and we worked through a book on the BASIC programming language. After that I continued to mess around with BASIC and wrote scripts so I could get at my favourite games. Later I was frequenting BBS's, and surfing the internet through a text based browser. I eventually became a Script kiddie - in retrospect, being a Script kiddie was what really turned me on to programming. My friends and I would write our own IRC war scripts take over local channels, we'd play MUDs late into the nights, and try to figure out how Trumpet Winsock, networks, mIRC, and HTML worked - those were the days of Netscape 1 (the version with the big glowing 'N'). Later we tried writing our own version of NetBus with the help of C / C++ programmers on IRC channels - the fragments of the C language these programmers shared with us were magical, they really sparked an interest in programming. In addition to all this my dad kept a constant supply of computer parts funneling into our house, my brothers and I would build computers from the parts - today my closest brother is a Linux guru, evidently all this sparked his interest too.

I've digressed, short story, programming has always been a part of my life, BASIC was my first language.

What was the first real program you wrote?

I followed a couple game tutorials in my BASIC books, but my first real program would have been Pacman in Turing - in my final year of high school I enrolled in a computer course, where the instructor let us choose our own adventure I chose to write a game.

What languages have you used since you started programming?

BASIC, Turing, Pascal, Assembly, COBOL, C, C++, LISP, Java, JavaScript, PHP, VBScript, most of the .NET Languages, and so on...

I've spent the most time in C, C++, C#, JavaScript, SQL, and the mark-up languages. I primarily program for the web or at least for the network.

While using multiple languages are great, I really believe that we you should completely understand the fundamentals of at least two languages (like say a static language and a dynamic language), because:

"Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity." - Steve McConnell, Code Complete 2nd Edition.

What was your first professional programming gig?

If by professional you mean worked at least 20 hrs a week and was paid, then I would have been 18. It was my first year of College, I needed a part-time job in order to live (In Honour of the Student Loan), I worked on an assembly line. I would occasionally help the office workers troubleshoot their IT issues and soon found myself working as their network admin / computer gopher. I went on to develop their cataloging system and a website. At the time I was going to school for Electronic Engineering, but decided to switch to a Computer specific program. Pervious to this, I had freelanced a couple websites for local businesses.

If you knew then what you know now, would you have started programming?

Absolutely! The industry continues to instill a sense of wonder in me. I can't imagine doing anything else.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Read! You'd be surprised how little progress has been made in the software industry over the past 30 years. By reading we can learn from the mistakes others have made.
Don't be intimidated by code or frameworks handed down by large organizations, their code isn't any different than yours.
Hard work always pays off, or as Thomas Edison said: "Success is 10 percent inspiration and 90 percent perspiration."

What's the most fun you've ever had ... programming?

Collaborative programming is always fun whether it be paired programming or working together on a project. It's hard to pinpoint the most fun I've "ever" had, because it's all fun. :)

Now it's your turn to answer: How did you get started in software development?

Book Reviewed: JavaScript: The Good Parts by Douglas Crockford

2008-06-07T16:32:33.798-07:00

Weighing in at 140+ pages of content, JavaScript: The Good Parts [Douglas Crockford] cuts through the obscurities, pleasantries, and filler found in most technical books. Instead, this book dives straight into the heart of the JavaScript language. It presents the clearest comprehensive explanation of what makes JavaScript a great programming language that I've encountered to date. It nails the important concepts, like JavaScript's: object oriented nature, its classless (pseudoclassical) nature, and functional nature. While covering the fundamentals like JavaScript's: functions, lexical scoping, lambdas, prototypal inheritance, and functional inheritance.

This book's size makes it approachable for all audiences, its style is terse and concise. This book has the potential to do for JavaScript, what Richie's inspirational classic the C Programming Language did for the C language.

JavaScript is the programming language of the web (AJAX), and this book will guide you through the good parts of this often misunderstood language - while this book is an excellent reference, it is not intended to replace JavaScript: The Definitive Guide, you'll do best to have both these books on hand.

If you enjoyed (or are considering) this book then you may want to learn more of what Douglas Crockford has to say, check out his great JavaScript video series on the YUI Theater.

I highly recommend this book. View my review on Amazon.

Writing a Control for the AJAX Control Toolkit: Something Stinks

2008-06-07T12:19:42.099-07:00

One of my resolutions this year was to contribute to the AJAX Control Toolkit for the ASP.NET AJAX Framework. I began my AJAX Control Toolkit development quest by digging into the online resources, reading ASP.NET AJAX in Action, and decomposing the AJAX Control Toolkit. I noted the huge learning curve required to developing a control, and continued to dig deeper. Once mired in ASP.NET AJAX a bad smell kept wafting by. Since then I've been trying to distinguish this smell.

What's really wrong with ASP.NET AJAX? What's that bad smell?

It doesn't plan for performance from day one
It treats AJAX as a classic computer science problem
It tries to turn JavaScript into a classical language which works against JavaScript's dynamic, prototypical nature

A Case Study: Why Plaxo.com Almost Failed

In the video: High-performance JavaScript: Why Everything You've Been Taught is Wrong (YUI Theater) Joseph Smarr discusses the challenges and lessons learned while developing Plaxo.com. While developing this AJAX centric application, the Plaxo team decided to include everything they could think of (including the kitchen sink) into their application. They created a framework to treat JavaScript as a classical language, they gave priority to features over performance, and... the project ALMOST FAILED. They were able to salvage their application by diverting their development efforts, making performance one of their top priorities, by unlearning everything they'd been taught about classical applications (instead embracing JavaScript), jettisoning unneeded framework bloat, and more.

Some of the points made in this video were:
Plan for performance from day one
AJAX is not a classic problem
JavaScript is not a classical programming language
User experience and a responsive application can make or break an application
Unneeded bloat in a framework, and an obtuse approach to using AJAX (treating AJAX and JavaScript as a classical language or classic computer science problem) has the potential to cripple your application
This Channel 9 video also mirrors these sentiments: Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript

How ASP.NET AJAX Failed: What can we learn from Plaxo?

The way the Plaxo team approached their application development is similar to how the ASP.NET AJAX Framework has been designed. Like Plaxo's initial attempt ASP.NET AJAX attempts to mold JavaScript into a classical language, and attempts to treat JavaScript and AJAX as a classic computer science problem by heaping on more abstractions. Like Plaxo's initial attempt ASP.NET AJAX also gives a low priority to performance. Plaxo was able to change their direction and salvaged their application, but the ASP.NET AJAX Framework is not in a position to make any sweeping changes - ASP.NET AJAX is going down the wrong path and it's too late.

The ASP.NET AJAX Framework is probably another exercise in Framework Architecture (Demoware) and a failure in practice. Its lack of use in the wild attests to these shortcomings - contrast the sites using ASP.NET AJAX with the sites using jQuery (Actions Speak Louder Than Words). Furthermore the places that ASP.NET AJAX does thrive (the small internal ASP.NET business apps that need some bling-bling) will also be the areas that Silverlight shines - Silverlight offers a better Microsoft centric programming model (less leaky Win Form / Web Form abstractions) that most Microsoft developers will embrace. Silverlight will probably divert the developers that currently embrace ASP.NET AJAX.

I don't recommend the ASP.NET AJAX Framework and won't be contributing to the AJAX Control Toolkit. My time is better spent elsewhere.

More on the perils of The ASP.NET AJAX Framework

2008-06-03T08:06:27.502-07:00

There's no need to whip a dead horse (I've probably been griping about the ASP.NET AJAX Framework for too long), but... Jon Galloway and a group of other notable gurus (K. Scott Allen, Scott Koon, and Kevin Dente) have started a podcast, their latest segment sparked my interest since it covered ASP.NET AJAX and AJAX Libraries / Frameworks in general.

I share their sentiments so I thought I'd post a brief but choppy transcript:

[ASP.NET AJAX] ... does offer some some nice features, they did try to take some of the common pieces of the CLR that [.NET Developers are] used to working with and move that down into a JavaScript library. So you get classes like a WebRequest class that wraps the XMLHttpRequest ... and they have a StringBuilder, and they added methods that we're more accustom with ...

that's wonderful, but I don't find myself needing those extensions all that often. If you want to do strictly client-side programming then something like jQuery offers you a lot more capabilities to do things that you really want to do client-side like sorting and CSS selectors. ... That stuff is easy to do with an Update Panel and ASP.NET, but Update Panels aren't always the best solution to use. ...

the goals with ASP.NET AJAX was to integrate into the ASP.NET server-side model ... that's great for ASP.NET, but it needs more client-side features. ... It works if your thinking from the ASP.NET control perspective, but if you look at it outside the ASP.NET model there are a lot easier ways to do it. ...

ASP.NET AJAX [development] seems to have come to a standstill I'm not seeing a lot of development in that area and the rest of these [AJAX] Frameworks are doing monthly releases. Every month that goes by [the ASP.NET AJAX Framework] falls further and further behind ... it needs to evolve.

Listen to this great podcast here: Technology Round Table Podcast #2 - AJAX Frameworks

The Good Parts of The ASP.NET Framework and Visual Studio

2008-05-31T14:56:37.992-07:00

Douglas Crockford opens his latest book with these words:

Most programming languages contain good parts and bad parts. ... [the language designers or architects] are usually powerless to do anything except heap more features on top of the existing pile of imperfections. And the new features do not always interact harmoniously, thus producing more bad parts. - JavaScript: The Good Parts by Douglas Crockford

His words can apply to all programming languages and frameworks. Especially the ASP.NET Framework and Visual Studio.

Bad parts in the ASP.NET Framework and Visual Studio:

ASP.NET Themes and Skins
The ASP.NET AJAX Framework
ASP.NET / Visual Studio Inline Style Properties
Visual Studio Design View
ASP.NET and Visual Studio's over dependency on XML configuration files

It would be great if someone wrote a book outlining the good parts of ASP.NET and Visual Studio. :)

What bad parts do you steer clear of?

Getting a Job at Google: A Web Developer Fizzbuzz

2008-05-24T14:03:23.537-07:00

Back when the web turned 2.0, AJAX was all the rage, and gas was cheap, a Google recruiter contacted me. We worked through a couple screening interviews - I explained how I was a .NET / ASP.NET / C# developer with some experience with Java and PHP, I described how C# was somewhat similar to Java. Things went great, I moved on to the next step of the process - writing code (a JavaScript widget for Gmail) with a 2 day (weekend) hard deadline. At the time I was wearing JavaScript diapers, but tried the exercise anyways - I'm still convinced the recruiter confused my Java / C# experience with JavaScript. Anyhow...

The Google Web Developer Exercise:

Web Developer Exercise
Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.

After my first attempt, I concluded that:

My JavaScript knowledge was embarrassing
Dynamic programming languages like JavaScript using prototypical inheritance were awesome - as a monocultured .NET developer I had sorely been missing out
Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers - we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL - NOT just a single multipurpose language or framework
Innovation can only happen when you become one with the technologies surrounding your realm - for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer, David Heinemeier Hansson would have never created Rails had he been an exclusive ASP.NET developer, and Scott Guthrie would never have developed ASP.NET had he been an exclusive ASP.NET developer. Diversity is essential for innovation

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: , or href="Javascript: do something;" ... are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

Cross browser compatibilities and work arounds for both JavaScript and CSS - with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
An understanding of the separation of concerns - JavaScript, markup, and CSS should be separate files, or at least separated within the document
Event registration and listening - DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
An understanding of functional languages - closures, namespaces, lambdas, recursion where necessary
Node manipulation - creating, swapping, removing elements
Knowledge of non-obtrusive JavaScript techniques
Importance of modular / compartmentalization of CSS and JavaScript - defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
JavaScript code conventions - naming conventions, statement conventions
CSS naming conventions
General DHTML / AJAX techniques - showing and hiding elements
A gauge on their attention to details and UI design intuition - what their gut tells them to do when things aren't spelled out

My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, GoogleExercise.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels - feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

Today I still think about Getting that job at Google, Yahoo!, Amazon, or Microsoft. How well do you know JavaScript?

Actions Speak Louder Than Words: Goodbye ASP.NET AJAX

2008-05-15T15:35:19.847-07:00

An anticlimactic conclusion about the ASP.NET AJAX Framework - this framework's niche seems to be the internal (intranet) business application realm that depend on ASP.NET Web-Forms. These applications have a handful of users, a couple developers, no performance or bandwidth requirements, little ambition for future growth, and the developers typically embrace dragging & dropping controls in Visual Studio. In this case the ASP.NET AJAX Framework provides some eye candy, and patches the broken Web-Form metaphor by cramming AJAX into the ASP.NET model, but then comes along the ASP.NET MVC Framework, Silverlight, WPF and ... ??? Goodbye ASP.NET AJAX!

Interesting observations:

How many applications explicitly state that they use the ASP.NET AJAX Framework?
25, this includes sites like DotNetNuke (with a reputation of being slow), view the list here.
How many of these applications are relatively high-traffic?
None. ZERO!
How many applications explicitly state that they use theYUI AJAX Library?
89, view the list here and here.
How many of these applications are relatively high-traffic?
Quite a few. A couple notable sites: Flickr, Slashdot, Linkedin, Paypal, O'Reilly, My Opera.
How many applications explicitly state that they use thejQuery AJAX Library?
516, view the list here.
How many of these applications are relatively high-traffic?
Many. A couple notable sites: Twitter, Digg, Dell, Slashdot, BBC, Netflix, Technorati, New York Post.

If no high-traffic application uses the ASP.NET AJAX Framework then why would you? Actions (or lack of action) often speak louder than words, and it appears that the ASP.NET AJAX Framework is not suitable for the real world.

Education is a Great Investment: In Honour of the Student Loan

2008-05-10T11:41:27.178-07:00

As a student I was a pathological penny pincher, but as much as I've complained about student loans, I'm also grateful for them. Sure, it would be great if Canada could adopt an approach like Finland and other European countries where education is free, but that's not in our cards.

Why are student loans good?
I grew up in a small village in Northern Ontario, in a huge family - in total there are 11 of us. YES! I have 8 siblings and we all have the same parents. :) Most Canadians are familiar with the rural community setting (maybe not the huge family scene). A railway runs through town, the town has 2 gas stations, a single postal code is associated to the entire area (including all the outlying hamlets, and farms), the local high school is 30 minutes from home, the high school kids are bussed from a 100km radius (and there's still only about 700 students in total). Most of your childhood is spent: crawling across beaver dams, building tree forts, playing Lego, banging away at BASIC on rainy days, swinging from ropes in barns, chasing sheep, skateboarding, and shooting guns. Most of the residents in these towns live modest lives, and have chosen the rural community because it's cheaper than living in the neighbouring city, or they have just always lived there. The residents are employed in the dwindling lumber industry, the agricultural industry, the local businesses, they are seasonal workers, or unemployed.

In short, living in these remote communities can be economically challenging, supporting a massive family in these areas can be difficult, and receiving educational assistance from your family is even more difficult. So... If it wasn't for government funded student loans I probably wouldn't have gone to College/University, and if it wasn't for an education I probably wouldn't have been able to develop the skills necessary to be where I am today - yesterday I paid the last of my Student Loans. :)

Thank-you Government of Canada for the student loans!

For all the students out there, keep your chin up, keep your eyes on the goal, don't let finances get you down, focus on your studies, and keep pushing forward. Education is a sound investment in your future - provided you're not going to school for underwater basket weaving, or attending an atrociously expensive private college, and not going to school forever (everything in moderation, right?). As the old adage goes: "you've got to spend money to make money", and education is a sound investment.

Griping About Users: What's Wrong With Forums?

2008-05-10T09:46:26.167-07:00

Forums or Newsgroups are a great way to expand your community, contribute to the greater development community, hone your communication skills, and stay grounded. However, forums can have a frustrating dark side. From what I can tell, the dark side of forums stem from the wide diversity of users.

On Forums we have:

the normal users
the newbies
the trolls
the users suffering from information fatigue syndrome
in some cases full time employees

As a forum contributor, I like to think that I'm giving something to the community, but some days I feel like I'm wasting my time and here's why.

Frustrating forum threads:

When contributors pass your words off as their own:
Amanda from Microsoft offers this bit of advice on 08-28-2007:

Which seems vaguely similar to something I might have said back on 12-07-2006:

When users are belligerent:

"Adam has so little time he can't even read your question ..." - Brian
When users want a quick fix or want you to do their work:

"please verify and do for me some work." - dagamishiva

It makes it all worth while when users are genuinely grateful for your advice and suggestions. In the end, forums (and helping people in general) is rewarding, and some forums that explicitly cover more advanced topics omit the frustrating chatter and facilitate professional level discussions.

What are your experiences with forums?

Necessary Skepticism: Skepticism is not Pessimism

2008-05-04T08:44:34.549-07:00

In the software realm our opinions are often polarized (perceived in extremes) with no middle ground - you're a pragmatist or an idealist, you're a Windows or *nix person, "you're either with us or against us". This train of thought is referred to as Black-and-White Thinking, or All or Nothing Thinking. This thought process continually manifests itself in the software realm for good reason - we're under pressure to produce, but have limited time, and can't exhaust all permutations or combinations of technological possibilities. So we develop coping skills, and make quick decisions (even if they are wrong). As IT professional we're constantly in The Fight or Flight mentality:

"All or Nothing thinking ... is part of the most primitive of human responses: The Fight or Flight Response. When faced with a life-threatening situation, we must make a snap decision and act on it. There is no time for 'maybe this', or 'maybe that'." -All or Nothing Thinking

Some Polarized Views

Views or labels that seem to be commonly applied to people, organizations, and people:

A Pessimist or an Optimist
A Cynic or an Proponent
A Skeptic or a Dreamer
A Pragmatist or an Idealist
A Tigger or an Eeyore

These labels are generally mutually exclusive - you're usually labeled a Pessimist or an Optimist, but not both. Then there's this general acceptance that Skeptics are Pessimists and these are Curmudgeons, and Eeyores (but everything in moderation). Switching between views is healthy and advisable (be a Skeptic and an Optimist), because inherently "[a]ll programmers are optimists" (1) and too much Enthusiasm, and Optimism often results in Hype, and "Hype is the plague on the house of software" (2).

Why not embrace all these views? Take on the role of a Skeptical Dreamer, then an Optimistic Cynic, or a Pragmatic Idealist. Let's throw off these polarized thinking models and fill in the gray areas. As Fred Brooks once said: "Skepticism is not Pessimism", and critical thinking is also not Skepticism.

(1) Fred Brooks, The Mythical Man-Month (2) Robert Glass, Facts and Fallacies of Software Engineering

Free: Win a Copy of Beginning CSS: Cascading Style Sheets for Web Design

2008-04-24T06:59:39.919-07:00

Beginning CSS: Cascading Style Sheets for Web Design by Richard York is a great book for any web developer looking to thoroughly understand CSS.

This book was required pre-reading for my latest Technical Editing task - I'm editing Mr. York's newest book. So in the spirit of spring, de-cluttering, and giving. I'd like to give this book away. This book is like new with a couple minor dings (from an airport fiasco), it is in full color (like all good design books should be), and it's free!

Contest Rules:

Comment on this post.
Leave a valid email in the email comment field.
The winner will be chosen at random and notified through email on Canada Day (July 1st).
I pay for shipping.

~~Good Luck!~~

The contest has ended and the winner is Devin Parrish!

Turning the Page on Another Virtual Chapter: Time For a Website Revamp

2008-04-23T08:34:00.591-07:00

Life is like a book of infinite chapters with everyone reading at their own pace - we're not who we were yesterday and won't be on the same chapter next week, we're all on the same journey, we progress.

Time for a change. This site and blog was initially directed at hiring managers, it worked great, the human resource teams thought the website was great. It successfully demonstrated creative potential, communication skills, dedication, and so on, but that was 3 years ago. Today my audience has changed (has become more developer centric), but the growing pains of yesterday linger.

So over the next couple months I plan to revamp this site to better represent my current state and anticipated professional direction.

Site update road map:

Transition from a showcase / superficial / professional type site to a more personal / how-to / community based / professional site
Keep it simple
Replace all the ASP.NET AJAX (ATLAS) widgets with hand coded JQuery or Scriptacolous JavaScript components
Drop the Home landing page, replacing it with my Journal / Blog
Drop the Professional Development, Resources menu item
Drop the Professional Development Landing page, redirect to Reviews
On the Contact page:

Remove the lengthy explanation on why I'm using a Captcha

General Site Design

Replace all HTML images with CSS images
Design a new logo
Design a new color scheme
Switch the CSS design from a fixed width layout to a liquid layout

Since my last name is hard to remember I'm considering www.adamdotcom.com as my primary domain name, what do you think?

Any recommendations are welcome!

The ASP.NET AJAX Framework is for DUMMIES!

2008-04-21T14:09:35.354-07:00

The ASP.NET AJAX Framework is an embarrassing server-side centric approach to DHTML / AJAX web development. While most programming languages and frameworks come with both good and bad parts, the ASP.NET AJAX Framework is probably an example of an overall bad part of ASP.NET - on the contrast the ASP.NET MVC Framework looks to be a good part.

What's wrong with the ASP.NET AJAX Framework?

1 .NET Developers are DUMMIES!
The ASP.NET AJAX Framework appears to have been designed under the assumption that .NET developers are dummies and can't learn or don't want to learn JavaScript. That .NET Developers would rather hobble along with their familiar languages, then to learn something new. I understand that the ASP.NET community's only real problem is education, so let's ask: What is wrong with the ASP.NET Community? Then educate ourselves rather than becoming the .NET Developer statuesque. It's patronizing to use a framework that assumes learning a new language is beyond our capabilities. Many of these other programming languages also happen to be more expressive than the statically typed .NET languages.

2. The "don't write a line of JavaScript" abstraction leaks like a sieve
The Framework is intended to shelter .NET Developers from the big bad JavaScript language. Which, like driving a car across North America without knowing how to pump gas, stops you dead. Either you depend on someone to pump your gas - depend on something like the ASP.NET AJAX Control Toolkit and the many authors to write your JavaScript - or you stop moving. As Web Developers, sooner or later learning how to pump your own JavaScript becomes a mandatory skill.

3. Client-side programming from the Server-side is a absurd
The AJAX Framework does back flips to translate server-side code into JavaScript, and then requires that you write JavaScript anyway. Save yourself the pain, learn JavaScript. One day The Law of Leaky Abstractions comes into play, the gas station attendant fills your gas tank with diesel - your AJAX Control Toolkit blows up (requires debugging) so you have to learn JavaScript anyways.

4. Bloated, poor performance, bad user and developer experience
The AJAX Framework extends many of the native JavaScript objects as it attempts to turn JavaScript into a staticly typed programming language, and tries to hook into the ASP.NET life cycle, but all these features are unneeded as they are ALL already achievable through the native JavaScript language - if it walks like a duck and quacks like a duck, then... err... could someone remind me why we need typed languages in a web browser? Anyhow; all these object extensions, enhancements, and upgrades, contribute to more scripts that need to be downloaded and increases the number of scripts running in your browser. Then to make matters worse there's partial-page rendering and Update Panels which do full page post backs under the guise of AJAX -bad-bad! Client-side scripting is supposed to enhance the user experience not make it worse. Other AJAX Frameworks are built with performance as their number one goal, but in the ASP.NET AJAX Framework. Adding more widgets to JavaScript seemed to be the first priority, and performance an after thought.

5. Working against the grain is a waste of time
The AJAX Framework works against the grain, it would be nice if it embraced the JavaScript language. Very few of the concepts and metaphors used in the ASP.NET AJAX Framework transcend AJAX techniques or frameworks - your time is probably better spent learning how JavaScript works or how the other AJAX frameworks work.

6. Disconnected from the ASP.NET MVC Framework
The ASP.NET MVC Framework throws the ASP.NET life cycle away leaving more dead weight ASP.NET AJAX Framework script and rendering many of the AJAX Framework techniques moot.

7. The ASP.NET AJAX Framework almost over looks the 'J' in AJAX - 'J' stands for JavaScript, and that is GOOD
JavaScript is the glue of the web, even the ASP.NET Framework depends heavily on JavaScript, it is not something to shy away from.

8. Aside from local intranet sites, no one really uses the ASP.NET AJAX Framework.
The AJAX Framework isn't widely used. The ASP.NET AJAX site showcases 25 sites using ASP.NET AJAX. None of these applications appear to be high-traffic or moderately high-traffic applications. On the other hand, the YUI site showcases 89 sites, out of these sites, 6 sites (flickr, Slashdot, Linkedin, Paypal, O'Reilly, My Opera) could be considered high-traffic. Other AJAX libraries like jQuery, and Dojo compare similarly. Your time might be better spent learning one of the other AJAX frameworks.

If we (.NET Developers) are going to claim we know AJAX, then let's focus on the core of AJAX (JavaScript) and stop obscuring it in poor frameworks. Frankly the ASP.NET AJAX Framework is embarrassing, the web development community is laughing at the ASP.NET AJAX Framework and the Developers touting it.

Book Reviewed: ASP.NET AJAX in Action by Alessandro Gallo, David Barkol, Rama Vavilala

2008-04-20T15:44:34.467-07:00

The authors of ASP.NET AJAX in Action did an OK (Average) job at presenting the ASP.NET AJAX Framework. However; this book lacked objectivity and suffered from hype. The authors didn't seem to have proficient experience with the JavaScript language, or enough experience with other AJAX Frameworks / Libraries, or sufficient experience using the ASP.NET AJAX Framework in real world projects. This book sadly felt like most technical books - average.

Comments like "we recommend that...", "because it makes no sense...", "you must rely on a special method...", "you must understand X,Y,Z to run complex client-side code without writing a single line of JavaScript" were discouraging. Many of the "whys" were left answered and the technical inner workings of the framework often trivialized. Don't get me wrong, writing a book is incredibly time consuming, but if you're an author, presenter or the like, and you don't fully understand something then admit it. Do some research, provide some links, or move on. Consistently making comments like these bring the integrity of the whole text into question.

The ASP.NET AJAX Framework itself is technically flawed, bloated, and almost entirely impractical. I was disappointed with the server-centric approach that both the book and ASP.NET AJAX Framework takes. I was disappointed that the book continually pushed JavaScript under the carpet as magic and at the end of the book I was pleased to see the promise of making "the JavaScript code disappear"never was fulfilled. JavaScript is the very most important part of AJAX, without the 'J' in AJAX, we're left with nothing - just 'Asynchronous', 'And', heaps of more ugly 'XML'.

When reading this book, take the contents and the ASP.NET AJAX Framework with a grain of salt, if you're really serious about learning AJAX then read JavaScript: The Definitive Guide by David Flanagan.

I typically only contribute positive reviews, but I don't agree with the majority of reviews found on Amazon and hope this review provides some objectivity. I commend the authors on their hard work, I'm probably being too harsh with this review - I know it's tough to write a book, and imagine they made many sacrifices as they worked towards tight deadlines.

View my review on Amazon.

How To Choose a Good Technical Book

2008-04-16T08:19:06.016-07:00

The quality of technical books have wide variations between publishers and authors. While choosing a book based on the author is reliable, depending on a publisher or brand name is not reliable, and choosing a book based on advertisements is even less reliable. It makes sense to choose your books wisely since most technical books live a short life (the duration of a single project), cost money, and require precious time to be read.

When choosing a book I follow this heuristic approach:

Ask experts in the field (friends, forums, newsgroups) for recommendations
Ask these experts to differentiate between the high level books and the books that take a technical deep dive.
Filter out (discard) the high level recommendations.
Filter out (discard) all recommendations that contain the following keywords in their title:

Cookbook
Problem - Design - Solution
Hacks
Tips
Learn X in 24 hours

Look for recognizable authors.
Cross reference these recommendations through Amazon's Reviews:

Books with over 100 excellent ratings on Amazon are instant winners - the Amazon community is rarely misleading.
Books that haven't received more than 50 ratings should be considered with skepticism - visit a local book store and skim through the text in question before making the purchase.

The ASP.NET AJAX Learning Curve

2008-04-09T07:36:06.087-07:00

The ASP.NET AJAX framework comes with a lot of baggage err... I mean... a huge learning curve when compared to other AJAX Frameworks like JQuery, YUI, Dojo, Prototype / Scriptaculous.

Here's a running list of the technologies, and concepts you'll encounter when digging into ASP.NET AJAX:

ASP.NET

The Page Life Cycle
The Control Life Cycle
Web Controls
User Controls
View State
Session State
Events

.NET / Classical Language

Interfaces
Inheritance
Delegates
Multicast Delegates
Assemblies
Properties (Get / Set)
Constructors

In addition to these, you also have the technologies universal to all JavaScript libraries:

JavaScript:

Closures
Object Literals
JSON
Events
DOM Manipulation
Prototypical Inheritance
Constructors
XMLHttpRequest

Cascading Style Sheets (CSS):
Web Services

The ASP.NET AJAX Framework is more complex than other AJAX frameworks, I'm continually lost in it's ambiguity as it attempts to skirt around the JavaScript language - I think this learning curve (and all it's confusion) is precisely why Silverlight has so much potential.

I'm still diving into the low-level details, but my first impressions of the ASP.NET AJAX Framework are:

Obscure, ambiguous, no clear vision - it offers multiple (resource intensive) ways to avoid writing JavaScript, but then requires that you write JavaScript anyways
Too server centric
Too heavy weight (I'm not appreciating how they're trying to turning JavaScript into a Java, C#, .NET clone, the overhead within the browser for these conversions seems like a huge performance bottleneck)
Has the potential for poor performance

Most of the other AJAX libraries have been written with performance, browser responsiveness, and User Experience as their number one priorities - I'm still not sure about ASP.NET AJAX.

How many ways can we try to avoid writing JavaScript? If an AJAX library doesn't enhance the User Experience then why use it? Regardless, I'm still digging deeper.

A Reflection on Themes, Skins, and Cascading Style Sheets (CSS) in ASP.NET 2.0 (A Final Conclusion)

2008-04-07T16:19:54.272-07:00

A couple years ago I was thrown into a web application that made heavy use of ASP.NET Themes and Skins. Prior to this I depended exclusively on Cascading Style Sheet (CSS) for my web development / web design needs. A first glance at ASP.NET Themes and Skins looked promising, but a number of flaws surfaced - see the links and issues listed at the end of this post.

In addition to these issues, here are a couple other considerations when thinking about ASP.NET Themes:

Themes do not adequately separate the levels of concerns within your application. When using Themes all design related files are baked into the application. From a maintainability standpoint, this doesn't bode well in large web applications. Hosting design related files on a single server or an external Content Delivery Network (CDN) is an effective way for managing site wide UI updates and increasing a sites performance, ASP.NET Themes works against this technique.
Themes add unneeded complexity by obscuring the real technologies at work (CSS). Everything that ASP.NET Themes offer can be better achieved outside of the ASP.NET Theme Framework. Technologies like Cascading Style Sheets (CSS), alternate Style Sheets, and JavaScript can achieve more than Themes can provide.
Themes are a server-side mechanism. Themes become a nuisance in client-side dependent, heavily dynamic, Web 2.0, DHTML, AJAX type web applications.
Themes discourage developers from learning more about web design and the technologies surrounding it. Themes offer a seemingly simple API, which shelters developers from the complexities of CSS and JavaScript, but sooner or later The Law of Leaky Abstractions comes into play and knowing the fundamentals of these technologies is a necessity.
Professional web designers don't use ASP.NET Themes, CSS is the language of web designers.

Default Skins on the other hand can be useful for defining consistent CSS hooks into common ASP.NET controls. It's unfortunate that we can't use Skins without Themes.

Related posts:

Founders aren't Employees, but neither are Consultants

2008-04-01T16:39:30.876-07:00

In You Weren't Meant to Have a Boss, Paul Graham makes some clear distinctions between Founders and Employees. A similar Founder Vs Employee thread was presented in Joel Spolsky's recent article How Hard Could It Be?: Lessons I Learned in the Army. Spolsky goes on to make the point that Employees do not have the same ambitions as Founders, and that Founders need to realize this dichotomy - that Employees are interested in today (short term) whereas Founders are focused on the long term.

The great employees will be devoted, sure, and it's completely reasonable to expect them to work their butts off. But unlike founders, employees are concerned about what their jobs are like today. They're not as excited about making sacrifices for the long run.

I can always tell the founders who haven't figured this out yet, because they're disappointed in all their employees, firing good people left and right and constantly asking, "Why hasn't Joe (or Jane) gotten this work done yet? I could have finished it in one weekend!" - Joel Spolsky: How Hard Could It Be?: Lessons I Learned in the Army

Both these articles highlight the differences between Employees and Founders, but what about Consultants?

Consultants can often fall under the full-time Employee umbrella, but probably have an even shorter term interest in their client. Part of a consultant's job is to maintain objectivity, to distance themselves from becoming financially, emotionally, and personally invested in their client - objectivity is lost when an attachment or investment is made.

According to Janet Ruhl a couple of the biggest Gotchas in consultancy work can be:

Investing in your client - purchasing shares in your client or agreeing to software royalties rather than a pay cheque.
Being manipulated into working for free.

Consultants are kind of like Employees, but different. Consultants probably have an even shorter term interest in the company they work for then Employees do. I think it's important to highlight these differences.

Book Reviewed: JavaScript: The Definitive Guide by David Flanagan

2008-03-26T07:49:27.404-07:00

JavaScript: The Definitive Guide by David Flanagan is a great book! When I began reading this book I was convinced that (like many technical books) the first couple chapters would contain the important stuff and the content would slowly digress into page filler, fluff, and the book would become just another monitor stand. But not this book! After finishing the formal chapters I started reading the references - YES, this book is so good I'm reading the references! Flanagan has raised the bar for all JavaScript books - this book is in its 5th edition, and reviewed by some of the greats in the Web Development / JavaScript world (Douglas Crockford, Peter-Paul Koch).

I often think of JavaScript as the assembly language of the internet - most of the current-generation web frameworks make heavy use of JavaScript, CSS, and AJAX. If you really want to understand how ASP.NET or Ruby on Rails really works, how AJAX works, how JavaScript libraries work. If you want to really understand how to push the web browser envelope, and how to really innovate, then this book is a required read. JavaScript (and other functional programming languages) present a different programming model. Once you grock the fundamentals of JavaScript you'll never be able to look at classical languages (Java, C++, C#, ...) with a straight face again. I highly recommend this book to ANY web developer from ANY web framework camp.

This book is now in my Recommended Reading section. View my review on Amazon.

A Completely Normal Post: Our Dog

2008-03-20T10:34:30.797-07:00

My blog posts tend to be obscured in programming languages, and techie gibberish, I thought I'd do a normal post on our dog - after all, pets are what blogs are really about, right? :)

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.

	Then	Now
Processors	Two 32bit AMD MP 1.2GHz	Quad Core 64bit 2.4GHz
RAM	3.5 GB	8 GB
Monitor(s)	A single 17"	Two 22" Samsung SyncMaster 226BWs
Personal Pain Points	Excruciatingly painful	Occasionally painful (only Vista induced)