Jun 14, 2018

Becoming a team lead: a survival guide

This post is a transposition of my Fluent talk Becoming a team lead: a survival guide. It’s been edited to better fit a blog post format. If you prefer to see the original format, you can view the slides with speaker notes instead. A video of the talk will be up some time in July 2018.

A survival guide is a strange thing to call this post, since survival guides are usually very serious books that prepare you for extreme situations. Building shelter in the wilderness, foraging for food, avoiding being eaten by bears - that sort of thing. I’m never sure when is the right time to read a survival guide, since being lost in the wilderness or being hunted by bears is not something you really plan for. If you read the survival guide too early, you forget most of it. If you read it too late, it’s no use.

Anyway, the reason this is a survival guide is because after spending my entire career as a software engineer, I was thrown into a team lead role without much warning. I had no idea what I was doing and had very little support. This is the survival guide I wish I had. It documents my experiences as an inexperienced team lead –as an engineer transitioning to a team lead– and my learnings & mistakes along the way. Hopefully this can act as a survival guide for you, too.

This is a fairly long guide, so I’ve split it into sections. Feel free to skip sections that aren’t relevant to you.

Introduction: the accidental leader

In 2014 I was lucky enough to be offered a job at the BBC in London. The team I ended up working on was made up of 10 people, 7 of whom were software engineers. We had a fantastic team lead (Hi, Pete!) who kept things running smoothly and –more importantly– kept the team happy. I learned a lot from Pete.

Then, disaster struck. Within the space of only a few months, most of the team leads in our department left. Including Pete. Up until this point, I had naïvely been trying to climb the career ladder and attain more power for myself within the department. So I had essentially already been digging my own grave (okay, I’m being a little dramatic here) and it only made sense that our head of engineering pushed me into it by asking if I would temporarily fill a team lead role.

Despite my desire for more decision-making power, I was apprehensive about taking a team lead role. I liked writing code, I didn’t like responsibility, and I really didn’t want to become a manager. I was assured, however, that my day-to-day work would hardly change, and that I wouldn’t have to do any management.

Looking back on this moment, I feel a bit stupid. Of course I took the role. It sounded perfect: all the power of a team lead with none of the responsibility. It was exactly what I wanted. If only I knew back then that things would not pan out like that at all. In hindsight I would say that the first few months of my new role as team lead were some of the most stressful and challenging months of my career.

This is really common.

Having spoken to many other team leads since then, I’m amazed at just how common this scenario is. Almost all of the team leads that I’ve met in software development sort of “accidentally” fell into their leadership roles despite having no prior experience, and almost all of them found it difficult to get any support after taking the role – regardless of whether they worked for a small startup or a multinational organisation. It seemed like in contrast to their previous career progression, becoming a team lead was vastly more difficult and overwhelming.

I think that in general the team lead role is misunderstood, and it is also oversold. Our industry is really good at pretending that software delivery is all about writing code, but in all of my experiences this is never the case. Some of the hardest problems in software are either people problems, organisational problems, or cultural problems. Yet we continue push technically brilliant software engineers into leadership roles, with no training in communication or management, and we wonder why they struggle to deliver or why they burn out.

Part I: Before you apply

Understanding the team lead role

The best way to avoid becoming an overwhelmed, burnt-out team lead is to not become a team lead. No, seriously. It’s important to be able to recognise when you’re not ready for a team lead role, or when to say no if you find yourself being pushed into one.

There are a lot of myths about leadership, and one of the biggest is that you gain power simply by becoming a leader. I thought this. A lot of people think this. My reasons for wanting to become a team lead were along the lines of:

I learned pretty quickly that my reasons were all wrong. If you find yourself agreeing with any of them, then I seriously urge you to delay taking on a team lead role because it might not live up to your expectations.

Then what are the right reasons to become a team lead? I would sum them up like this:

If that sounds like you, then you might find that a team lead role suits you well!

Setting yourself up for the role

Assuming you do want to become a team lead, how do you set yourself up for the role so that you’re prepared well in advance?

You likely already work in a contributor role, which will mean doing this preparation in your own time. If you’re lucky enough, you might be able to prepare in your company’s time. Either way, this time will be a good investment because it will help you to hit the ground running and become a more effective team lead.

Do some research

