Archive for January, 2008

On Teams: Thoughts, and Quotes related to Team Work

January 31st, 2008

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

Author: Adam Kahtava Categories: Musings, Software, Team Work Tags:

How Well Do You Know JavaScript?

January 13th, 2008

JavaScript is probably the world’s most popular and misunderstood programming languages and for good reason.
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, protected assessors, no classes, no enums, no structs – you understand that all these language features can be achieved through objects and function closures.
  • JavaScript is classless, but instead it uses objects as general containers.
  • JavaScript makes use of garbage collection.
  • JavaScript uses truthy and falsy values – you understand which values are truth and falsy.
  • JavaScript makes use of the ‘nan’ (not a number) and ‘undefined’ values – you understand the difference between these values.
  • JavaScript has pretty good debuggers – you understand how to debug JavaScript from both IE (link) and Firefox (link).
  • You appreciate recursion, and understand that recursion is a useful technique in JavaScript.
  • You understand that JavaScript Namespaces should be used – you understand the importance of namespaces, and know how to create one (Namespacing Your JavaScript).
  • You know how to avoid the JavaScript pseudo-protocol (<a href=”Javascript:alert(‘hello’);”), and appreciate avoiding it.
  • You know how to avoid embedding DOM Level 0 JavaScript events (<a onclick=”alert(‘hello’);”) in your mark-up / document structure, and appreciate this technique.
  • You know that JavaScript can make use of two different event models (event capturing and bubbling), but we should only ever make use of bubbling.
  • You understand what JSON is and how it’s used.
  • You know how to keep you JavaScript, CSS, document structure separate, and appreciate non obtrusive JavaScript.

If any of these points seem foreign, then it may be time to learn JavaScript. With all the hype and buzz around Web 2.0 and AJAX it could be a great way to augment your career while broadening your programming language vocabulary.

Great resources for learning more about JavaScript:




Author: Adam Kahtava Categories: .NET, AJAX, ASP.NET, CSS, DOM, Firefox, IE, JavaScript, Software, Videos Tags: