Tag Archives: Leadership

Learn Javascript – the Language Itself

One of the worst pieces of advice that I have ever received was from an architect / team leader which I used to work with. He told me,
“Don’t waste your time learning Javascript. Just learn one of the modern libraries like jQuery.”

As you can probably figure out, this guy was a bad advice machine, with terrible judgment to boot.

In a Douglas Crockford video I once watched, he lamented that one of the big problems which plagued Javascript was that developers started writing it without actually learning it first. As I trust the great Douglas Crockford over the aforementioned incompetent architect, I decided to learn Javascript.

The reason I bring this up is because the other day I was reading the jQuery API documentation about the map() function (refreshing my memory – it had been a while). In the examples section, the following code was set out:

<script type="text/javascript">// <![CDATA[
$.fn.equalizeHeights = function() {
  var maxHeight = this.map(function(i,e) {
    return $(e).height();

  return this.height( Math.max.apply(this, maxHeight) );

// ]]></script>

If I was not fluent in javascript, I would not have understood the following fragment of code:

Math.max.apply(this, maxHeight)

The apply method is quite particular to javascript. Sure, I could have Googled that code and just chucked it in my project to get it working. But I wouldn’t have a clue why it works. And many developers I know aren’t even aware of the apply method, let alone what it does. Don’t be surprised by that. Really!

As it turned out, the architect I mentioned above did not understand Javascript or AJAX at all. This became apparent in various team discussions, and made for some great giggling amongst the junior developers.

So listen to Crockford. Learn Javascript! With the HTML 5 stuff and the advent of client-side, data-binding frameworks, developers will be writing more Javascript than they ever have before.

Being a Responsible Mentor

If you are going to jump on someone, at least make it a worthwhile endeavor.

At least do it when the person will actually learn from it. Don’t do it just because you are in a dire mood.

I used to work under a couple of people who were “past masters” at shooting down developers for no constructive reason. An example follows.

One day, when we were doing a proof of concept, I instantiated an object in a constructor to save the time of hooking up an IOC container. I then got jumped on by the team-lead when I explained that, “I used poor man’s dependency injection”. I can’t even remember the tirade, because there was nothing to be learnt from it. It was more of an exercise in solipsistic, self-indulgent ranting than anything. Somebody’s ego gave themselves the green light to knock me with their big swinging intellect.

I am reminded of this, because I just read this article by the great Dino Esposito. Let me just quote a paragraph from that article:

Because the controller class clearly has a dependency on the orchestrator, you might want to design the controller class to support dependency injection. Therefore, as a first step you abstract the orchestrator to an interface. The code above uses the poor man’s dependency injection schema (an overloaded constructor); feel free to rewrite that code to use your favorite IoC framework.

I wonder what Dino would have said if he had been on the pointy end of the ridiculous rant which I was exposed to.

People judge you at work. For good or bad. So if you are going to start swinging your ego around with no real benefit to the project, the team or the junior developer in question, prepare to be judged and remembered. Remembered as that person who didn’t really know that much, but who always had to service their insecurity with useless rants of no worth.