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?

#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 back 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 wrote a Pacman game 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 Pacman program.

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.

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

Absolutely! It's been two decades since my first "hello world!" program and 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?

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

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.

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

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.

Namespacing your JavaScript is critical for sites that make heavy use of JavaScript, or sites that use any the JavaScript AJAX libraries (Scriptaculous, ASP.NET AJAX Client Side, YUI, JQuery, ...). It's also a great defensive programming technique - this is another post on JavaScript techniques that I've found useful.

Why Namespaces? Well... :) When a browser loads a document, it loads ALL the JavaScript into the browser. Objects that are not enclosed within a Namespace are Global, and Global Variables are Evil because they run the risk of interfering / overriding / clobbering previously defined objects (variables, functions, etc...). The JavaScript language, in its current form does not have native support for Namespacing . So, as pragmatic developers we realize the need to "Program Into [Our] Language, Not In It" - Steve McConnell, Code Complete 2nd Ed, Chapter 34.4. In the JavaScript language we use Objects to achieve Namespacing - we'll cover this closer to the end of this post.

Don’t limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives ... - Steve McConnell: Code Complete 2nd Ed, Chapter 34.4

An example of when Namespaces could be used: Let's say, we're working on a team of 3 developers, each developer is working on a different widget / component for the same page. So inside our HTML / XHTML document we define and load three different JavaScript files and inside these files we have something like:

In someObscureWidgetJavaScriptFile1.js have:

  helloWorld = function(){ alert('hello world'); };

In someOtherObscureJavaScriptFile2.js we have:

  helloWorld = 'hello world';

In someOtherObscureJavaScriptFile3.js we have:

  helloWorld = { hello: 'hello', world: 'world' };

All these JavaScript files get loaded into the browsers global calling object (window), and each assignment of helloWorld interferes with the previous. When we attempt to reference helloWorld we'll be depending on the order in which the JavaScript files were loaded - if the first file was loaded we'll be able to display the alert, if the later file was loaded first we'll be able to reference a string, and so on.

Back to the topic at hand, How do I create a Namespace in JavaScript.
Note: this approach to Namespacing was recommended and referenced in JavaScript: The Definitive Guide by David Flanagan, other methods of Namespacing can be found on the web (Namespacing your JavaScript by Dustin Diaze outlines an alternate approach). For me, the following seems more intuitive, and is recommended in Flanagan's book - probably, the best JavaScript book written to date.

Ceating a Namespace in JavaScript:

// Create the namespace object.  Error checking omitted here for brevity.

var myNameSpace;
if (!myNameSpace) myNameSpace = {};
myNameSpace.myPseudoClass = {}; 
//JavaScript doesn't support classes, 
// so let's avoid confusing people and call this a Pseudo Class



// Don't stick anything into the namespace directly.

// Instead we define and invoke an anonymous function to create a closure

// that serves as our private namespace. This function will export its

// public symbols from the closure into the myNameSpace object

// Note that we use an unnamed function so we don't create any other

// global symbols.

(function() {  // Begin anonymous function definition

    

  // Nested functions create symbols within the closure
    
  function displayMyMessage() { alert(myMessage); }

      // Local variable are symbols within the closure.
    
  // This one will remain private within the closure
    
  var myMessage = 'Hello World';
 
      // This function can refer to the variable with a simple name
    
  // instead of having to qualify it with a namespace
    
  function getMyMessage() { return myMessage; }

      // Now that we've defined the properties we want in our private
    
  // closure, we can export the public ones to the public namespace
    
  // and leave the private ones hidden here.
    
  var ns = myNameSpace.myPseudoClass;
      ns.displayMyMessage = displayMyMessage;
      ns.getMyMessage = getMyMessage;

})(); // End anonymous function definition and invoke it

Then outside our namespace we can invoke our methods like this: myNameSpace.myPseudoClass.displayMyMessage();

Read Chapter 10, Modules and Namespaces in JavaScript: The Definitive Guide for a deeper dive into Namespaces and Modules in JavaScript!

If you're still not convinced you need Namespaces and are interested in reading more about the issues surounding Global Data, then you may be interested in reading Chapter 13.3 (Global Data) in Code Complete.

A quick search on the internet for "Inter Browser Window Communication Using JavaScript" reveals many outdated search results recommending questionable techniques. In the past I've fallen prey to many of these ill-advised suggestions. So... I thought, I'd start a small series on JavaScript techniques that I've found useful.

This post covers Inter / Cross Browser Window Communications using JavaScript.

A common scenario in web applications is: to have Page A open Page B , then have Page A communicate with Page B or vise versa.