You’ll save yourself many headaches by researching the team lead role in advance. Learn what to expect from the role, and what skills you need to sharpen. The fact that you’re reading this is a great start (there’s a further reading section at the end of this post too). I would recommend investing time in improving your communication skills and learning about different leadership techniques.

I also recommend learning how to identify and deal with mental health issues because they are extremely prevalent in our industry. Being able to identify issues early on in yourself and the people around you can make a huge difference in preventing burnout.

Fix things that cause pain for the team

The aim of this is simple: get used to the idea of being someone who removes roadblocks for the team rather than being a core contributor. Start by volunteering to attend boring meetings, or optimise people’s workflow by making the build faster. Removing pain from the rest of your team will keep them happier and allow them to work with fewer interruptions.

Take every opportunity to mentor

Mentorship is a great way to transfer knowledge and grow your team. It also helps to reduce the team’s reliance on you. You should pair program with junior team members to help them get through their workload, and regularly invite other people to sit with you whenever you are working through a problem.

Being a good mentor is something that I believe really only comes with experience. Getting the experience early on will make you a much better mentor when you move into a lead role.

Focus on the bigger picture

You’ll likely be at least partly responsible for delivery as a team lead. It’s good practice to zoom out and think about the optimal way to get to the end of the project. In particular, think about how to avoid roadblocks in your upcoming work. Sometimes it’s better to have one person work on something totally unrelated to your current sprint so that the rest of the team can work unimpeded in the next sprint.

Be present

Software folk are very good at putting their headphones on and living in their own little bubbles. This reinforces the idea that software development is some sort of mythical or sacred practice that should never be interrupted, and it makes people second guess whether they should ask for help. This isn’t what you want in a team. You want people to be comfortable asking for help – that can be the difference between a successful & productive team who ask for help as soon as they’re stuck, and an unproductive team who struggle with their work in silence.

Part II: You got the job!

So, you’re a new team lead - congratulations! The following sections are your handbook to being an effective team lead in your daily work.

Avoid being overwhelmed

Being a team lead can be overwhelming at times, especially during the first few months while you’re still getting a grasp of everything. If you feel yourself becoming overwhelmed at any point, don’t ignore it. Humans are generally quite good at picking up on each other’s emotions, so a stressed or overwhelmed team lead can inadvertently pass stress on to the rest of the team.

Stop writing code

One of the first things you should do when you’re feeling overwhelmed is stop writing code. Even though (for me) coding is one of the most enjoyable parts of the job, writing code takes a lot of time and it generally makes you unavailable to the rest of the team.

If you’re working on something important, see if you can pass it onto a team member. Otherwise just put it to one side for a few days.

Learn to delegate

Learning how to delegate can be difficult, especially for team leads who are transitioning from a full-time contributor role. Often the problem is that the team lead is still considered to be (or considers themselves to be) the de facto owner of certain parts of a codebase. Explicitly passing this ownership on to somebody else can help make it easier to ask other people to work on that code.

Delegation is easier said than done, but doing it correctly can be an extremely effective way of reducing your stress levels. Pick a member of the team you know is capable, make sure they have low stress levels, and (politely!) ask them to complete a task for you.

Say no

This is a personal favourite of mine, and it made a few of my senior stakeholders very unhappy at times. Saying “no” when you or your team is asked to take on more work is a totally valid way of dealing with being overwhelmed. Of course there are more polite ways to say “no”, like “can you ask me again next week” or “is there anybody else available to do that”. However you say it, it’s always better to say no than to disappoint someone by being too busy to fulfil their request.

Saying no has this other benefit which is that it signals to your boss or stakeholders that you or your team have too much to do.

The best case scenario for saying “no” is that your team is given some extra help to deal with the workload. The worst case scenario is that you’re told to do the work anyway, in which case…

Ask for help

We’re not very good at this in the software development industry. It’s as if there’s a bizarre sense of achievement or credibility in struggling through a problem for days when it could have been trivially solved by someone else in minutes. “Help” can come in many forms: someone helping you get through your work, mentorship from your boss or another team lead, or just be someone to talk to over lunch. Whatever form it comes in, don’t be afraid to put your hand up and ask for help when you’re feeling the pressure. You’ll thank yourself later.

Similarly to saying “no”, asking for help sends a clear signal upwards that your team isn’t coping. This doesn’t indicate any failure on your part! If anything it indicates a failure with your stakeholders or upper management – they’re not managing their people (“resources”) well enough.

