Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck another member of your team who may have lost more time without your advice. You can’t consider only your own time. If the disruption does cost you, it is weighed against your teammate.

When a junior developer disrupts you with a question your support of them is important. They can spend more time stuck than you’d spend to help. Consider how much time you’re actually saving by being interrupted if you include others’ time in that equation. This can lead to a long-term boost for the whole team as they learn from you and others.

In either case you should trust your teammates.

The most common disruption complaint is the “hapless manager” walking over to the in-the-zone programmer for a question. Developers think this yanks her out of a productive state of mind that’s hard to get back to. Do five minute interruptions really cost an hour of productivity? Does it take a long time to get back into a state of mind where you’re productive?

There is an often smug animosity towards non-coders who don’t understand what making software is like. They interrupt us, we like to say, because they don’t understand how a programmer’s mind works. This attitude inflates our perspective of what that interruption costs.

But, our managers want us to work well. Any good manager’s job is to support you in your work. We can communicate when real focus is necessary, but don’t be antagonistic about it. Everyone understands context switching, so include this when discussing schedules and allocation. It should be a part of the process to support the focus you need. Like the developers on your team, your manager needs your attention sometimes. Remember to think about the time of the whole team and project. Don’t think only about your own time.

Remember that the actual act of writing code is only a part of our job. Collaborating with our team and coordinating with our clients and company are just as important. Disruptions from outside the technical team are not taking you away from your work. Those interactions are the work, too!

Interruptions can be irritating but they can also do more good than harm in a cooperating team.

And, sometimes an interruption actually helps you.

Those deep states of mind focused on a problem can feel like an important key to cracking a really hard problem. You just need to dig into the depths of the codebase for three hours to figure out how to solve those really thorny bugs, right? Those deep dives can be fraught with false tunnels and misconceptions along the way. An occasional reset can help a lot! A little interruption of your train of thought means you can look again with fresh eyes.

Opportunities in your work day to take a break from a problem and come back to it later are great. It can be good to have something to take you away from your desk. The truth is that “zone” we’re often in can just as likely see us stuck as it can see us through to a solution. Whether it’s taking a break to attend a meeting or juggling a few projects, something to redirect yourself to gives context switches that can be very helpful. Give developers some options for how to spend their time and give them reasons to break up their day.

A specific interruption can be frustrating but they are not inherently costly to a project. Pay attention to the balance, of course. You have to have a team you can trust, both among technical and non-technical members, too.

So, the next time you gripe about being pulled away from coding, think a little closer about it. Are you putting your team ahead of yourself? Are you giving yourself the breaks you need? Good teams give developers time to focus, but good developers give their teams their attention in return.

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or the code. This mismatches can lead to conflict, arguments, resentment. They can lead to dwindling code quality and eat at the respect and will the whole team has for adhering to the code review.
Hold fast if a new member joins your team who doesn’t buy into the code review sanctity. They will often take code review feedback personally, and their apparent disregard for your suggestions is easy to take personally, as well. That’s a recipe for bad blood and arguments, so try to defuse it quickly.
This brings us to the next respect you need to have.
You have to respect your teammates. You aren’t a collection of programmers who just happen to be working on your tasks in the same codebase. You don’t function independently within the team but as a unit. Code reviews are one thing we do to guide and enforce that idea.
The respect for your teammates goes both ways during a code review. There is respect from the reviewer to the reviewee, as well as the reviewee to the reviewer.
As a reviewer, your attitude and approach can make or break your colleagues’ respect for the process, the team, and you. There are some easy tips in the feedback you give and especially in how you give it, which can make them easier for both sides.
  • Try to avoid blaming “you” language. Don’t say “You didn’t do this right” when you could say “This would be less likely to break if…”
  • Use “we” language to convey the team ownership of the code. If some code convention wasn’t followed, don’t say “I prefer that you…” or “You incorrectly…”, rather say “We always follow array items with a comma, even the last one.” etc.
  • When using “I” language, use soft phrasing. Don’t say “I need” or “I know”, but “I usually” or “I’ve always found”.
  • Just be respectful and review the code for the team, not against the reviewee.
You have to respect your reviewer. I’ve given most of this advice from the perspective of reviewing code, but this rule is all about having your code reviewed.
The first rule of having your code reviewed is “Don’t take the code review personally”. Your code is not a reflection of you and it is never perfect. Your approaches can be great, but everyone can have valuable feedback. Accept feedback with some empathy and humility.
The second rule of having your code reviewed is “The team reviews your code because the team owns your code.” You do not own your code. Even when you’ve just written it when no one else has touched it yet, even if you put hours of effort and sweat into it. You do not own your code, this bears repeating. So, when your code gets reviewed remember that what eventually ends up in the project has to meet the team’s standards and idiosyncrasies. Often, it is essential that you bend your own preferences. You have to allow the code to work for the whole team, even changing your vision. Our code styles and practice should be in context to the team and project we work in, so don’t be completely tied to one approach, even if it’s your favorite approach.
You have to respect yourself. I’m not to write this without including the respect you need for yourself because the rest of the article was dominated by everyone else. Of course, this can mean a lot of things.
Respect yourself to speak up or push back when feedback you get really is wrong, in your opinion. Make your case strongly, but still keep all the advice above in mind when finally coming to a conclusion.
Respect yourself to be a little dignified responding to code review feedback. Don’t take it personally and look petty. Don’t ignore any bits of the feedback without making a case for why, looking dismissive. Don’t get angry about changing code you really looked and highlight your ego.
Respect yourself enough to look good in your teammates’ eyes at the end of the process so everyone can be happy with what finally goes into the project and shared by the whole team.