One of the techniques floating around the internet suggests that you use Cookies and a JavaScript setTimeout function that listens for the presence of a cookie. So essentially Page A sets a cookie and Page B listens for this cookie and acts on it.

A alternate solution might be to use the JavaScript Browser window.open and window.opener methods. Using these two methods we can achieve inter / cross browser window communication as long as the Same Origin Policy is withheld - a similar approach can be taken for frame and iframe communication.

An example:

// myNewWindow stores the reference to the newly
//   created window, this provides a handle for defining
//     and calling methods in the New Window
var myNewWindow = window.open('about:blank');

// Lets call the alert method in our New Window
//    from this window (the Original Window)
myNewWindow.alert('Hello From Original Window');

// Lets call an alert method in our Original Window
//    from our New Window. So.. Lets use a timer
myNewWindow.setTimeout(
  'window.opener.alert(\'Hello From The New Window\')', 100);

Click here to run this code live in your browser window using a Bookmarklet, or copy the above code into your Firebug Command Line Console.

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.

Team work and interpersonal skills are absolutely essential for the present day knowledge worker (software developers, and the like). If you don't like working in teams, don't know how to work in a team, then you may not be able to find work.

In the larger software community, most agree that:

programming is a social activity, ... being the lone wolf ... is not what we do anymore  - Douglas Crockford  

And most of us have come to understand that:

Team dynamics; how well a team works together has a bigger impact on a project than the developer’s individual capabilities. And that: No individual is a success who hurts the team, and no individual is a failure who helps it.- Software Project Survival Guide

So, it should come as no surprise when a company (like Microsoft) that depends almost entirely on team work lists Team working and interpersonal skills as the VERY most important business skill. - Computer knowledge 'undervalued'

However; it's often hard for the those in management to understand that you can't force people into a team environment - let alone change or mold them. So, if someone doesn't like working on teams, has never worked on a team, or doesn't agree with your existing team's cultural views, then you should ask why. Because:

the people that work for you through whatever period will be more or less the same at the end as they were at the beginning.  If they're not right for the job from the start, they never will be. - Peopleware: Productive Projects and Teams

In reality, we have very little influence on our team members, poorly matched cultural values will likely result in poorly functioning teams, which in turn negatively results the projects success. Joel Spolsky takes this train of thought a little further and suggests that:

it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort - The Guerrilla Guide to Interviewing (version 3.0)

However; most organizations don't have the exposure that Spolsky does, and can hardly find candidates period - let alone the very best candidates. Often in the real world, the only chance you'll have to guide (influence) any team of developers (or anyone), is to lead by example. Jeff Atwood offers some great advice: 

Cajoling and berating your coworkers into compliance isn't an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn't to brainwash everyone you work with, but to negotiate ...

So much of leadership is learning to give a damn about other people, something that us programmers are notoriously bad at. We may love our machines and our code, but our teammates prove much more complicated. - Leading by Example

Team work and interpersonal skills are more important than technical skills. The ability to work in a team is absolutely mandatory for today's software developer.

JavaScript is probably the world's most popular and misunderstood programming languages and for good reason - most developers will claim they know JavaScript even when they don't - I know I have!

When a developer claims to know JavaScript this generally equates to one or all of the following:

• "I know what JavaScript is, I can learn JavaScript in 30 minutes"
• "JavaScript is for kids, it's a toy language, it's easy"
• "I just copy and paste my JavaScript snippets / scripts from the internet"
• "JavaScript is just another programming language like C++, C#, VB.NET, or Java"

If thoughts similar to these have crossed your mind when sizing up your JavaScript knowledge, then you probably don't know JavaScript.

I would argue that if you've never programmed in a functional programming language (like: Lisp, Scheme, F#), never read a GOOD book on JavaScript, or never watched a video on JavaScript, then you probably don't understand JavaScript at all. JavaScript is starkly different than any other mainstream programming language.

When it comes to JavaScript, if you don't understand the fundamentals then you're only punishing yourself.

Here are some things every JavaScript developer should probably understand:

• JavaScript, Mocha, LiveScript, JScript, and ECMAScript are all essentially the same.
• JavaScript is a prototypically inherited (prototype-based programming) language which is very different than the classically inherited (class-based programming) languages like C++, Java, and most of the .NET languages - you know the difference between a prototype-based programming and class-based programming language.
• JavaScript is a loosely typed language - you know the difference between strongly-typed programming languages and weak-typed or loosely typed languages.
• JavaScript is a functional lambda language - you understand lambdas and that functions in JavaScript can be lambdas.
• JavaScript functions can be defined inside functions, inside functions, inside functions, and so on - you can demonstrate this.
• JavaScript uses function scope, has no curly brace '{}' block scope - you understand that this is common attribute of most functional programming languages.
• JavaScript has no private, public,