#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?

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?

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.

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:

1. My JavaScript knowledge was embarrassing
2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome - as a monocultured .NET developer I had sorely been missing out
3. 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
   
4. 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
   
5. 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.

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.

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.

Steve Yegge discusses junior-style programming in his post: Portrait of a n00b. After reading Steve' post I decided to dig up some of my own n00b code - this code is from the summer of '99.

I got my first real C++ book
Bought it at the local book store
read it 'til my eyes turned red
it was the summer of '99

I found this code amusing... To keep things short, I included one method, but the entire class implementation is similar - my comments describe almost every facet of what I now regard as relatively simple logic and I've completely removed all whitespace.

As Steve puts it:

[I was] making up a temporal narrative in an attempt to carve out a mental picture of the computation for myself. These stories I told myself were a critical part of my mental development as a programmer. I was a child trying to make sense of a big, scary new world. - Steve Yegge: Portrait of a n00b

The code:

//***************************_Command.cpp_*********************************

//__Creator:_____________Adam Kahtava

//__Date:________________June 14, 1999
//*************************************************************************

//-----Implements the init method defined in the command.h header file
//-----Keywords and Modifiers are initialized into keyword[], and modifier[1-5].
//-----(Keywords and modifiers are all separated by semi-colons).
void command::init(char data[]){
  int j=0;
     int len=strlen(data);
        for(int i=0;i<6;i++){ 
    //this for loop is run 6 times, 1st for the keyword,
                             // and 5 times for the modifiers, and increments i.
           int k=0;
           char temp[20]={""}; //sets temp to "" (the default)
           //goes through "data" copying string into "temp", 
           // until delimiter ";", '\0' is encountered or until len >= j
        
    while((data[j]!=';'&&data[j]!='\0')&&len>=j){
                 temp[k]=data[j]; //copies useful data from "data" to "temp"
            
      i++; //increments i
            
      k++; //increments k
        
    }
        
    if(i==0){ //is initiated on first "for loop".
            
      strcpy(keyword,temp); //copies temp to keyword/
        
    }
        
    else if(i>0){ //else if "for loop" has been run more than once.
            
      strcpy(modifier[i-1],temp); //copies temp to modifier[1-5].
        
    }
        
    j++; //increments j
    
  }   

}    

Notable difference from then and now:

Back in '99 I thought everything I wrote was awesome, I thought I was a Code Poet, or a Programming Ninja (with Real Ultimate Power). I thought my descriptive comments were awesome, and probably thought that by removing all whitespace I would be increasing the program's efficiency. I thought I could learn more by just programming than reading about programming - I recall discarding books and often hacking my way to comprehension. I was clearly disillusioned.

Today I agree with Jeff Atwood that everything I write sucks, I have an obsession with white space, and prefer to thoroughly understand a programming language before verbalizing my proficiency in it. Now I occasionally get complaints that I'm not including enough comments, and I'm still improving and learning. :)

Loosely typed / weakly languages are amazing! But... for myself, coming to this conclusion was like an acquired taste.

Many people appreciate loosely typed languages for the how expressive, elegant, simple, and Zen like they are - and I agree, but I haven't always thought this way. You see; strictly typed (statically typed) programming languages have always been the mainstay of my programming vocabulary, C++, Java, and C# were the meat and potatoes of my programming language diet. I used these languages (strictly typed) because they were familiar, I understood how their compilers, IDEs, and comfortable class-based inheritance model worked. If someone asked me whether I liked C# (insert strict typed language) or JavaScript (insert weakly typed language) I would immediately have given preference to the strictly typed language. Why? Because that's where I felt safe, and that's what I understood - besides who wants to admit they prefer the "weak" language? My preference wasn't based on knowledge or experience it was based on my familiarity with the strictly typed culture.

I was suffering from Software Ethnocentrism.

Software Ethnocentrism often entails the belief that one's programming language or development environment is the most important and/or ... are superior to those of other software developers. Within this ideology, software developers will judge other groups in relation to their own particular development environment or culture, especially with concern to programming language, methodologies, behaviour, customs, and religion.
 - the derived definition (above) is based on Wikipedia's article on Ethnocentrism.

I had the tell tale signs of Software Ethnocentrism:

• I thought strictly typed language were "the bomb"  - the only viable solution :)
  
• I thought Test Driven Development (TDD) and Unit Testing was the panacea
• I was completely obsessed with refactoring tools like ReSharper and Refactoring
• I thought my Compiler and IDE were superior
• and I had complete faith in multipurpose strictly typed languages like C#

Then things changed. I started diving deep into the hearts of weakly typed languages: JavaScript, Ruby, and LISP. Now today, I wonder If the time I spent hung up on strictly typed languages, TDD, and unit testing could have been better spent by expanding my programming vocabulary. If I had only delved deep into the heart of weakly typed languages (like JavaScript, 3 years ago) and grocked the fundamentals of these other languages, then I could have achieved this richer understanding of programming languages that I have today. It's important to note, that i'm not stating that weakly typed languages are better than strictly typed languages or vise versa, only that both have their place, are equally useful, and should be used when appropriate.

Do you too suffer from Software Ethnocentrism? Try staving off this programming language tunnel vision, learn a new type of programming language. It might be a better investment in your time than becoming obsessed over a microcosm (like say unit testing and TDD).

Steve Yegge makes some humorous jabs at the static type culture:

... I think we can conclude that people who rely too much on static types, people who really love the static modeling process, are n00bs. ... Hee hee.
 - Steve Yegge: Portrait of a N00b

... I think there's some mystical relationship between the personality traits of "wakes up before dawn", "likes static typing but not type inference", "is organized to the point of being anal", "likes team meetings", and "likes Bad Agile". I'm not quite sure what it is, but I see it a lot.
- Steve Yegge: Good Agile, Bad Agile

... you have your slob type systems and your neat-freak type systems, and it comes down to personal preference. The neat freaks (Java, C#, C++, Pascal) know damn well that the slobs (Perl, Python, Ruby, JavaScript) are just as productive. Maybe even more so.
- Steve Yegge: Egomania Itself

Cartoon Notes: I took this cartoon from Steve Yegge's blog titled Egomania Itself. It represents the irony of static type languages where everything is a named type - presumably the owner of the property is naming all his objects so he can remember what they are, but in loosely type languages, If it walks like a dog and barks like a dog, I would call it a dog. Read more about Dog Typing er... Duck Typing.