Adam.Kahtava.com / AdamDotCom

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

Adam Kahtava — Sun, 13 Jul 2008 18:14:03 GMT

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?

Adam Kahtava — Tue, 01 Jul 2008 18:04:05 GMT

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

Adam Kahtava — Mon, 23 Jun 2008 17:17:08 GMT

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

Adam Kahtava — Wed, 18 Jun 2008 22:11:46 GMT

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

Adam Kahtava — Sun, 15 Jun 2008 19:50:02 GMT

#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

Adam Kahtava — Fri, 13 Jun 2008 23:45:53 GMT

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

Adam Kahtava — Sat, 07 Jun 2008 23:32:33 GMT

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

Adam Kahtava — Sat, 07 Jun 2008 19:19:42 GMT

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

Adam Kahtava — Tue, 03 Jun 2008 15:06:27 GMT

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

Adam Kahtava — Sat, 31 May 2008 21:56:37 GMT

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

Adam Kahtava — Sat, 24 May 2008 21:03:23 GMT

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: <a onclick="return false;" ..., or <a 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

Adam Kahtava — Thu, 15 May 2008 22:35:19 GMT

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 the YUI 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 the jQuery 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.

	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)