Adam.Kahtava.com / AdamDotCom

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. I needed a new computer.

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:

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?

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, each developers got dual LCD monitors, state of the art machines, fooze ball, and to top it all off, they had a cafeteria with 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 didn’t seem right.

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 “Not really”. 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). 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 gamer doesn’t say anything about your performance 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 (why do you care 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:
You know when your employees should be at work.

Draw backs:
Going to work could feel like boot camp or 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 because 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.

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

#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 old were you when you started programming?

Somewhere around the age of 8 or earlier, computers were always just there – they’d been in my life since I can begin to remember.

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. His robotics program involved lots of programming and together we worked through a couple BASIC programming books. I continued to mess around with BASIC and wrote scripts so I could get at my favourite games. Later I was frequenting BBSs (The Fisherman’s Scroll), and surfing the internet through lynx (a text based browser). I eventually became a Script kiddie – being a Script kiddie was what really turned me on to programming. My friends and I would write IRC war scripts, play MUDs, and try to figure out how Trumpet Winsock, networks, 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 – the fragments of the C language these programmers exposed to me were magical, and sparked an genuine interest in computer programming. In addition to all this my dad kept a constant supply of old and new computer parts funneling into our house, my brothers and I would build computers from the parts – today my closest brother is a Linux fanatic, evidently all this sparked his interest too.

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 from my BASIC books, but my first real program would have been Pacman programmed in Turing – in my final year of high school I enrolled in a computer course, where the instructor let us write any program we wanted for half a school year I chose to write a game.

What languages have you used since you started programming?

I’ve spent most my time in C, C++, C#, JavaScript, SQL, and the mark-up languages. I primarily program for the web or at least for the network, but have used many other languages like COBOL and so on…

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?

I would have been 18. It was my first year of College, I needed a part-time job in order to pay rent, I initially worked on an assembly line, but would occasionally help the office workers troubleshoot their IT issues. I soon found myself working as the company’s 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. Previous to this, I had freelanced a couple websites for local businesses while in high school.

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. :)

This post was in response to Michael Eaton’s initial post on: How did you get started in software development?

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

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.

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?

• 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
• It feels like a framework that was written for dummies (Don’t Write Frameworks For Dummies)

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 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.

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 podcast here: Technology Round Table Podcast #2 – AJAX Frameworks