This is not a technical post, but something that I’ve been pondering about for a while and it is related to a lot of comments and emails I get through here. I wanted to sum up some points what it is like to work for a large, very public corporation and what my points of view and my circle of influence are.
Lately I’ve been getting a lot of questions about this and instead of repeating myself over and over again, I take this as an opportunity to write a reference piece.

There comes a time in the career of a developer where you go up the hierarchy in your company. Most of the time this is because of your performance and dedication to the company but also to the wider market that you work in and due to the fact that you have proven to yourself that you are a good developer and team player.

Web Development is a very young profession and we do make all the mistakes that have been done in other professions before. One thing is for sure though: you need to keep your eyes open and roll with the changes of the market in order to succeed. If you take your job and the fact that the web is a new media really serious this means that you need to check out future technologies and ideas as much as delivering the current ones to full satisfaction.

If you’ve done this for several years and feel your forehead getting numb from running against walls trying to get this idea through to people whose main concern is to make enough money to be able to pay the wages and other company expenses you got two choices: start an own company, consult others or try to join one of the big players in the market.

The former two come with financial unknowns and a lot of stress. The second also comes with the decision to let go of some of your dedication as you cannot over-deliver. You consult, you invoice, you hope they get better and you leave for the next job. You know what to do right, but you hardly ever get the chance to really deliver it.

The latter – working for a future-facing, established corporation that is not in trouble – comes with a lot of positives:

• You work for a company that has been around a while and knows how to treat employees so that they can deliver (this means HR issues are taken care of and the pay is no problem either)
• You work for a company that already has a lot of developers working for it and doesn’t have to start understanding the value of good IT support. This includes getting adequate hardware, the right software and upgrades whenever they are necessary rather than when they fit the budget.
• You get reach beyond your wildest dreams – millions of users – and learn about tricks of the trade you never thought necessary but that are when you want to deliver a great experience for all these people.
• You get the chance to work with amazingly skilled people – those whose books you read and wondered how the hell they come up with great ideas like that.
• You get to propose people you always wanted to work with to get hired – and find that there is a budget for that!
• You find that there are departments in the company that research technologies and ideas that aren’t an immediate success but will be a great asset in the future. You even get kudos and maybe even more for proposing them some ideas.
• You can learn from the massive experience of people that have been playing in this league for a long time.
• You get company perks (free food, cheaper hardware, gym, health care and so on…)

All of this will make you happy but there is a flipside, too.

• You are a geek, possibly even with a “scene” background and you “sell out to the man” in the eyes of a lot of people that saw you as an equal before.
• People expect you to change drastically and you have to suffer many “tongue-in-cheek” comments about you “being assimilated”, “joining the mothership” and other “clever” remarks.
• Whenever you talk about a product of your company, people will take it less serious than when you said the same prior joining the company. “Of course you say this is good, they pay you for it”.
• You will be responsible for everything your company does, no matter how far removed from your area of expertise or even location it happens.
• You will be judged not by the good stuff that happens but by the lower quality things the company produces – it is fun to poke the giant and show that you can do things better (whilst forgetting the dependencies the giant has to support that you don’t have to)
• Naturally you will be considered to have insight into all the happenings in the company and probably can tell in detail whatever people might want to know.
• It is expected that if somebody wants you to work for them (for example as a speaker at a conference) your company will gladly pay for your travel there and the accommodation and not the organization that wants you to work for them.
• You are expected to be as rich as the richest director in the company, as all the goods are shared equally, right?
• You will know what stocks to invest in as your company is big in Wall Street
• You can get anyone a job in your company, even if they haven’t the faintest clue what they really want to do or what they can bring to the table.

Each of these is no biggie and you can shrug them off, but it is amazing how many of these happen day in and day out.

So here is what I do and know about my company and its future:

• I work as a web architect, giving advice on frontend web development matters to the people who build the internal tools that we build our web sites with.
• I am part of a team whose job it is to define the standards frontend web matters are delivered to.
• I am working on internal tools to make it easier to re-use code and components across different products.
• I propose people to hire and interview others for positions in web development
• I am an external European arm of our development library and can offer information and talks about that
• I am a speaker that can talk about all the public facing APIs, libraries and components we offer for outside developers
• I am an internal trainer on all matters web development and human interaction (accessibility, writing for the web…)
• I am reviewing internal code and products of Europe, Asia and sometimes the US
• I talk a lot to teams in the US to make sure our standards tie in with their ideas and will become global standards
• I talk to universities about hack days, challenges and other academic happenings.
• I keep an eye on the team in Europe and around the globe to make sure that developers are happy and can do a good job – removing obstacles for them and talking people out of ideas that would mean a lot of work for the web developers without much gain.
• I liaise with other people in the same positions and HR and PR to make sure we have some processes in place that will ensure that we can hire good people in the future and give potential new developers an insight into what it means to be a developer for a large site like ours.
• I speak to the backend teams to ensure we work together smoothly and have methodologies that work hand-in-hand.

This is a lot, and it keeps me busy with the things I care about the most – cool technology that benefits web surfers and empowering people who want to build this technology.

In short, I talk a lot to developers, their managers and outside people about our technologies to make sure that we can deliver good products and have fun experimenting with new ideas.

And that is all that I know about in my company. Anything else, I’d venture to guess that you know more than I do!

Let’s face fact folks: not too many developers plan their JavaScripts. Instead we quickly write something that works, and submit it. We come up with variable and function names as we go along and in the end know that we’ll never have to see this little bit of script ever again.

The problems start when we do see our script again, or we get scripts from other developers, that were built the same way. That’s why it is good to keep a few extra steps in mind when it comes to saying “this is done, I can go on”.

Let’s say the job was to add small link to every DIV in a document with the class collapsible that would show and hide the DIV. The first thing to do would be to use a library to get around the issues of cross-browser event handling. Let’s not concentrate on that for the moment but go for oldschool onevent handlers as we’re talking about different things here. Using a module pattern we can create functionality like that with a few lines of code:

collapser = function(){
  var secs = document.getElementsByTagName('div');
  for(var i=0;i<secs.length;i++){
    if(secs[i].className.indexOf('collapsible')!==-1){
      var p = document.createElement('p');
      var a = document.createElement('a');
      a.setAttribute('href','#');
      a.onclick = function(){
        var sec = this.parentNode.nextSibling;
        if(sec.style.display === 'none'){
          sec.style.display = 'block';
          this.firstChild.nodeValue = 'collapse'
        } else {
          sec.style.display = 'none';
          this.firstChild.nodeValue = 'expand'
        }
        return false;
      };
      a.appendChild(document.createTextNode('expand'));
      p.appendChild(a);
      secs[i].style.display = 'none';
      secs[i].parentNode.insertBefore(p,secs[i]);
    }
  }
}();

This is already rather clean (I am sure you’ve seen innerHTML solutions with javascript: links) and unobtrusive, but there are some things that should not be there.

Step 1: Remove look and feel

The first thing to do is not to manipulate the style collection in JavaScript but leave the look and feel to where it belongs: the CSS. This allows for ease of skinning and changing the way of hiding the sections without having to mess around in the JavaScript. We can do this by assigning a CSS class and removing it:

collapser = function(){
  var secs = document.getElementsByTagName('div');
  for(var i=0;i<secs.length;i++){
    if(secs[i].className.indexOf('collapsible')!==-1){
      secs[i].className += ' ' + 'collapsed';
      var p = document.createElement('p');
      var a = document.createElement('a');
      a.setAttribute('href','#');
      a.onclick = function(){
        var sec = this.parentNode.nextSibling;
        if(sec.className.indexOf('collapsed')!==-1){
          sec.className = sec.className.replace(' collapsed','');
          this.firstChild.nodeValue = 'collapse'
        } else {
          sec.className += ' ' + 'collapsed';
          this.firstChild.nodeValue = 'expand'
        }
        return false;
      }
      a.appendChild(document.createTextNode('expand'));
      p.appendChild(a);
      secs[i].parentNode.insertBefore(p,secs[i]);
    }
  }
}();

Step 2: Remove obvious speed issues

There are not many issues in this script, but two things are obvious: the for loop reads out the length attribute of the secs collection on every iteration and we create the same anonymous function for each link to show and hide the section. Caching the length in another variable and creating a named function that gets re-used makes more sense:

collapser = function(){
  var secs = document.getElementsByTagName('div');
  for(var i=0,j=secs.length;i<j;i++){
    if(secs[i].className.indexOf('collapsible')!==-1){
      secs[i].className += ' ' + 'collapsed';
      var p = document.createElement('p');
      var a = document.createElement('a');
      a.setAttribute('href','#');
      a.onclick = toggle;
      a.appendChild(document.createTextNode('expand'));
      p.appendChild(a);
      secs[i].parentNode.insertBefore(p,secs[i]);
    }
  }
  function toggle(){
    var sec = this.parentNode.nextSibling;
    if(sec.className.indexOf('collapsed')!==-1){
      sec.className = sec.className.replace(' collapsed','');
      this.firstChild.nodeValue = 'collapse'
    } else {
      sec.className += ' ' + 'collapsed';
      this.firstChild.nodeValue = 'expand'
    }
    return false;
  }
}();

Step 3: Removing every label and name from the functional code