Conducting effective one-on-one meetings

I spent the first few months of being a team lead panicking and stressing about my workload, so I saved time by avoiding one-on-one meetings. I assumed that if anyone needed anything, they would just approach me. This was a really big mistake. One-on-one meetings are one of the best ways to keep in touch with your team because they offer a private & safe space in which to have open & honest conversations that you would not normally have in front of the rest of the team. They might feel awkward at first, but eventually these meetings should feel as natural and casual as a daily stand-up.

Have them regularly

The first piece of advice I have around one-on-one meetings is to have them, and have them regularly. I only mention this because I know from experience how easy it is to avoid them. It doesn’t matter how tight your deadlines are, or how much fun your current workload is, meeting with your team should be at the top of your priority list.

Having them every 2 weeks is a good place to start. If 2 weeks feels too regular, you can slowly increase the time between meetings until they feel just right. Remember to set up recurring calendar events and treat them like you would any other important meeting. Never skip them!

Use a template

I found it really useful to have a template for my one-on-one meetings. A template gives your meeting some structure and ensures that you don’t miss out anything important. You can stray from the template and adjust it as you go along - it’s just there as a guide.

Take notes

Take notes of everything that’s discussed, because you’ll want to refer to them later. Get the consent of the person that you’re meeting with first, and reassure them that you’re only making notes for your own reference, and that they are completely confidential. I usually start every meeting by showing the other person my notes from last time, to make sure we’re on the same page.

Prepare beforehand

Give yourself 10 minutes before each of your one-on-ones to prepare yourself. Think about what you want to say. Remind yourself what each person has been working on recently. Go over your notes from the last meeting and make sure you’ve done everything you said you would. If you haven’t, well, you’ve got 10 minutes to think of some good excuses.

Ask and listen

Probably the most important bit of advice regarding one-on-one meetings is to remember that your role in these meetings is to listen. After you ask a question, just sit back and listen. Long stretches of silence are okay - they give you both a chance to think. Don’t just listen, either. Really take in what the other person is saying – regardless of how important you think the matter is, or whether you agree or not. This person is telling you something because they think it’s important, and it’s your job to take everything they say very seriously.

Don’t over-promise

Remember how I said that you should do everything that you said you would in the last meeting? It helps if you don’t put yourself in an awkward position in the first place by promising things that you can’t deliver. It’s fine to promise that you’ll order a new keyboard, or that you’ll raise an issue to your manager’s attention. But don’t ever promise things like promotions or pay rises. Over-promising will only lead to disappointment and dissatisfaction.

Dealing with pressure from stakeholders

Let’s talk about stakeholders. No matter the size of your company, you probably have at least a few. They’re the people who are interested in the outcome of your project, and they probably set the overall direction of your work by coming up with the project requirements and various tweaks along the way.

Always be honest

Always be honest about how your project is going. Especially if you’re behind schedule. In business-speak, this is called “managing expectations”, and it’s vital that you and your stakeholders have the same expectations.

… Unless you’re ahead of schedule

There is one exception to the “always be honest” rule, which is that you should not tell anyone that you’re ahead of schedule. The only time you’re really ahead of schedule is when you finish the entire project early. Until that point, you’re just one unexpected delay away from being behind schedule.

Compromise early & often

Since you’re going to be telling your stakeholders when you’re behind schedule, a useful skill to have is negotiating compromise. Compromising can be an awkward and painful process where you basically ask your stakeholders to either cut back features or give you more time. You should try to compromise as soon as you know the deadline is tight, and you should do it as often as you need to. Compromise until the deadline feels truly achievable. Just remember that there is no “us vs. them” – everybody wants the same outcome, which is a high quality product delivered in a timely manner.

Don’t pass the pressure onto your team

There will be times where you truly are behind schedule and there are no compromises to be made. During these times, a good team lead will shield their team from any pressure, and generally protect them from the harsh realities of the world. When the pressure is on, the last thing you want to do is stress the team out. Even teams that work well under pressure will eventually burn out and become unproductive.

Ask for help

A common theme in this guide is to ask for help. A strategy I’ve used successfully in the past when I’ve been really close to a deadline is to borrow some time from another team. Then I can return the favour when that team needs help in the future. This is effective because having somebody else work on little things like bug fixes can really take the pressure off everybody else while they focus on finishing major features.

Grow & support your team

I said before that a core part of the team lead role is growing the people on your team. I think it’s actually the most important part. You might be tempted to say that delivering value to the business is the most important part of your role, but you’ll find that as people grow, they learn new skills and they become happier and more productive. The more skilled your teams are, the more value they deliver (and the more you should pay them).

People grow in different ways, and part of your role is to identify how everyone on your team grows best. Some people like to be mentored, and told what to do. Some like to be given reading material or tutorials to follow. One thing that is common to most people I’ve worked with is that they grow when they’re challenged.

Allow pet projects

Sometimes your team’s day-to-day work isn’t challenging enough to stimulate growth. This is why I’m quite fond of pet projects. You don’t have to set aside dedicated time for pet projects, like Google’s now-defunct 20% time. Instead you can allocate time for pet projects when they’re most appropriate. For example, someone on your team wants to learn about React. Wait until you have some downtime, and then ask them to spend a day or two building a simple clone of something they worked on recently using React. Afterwards, have them report back to you (and the team, if they’re comfortable with that) on the pros and cons.

Encourage pairing

For the times when the day-to-day work is challenging enough, you want to make sure that everyone on the team is actually progressing with their work enough to really learn and grow from it. I was given a tip to help with this:

Nobody is allowed to work on a task by themselves for more than one day.

I think this is a fantastic tip. It ensures that people spend less time being stuck on simple problems, and more time progressing with their work in a way that challenges them and allows them to grow. It also works really well for tasks that you know will take longer than a day, because you end up with more than one person having knowledge about these complex tasks. This reduces your reliance on a couple of key people that normally take on the complex tasks.

Run knowledge sharing sessions

Getting together on a regular basis to talk about things you’ve all learned recently can be a good way to keep everybody up-to-date on the whole project. You can even use these sessions as a way to talk about non-work things, like what you’re all planning to do over the weekend. This doesn’t work for all teams, but it’s a nice way to make the meetings more informal and get everyone to know each other as people.

These sessions are also the perfect opportunity to invite other teams along to encourage cross-pollination of ideas.

Spend time together

I’m not a particularly social person. I used to be the person who would skip team lunches because I’d rather eat by myself. Everybody relaxes and has fun in different ways, which is why it’s so important to enable the team to spend time together in a variety of settings. Have lunch together in a restaurant, or in the office, or in a park. Go to meetups or conferences together. Start a book club. Use techniques like swarming –where you all work together on the same task– to bring everyone together.

Swarming is a particular favourite of mine. Firstly because it’s a great way to trick people into spending time together (they all think they’re doing work but in fact they’re bonding and being social – ha, punk’d!) and also because it’s just a genuinely good way of getting work done. I’ve found that swarming works particularly well for tasks that are big but easy & monotonous – things like testing a single feature on many configurations, or writing documentation.

Remember: you are a team!

Every team is different. As the team lead, your job is to celebrate everyone’s differences and make every effort to ensure that each person on the team has an equal opportunity to grow and achieve their goals. I promise you that focussing on the growth and happiness of your team will not only make you a better team lead, it will make your team happier and proud to work together. It will make your team more productive and more successful. If you’re lucky, it will even inspire members of your team to become great teams leads in the future – just like you.

Further reading

Here are some other resources to help you become a better team lead.

(Read more)

Aug 5, 2017

Introducing Second: a framework for mostly-static React applications

TL;DR

Why build this framework?

While using React to build the BBC News front page and several other mostly-static pages, a common theme emerged: only a small number of components on these pages require client-side JavaScript to function. Rendering every component in the browser does not provide an optimal experience — especially for users on low-powered devices or low-speed connections. Instead, selectively bundling components for the browser reduces bundle sizes and minimizes CPU overhead without sacrificing React’s event system and stateful components.

Second is not a large or complex framework. It is the result of combining several simple and well-tested techniques—

—and combining them into a single package that can be easily reused across multiple applications.

(Read more)

Apr 4, 2017

Introducing a faster BBC News front page

Web performance is something I care deeply about both as a developer whose work affects millions of people around the world, and as a user who often accesses the web on slow & unreliable connections. I have regularly and loudly complained that the BBC News website is unnecessarily slow, so when I was given the opportunity to help rebuild one of the most visited pages of BBC News—the front page—I jumped at the chance.