MDN Brings Browser Vendors To One Table

Have you heard the great news about documentation on the web? Mozilla, Google, Microsoft, and Samsung have made a join commitment to directing documentation focus for their browsers’ web standards to the existing Mozilla Developer Network (MDN).

This is a huge step for the web, for a number of reasons.

First, this commitment means that, with these four vendors committing to combining their documentation, differences will be a lot more obvious. I think this is going to create a big incentive to the vendors towards both compliance and matching pace with each other.

Second, just like the great resource of, developers are going to have even more one-stop shopping for sizing up the differences between browsers on a particular feature, determining when new toys are available consistently enough to use on broad-usage projects, or finding the nuances of working around those differences to provide stable experiences to all your users, regardless of their devices and software.

Lastly, and I think most interestingly, this news is amazing for all that it isn’t. It isn’t particularly shocking or surprising. It gives us a new leg up on cross-browser development, but the gaps it closes aren’t actually that large to begin with. Five years ago? This would have much bigger news then. Ten years ago? This would have been essentially unthinkable. We’ve come a long way to get here, but the vendors cooperation has improved so much that this news, while great, honestly feels almost inevitable.

That feeling gives me a lot of hope for the success of this initiative!

Learning to LÖVE: Getting Started with LÖVE (on Windows)

This entry is part 1 of 2 in the series Learning to Love

Learning to LÖVE is a series of tutorials and articles teaching the ins and outs of building games with the LÖVE engine. LÖVE is a great tool for people new to building games. It can serve seasoned developers, too, as a straight forward way to bring game ideas to life.

This first installment of Learning to LÖVE will get you up and running quickly with LÖVE installed, as well as a recommended editor and extensions that make working with LÖVE games easier. You’re going to install LÖVE to run your games, the Atom text editor to work on your games, and several extensions to Atom that help you write Lua, the programming language LÖVE uses, and to run and test your games.

This targets Windows users, but most of the details will work on other platforms. OSX and Linux versions of this article should be available at some point in the future.

Let’s get started by installing LÖVE itself first.

You can get LÖVE from the project’s website The downloads are first and foremost on the main page, so you can easily find them! I recommend grabbing the “64-bit Installer” option. This will be the easiest to work with, including with the extra tools we’ll be adding next.

Just walk through the installer steps and you’ll have LOVE installed in no time.

Next, we’ll install Atom, our text editor of choice. I’m recommending Atom for three crucial reasons for people new to programming:

  • Atom is a free text editor

  • Atom is easy to use

  • Atom has great extensions, including ones that make working with LÖVE a breeze

Just like LÖVE itself, the Atom website makes the download option front and center. You can find it at, so go there and download the installer now.

Atom doesn’t even require any installer steps. It will install automatically, so just wait for it to complete. Atom is larger than LÖVE itself, so the wait is just a bit longer.

When Atom is done installing, it should open itself automatically. If it doesn’t, you should find it in your Windows menu, so go ahead and open it. You’ll be presented with a lot of first time options. If they are daunting, don’t worry: I’ll walk you through the things you need today.

The first thing you’ll see is the Atom settings and a collection of “Get to know Atom!” options to make it easy to start customizing. The first thing we want to do is “Install a Package” so we click “Open Installer”, search for “love-ide”, and click the “Install” button when the package comes up in the search results.

Atom will run through the package installation steps. It will ask you a few times if you want to install dependencies. Answer “yes” each time. These are just other packages that the one we want depends on to do its job of making LÖVE easier to work with.

When all of these packages are completed you can close the Welcome tab on the right and focus on the settings. Click the settings button on the love-ide package, which should still be present. We’re going to make some small customizations to ensure it works with the version of LÖVE we have installed.

The main thing we want to do is configure Atom to use the debug version of LÖVE , so that we can get information when our code fails. In the first setting, which is labeled “Path to Love Executable”, enter this: C:\Program Files\LOVE\lovec.exe

That’s all the customizations we’re doing right now!

This article is all about getting setup. We’ll make our first game in the next installment, but I’ll at least show you the first tastes of what the process will look like. So we’ll create an empty project and run it to see the most basic LÖVE program run with an empty screen, but its a start!

Click the “File” menu in Atom and select “Open Folder…”

When the dialog appears, click the “New folder” button in the top left and name your first project. We can call it “My First Love Game”.

Now we just want to create a standard file for LÖVE called “main.lua”. All LÖVE games begin with this file, the main script that runs your game. Right click on your project folder and select “New File”, name the file “main.lua” and press enter.

Now you can use love-ide’s LÖVE run button, in your toolbar on the top left, to run this empty script to see the start of your first game run… sort of! It’s just an empty window for now, but you’ll be packing lots of great stuff in that space soon enough.

In the next installment of Learning to LÖVE , we’re going to take this empty script and fill it with our first real game. I hope you’re excited to get into the world of game making!