This makes a lot of sense in terms of maintenance. Of course it is easy to do a quick search + replace when the label names or class names have to change, but it is not really necessary. By moving everything human readable into an own config object you won’t have to hunt through the code and suffer search + replace errors, but instead keep all the changing bits and bobs in one place:

collapser = function(){
  var config = {
    indicatorClass : 'collapsible',
    collapsedClass : 'collapsed',
    collapseLabel : 'collapse',
    expandLabel : 'expand'
  }
  var secs = document.getElementsByTagName('div');
  for(var i=0,j=secs.length;i<j;i++){
    if(secs[i].className.indexOf(config.indicatorClass)!==-1){
      secs[i].className += ' ' + config.collapsedClass;
      var p = document.createElement('p');
      var a = document.createElement('a');
      a.setAttribute('href','#');
      a.onclick = toggle;
      a.appendChild(document.createTextNode(config.expandLabel));
      p.appendChild(a);
      secs[i].parentNode.insertBefore(p,secs[i]);
    }
  }
  function toggle(){
    var sec = this.parentNode.nextSibling;
    if(sec.className.indexOf(config.collapsedClass)!==-1){
      sec.className = sec.className.replace(' ' + config.collapsedClass,'');
      this.firstChild.nodeValue = config.collapseLabel
    } else {
      sec.className += ' ' + config.collapsedClass;
      this.firstChild.nodeValue = config.expandLabel
    }
    return false;
  }
}();

Step 4: Use human-readable variable and method names

This is probably the most useful step when it comes to increasing the maintainability of your code. Sure, during development sec made a lot of sense, but doesn’t section make it easier to grasp what is going on? What about a, and especially when it needs to be changed to a button later on? Will the maintainer rename it to button?

collapser = function(){
  var config = {
    indicatorClass : 'collapsible',
    collapsedClass : 'collapsed',
    collapseLabel : 'collapse',
    expandLabel : 'expand'
  }
  var sections = document.getElementsByTagName('div');
  for(var i=0,j=sections.length;i<j;i++){
    if(sections[i].className.indexOf(config.indicatorClass) !== -1){
      sections[i].className += ' ' + config.collapsedClass;
      var paragraph = document.createElement('p');
      var trigger = document.createElement('a');
      trigger.setAttribute('href','#');
      trigger.onclick = toggleSection;
      trigger.appendChild(document.createTextNode(config.expandLabel));
      paragraph.appendChild(trigger);
      sections[i].parentNode.insertBefore(paragraph,sections[i]);
    }
  }
  function toggleSection(){
    var section = this.parentNode.nextSibling;
    if(section.className.indexOf(config.collapsedClass) !== -1){
      section.className = section.className.replace(' ' + config.collapsedClass,'');
      this.firstChild.nodeValue = config.collapseLabel
    } else {
      section.className += ' ' + config.collapsedClass;
      this.firstChild.nodeValue = config.expandLabel
    }
    return false;
  }
}();

Step 5: Comment, sign and possibly eliminate the last remaining clash with other scripts

The last step is to add comments where they are really needed, give your name and date (so people can ask questions and know when this was done), and to be really safe we can even get rid of the name of the script and keep it an anonymous pattern.

//  Collapse and expand section of the page with a certain class
//  written by Christian Heilmann, 07/01/08
(function(){
 
  // Configuration, change CSS class names and labels here
  var config = {
    indicatorClass : 'collapsible',
    collapsedClass : 'collapsed',
    collapseLabel : 'collapse',
    expandLabel : 'expand'
  }
 
  var sections = document.getElementsByTagName('div');
  for(var i=0,j=sections.length;i<j;i++){
    if(sections[i].className.indexOf(config.indicatorClass)!==-1){
      sections[i].className += ' ' + config.collapsedClass;
      var paragraph = document.createElement('p');
      var triggerLink = document.createElement('a');
      triggerLink.setAttribute('href','#');
      triggerLink.onclick = toggleSection;
      triggerLink.appendChild(document.createTextNode(config.expandLabel));
      paragraph.appendChild(triggerLink);
      sections[i].parentNode.insertBefore(paragraph,sections[i]);
    }
  }
  function toggleSection(){
    var section = this.parentNode.nextSibling;
    if(section.className.indexOf(config.collapsedClass)!==-1){
      section.className = section.className.replace(' ' + config.collapsedClass,'');
      this.firstChild.nodeValue = config.collapseLabel
    } else {
      section.className += ' ' + config.collapsedClass;
      this.firstChild.nodeValue = config.expandLabel
    }
    return false;
  }
})();

All very obvious things, and I am sure we’ve all done them before, but let’s be honest: how often do we forget them and how often do you have to alter code where it’d have been nice if someone had taken these steps?