That was April 2016. Now, a whole year later, we’re ready to begin a phased rollout of the new front page. Starting with a small percentage of users in the UK, we will gradually move everybody to the new front page over the course of several weeks. (Update: as of June 2017, the new front page is rolled out to all users).

Quick facts about the new front page

(Read more)

Feb 16, 2017

Web development technologies to adopt in 2017

I started 2016 feeling quite overwhelmed by the sheer number of new technologies that were being introduced. This year I feel like many of those technologies have matured, so I have collated a list of the ones that I think deserve your attention. My focus for the last couple of years has been on performance, so I’ve made an effort to ensure that all of the technologies mentioned are either “performance-friendly” or are directly related to performance.

(Read more)

Feb 13, 2017

How we assemble web pages at BBC News

This post is about the Web Application Framework in use by some teams at the BBC. It is not strictly a framework in that it specifies the contracts between components, rather than providing concrete implementations of the components. For this reason, I prefer to think of it as the Web Application Specification.

At the beginning of 2015, a group of developers and technical architects from around the BBC got together with the goal of designing a system for sharing web page components between teams. This came from an acceptance that most of the BBC’s public-facing web products have a similar look & feel, and a desire to improve efficiency through sharing rather than building similar things over and over again.

(Read more)

Dec 26, 2016

What it's like to work as a developer at BBC News

The BBC is a pretty large organisation. Today it employs around 20,000 people (actually around 35,000 when you include part-time and fixed-term contract employees) across a huge number of divisions. The BBC Careers website typically has over 100 vacancies posted on any given day. Before I joined the BBC, I found the sheer scale of it a bit intimidating. Usually I can get an idea of what it’s like to work for a company by reading their job advertisements and their engineering blogs, but with the BBC I was almost completely clueless. In this post I hope to shed some light on what it’s like to work as a developer or tester for BBC News.

Just a small disclaimer first: from an engineering perspective, the BBC is not like most other companies — it’s more like dozens of smaller companies, each with their own engineering department, working towards a common goal. News, Sport, Programmes, iPlayer, Radio… As digital products, these are all built mostly independently of each other. I work for BBC News, so a lot of what I’ve written may not apply outside of BBC News.

(Read more)

Jul 22, 2016

Redefining the BBC News core experience

TL;DR: Over the last 4 years, the BBC News core experience has been transformed from a speedy 21KB page into a slow & bloated 685KB monster. This was in part due to a lack of performance monitoring and 4 years of feature creep, but also due to a lack of performance-oriented culture throughout the business.

I created a lightweight prototype of the BBC News core experience which demonstrates that focusing on the content first and foremost can result in an extremely fast page. I want the BBC and other websites to rethink what the core experience means, and experiment with giving users the power to define their own experience.

In the beginning of 2012 the BBC Responsive News team wrote about how they provide a “core experience” for users by default, and then progressively enhance the page if the browser cuts the mustard. At the time, this was cutting edge. They were able to build pages that worked on practically any browser without compromising the experience for users on modern browsers. To quote directly from the Responsive News blog:

(Read more)

May 20, 2016

Using A/B testing to prioritise performance optimisations

Back in December 2015 I spoke at LDNWebPerf alongside Peter Chamberlin about how web performance is not a technical problem (slides with speaker notes). One of the things I talked about was how we used multivariate testing (MVT) at BBC News to prioritise performance optimisations. The gist of it was that our stakeholders had already bought into the idea that performance has a strong correlation to business metrics, and they wanted to dedicate some development time to improving performance. The catch was that they didn’t want to spent too much time on it.

Our predicament, then, was that we needed to know which optimisations had the biggest impact on performance without actually spending the time to make the optimisations. For example, we had a hunch that inlining the critical rendering path CSS would improve our start render time, but with over 1MB of CSS and a complicated application architecture, implementing this was much easier said than done.

This is where the idea to A/B test performance came from: we could easily make the performance optimisations by hand on a single page, and then benchmark each of the optimisations to find out which had the biggest impact.

(Read more)

Mar 28, 2016

How can we fix open source culture?

The recent kerfuffle around the NPM #unpublishgate and the Greenkeeper bot impersonation has got me thinking about the open source community and its culture.

Sometimes the open source community feels like a wonderful, cooperative, welcoming place. There have been times when maintaining an open source project has given me an enormous sense of satisfaction and well-being. On the best days, complete strangers offer valuable feedback and even actively contribute to my projects.

(Read more)

Aug 23, 2015

Accidental Keyboard Enthusiasm

Over the last 5 years I’ve managed to collect quite a few mechanical keyboards, to the point where I think I qualify as an (accidental) enthusiast.

Das Keyboard (3) Model S Ultimate

This was my first mechanical keyboard. The soft Cherry MX Brown switches make it my favourites for long periods of typing. Even so, I rarely use it any more. At the time of writing, this model is still available on the Das Keyboard website.

Das Keyboard Model S Ultimate

CODE Keyboard

I was really excited when Jeff Atwood announced the CODE keyboard. I already knew that I wanted my next keyboard to be compact and have backlit keys, so the CODE seemed to come at just the right time. Not long after buying the CODE, I purchased some Keycool rainbow keycaps so brighten things up.

The CODE has Cherry MX Clear switches, which makes for a much firmer keyboard than the Das. I find the clears preferable for short bursts of typing, but over long periods they tire my hands out.

(Read more)

Jul 27, 2015

Functional Programming Resources

This post contains a collection of resources for learning about functional programming. These resources cover a range of levels from beginner-friendly introductions right through to more advanced concepts. (Read more)

Jul 8, 2015

Useful Git Commands

Some notes on terminology

In case you’re not familiar with some of the terminology used below, here is a small glossary.

Object

An object in Git is either a blob (file), tree (directory), commit, or tag. All objects in Git have a hash (like 99b69df491c0bcf5262a967313fad8be0098352e) and are connected in a way that allows them to be modelled as a directed acyclic graph.

Reference

A reference in Git is a bit like a pointer, or a symlink. References are not objects themselves, and they always point to either an object or another reference. Branches, tags, and HEAD are examples of references.

You can learn about all of this and much more in my Hacker’s Guide to Git.

(Read more)

Apr 26, 2015

Cabal: Installing readline on OSX

I’ve had trouble installing the readline package on a few separate OSX installations, so I figured it was worth writing the solution down.

When running cabal install for a package which depends on readline (or simply when running cabal install readline), Cabal exits with errors along the lines of

Configuring readline-1.0.3.0...
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for GNUreadline.framework... checking for readline... no
checking for tputs in -lncurses... yes
checking for readline in -lreadline... yes
checking for rl_readline_version... yes
checking for rl_begin_undo_group... no
configure: error: readline not found, so this package cannot be built

The problem is that Cabal is not aware of the location of the readline lib. My workaround is to specify the location of the lib whenever running these commands:

$ cabal install readline --extra-include-dirs=/usr/local/Cellar/readline/6.3.8/include/ \
                         --extra-lib-dirs=/usr/local/Cellar/readline/6.3.8/lib/ \
                         --configure-option=--with-readline-includes=/usr/local/Cellar/readline/6.3.8/include/readline \
                         --configure-option=--with-readline-libraries=/usr/local/Cellar/readline/6.3.8/lib/

Your paths may differ slightly if you have a different version of readline installed. You can check this with

$ ls /usr/local/Cellar/readline
6.3.8
(Read more)

Oct 31, 2014

Transitioning to a new keyboard layout

I’ve long been considering switching to a different keyboard layout. I tend to type with mostly my forefinger and middle finger, only using my ring and pinky fingers occasionally to stretch out to the modifier keys. Despite this, I still manage to type at around 120WPM on a staggered QWERTY keyboard.

Thinking back, I probably started teaching myself to type at a reasonable speed around age 10. I’m now in my mid-twenties. My typing technique (or lack thereof) never really bothered me, but 15 years of typing with poor technique has started to take its toll. Recently I’ve started experiencing hand fatigue, and I’m beginning to see early signs of RSI. So I figure now is the perfect time to make some changes to the way I type.

(Read more)

Aug 2, 2014

JavaScript Performance: Variable Initialization

Initializing variables properly in JavaScript can have significant performance benefits. This can be shown with a simple synthetic benchmark.

notype.js

var x = null;

for (var i = 0; i < 1e8; i++) {
    x = 1 + x;
}

withtype.js

var x = 0;

for (var i = 0; i < 1e8; i++) {
    x = 1 + x;
}
(Read more)

← Older Posts