More Than Coding

Because machines still need humans

The Programming Language Skill Scale


  • Know nothing about it
  • Know enough to successfully pretend to know it during lunch
  • Know enough to be dangerous with it
  • Know enough to be employed to be dangerous with it


  • Know enough to ask intelligent questions about it on
  • Know enough to answer n00b homework questions about it on
  • Know enough to ridicule n00b homework questions about it on
  • Know enough to contribute to open-source projects written in it
  • Know enough to be disgusted with the state of open-source projects written in it


  • Know enough to start writing a compiler for it
  • Know enough to abandon writing a compiler for it
  • Know enough to invent an improved version of it to create The One True Language
  • Know enough to get bored and find another language to obsess over for a decade or so

Interoperability Success Stories

If you spend any time writing software, you’ll eventually hit an interoperability wall: two components that should talk to each other just refuse to do so.

Maybe it’s a web API that has just been modified without proper concern for backward compatibility, breaking your existing application in the process. Or perhaps you’re trying to use two middleware products together, only to find that the communication standard they implement is horrendously complex, causing each vendor to interpret it ever-so-slightly differently and making them completely useless when brought together.

For all of the many painful incompatibilities of the past, there are plenty of wonderful success stories of software and specifications that enabled collaboration and integration in myriad ways. You just don’t hear them praised that often.

Here are some examples of technologies that do their job, and then get out of the way.


“It’s way too simple.” “It should be a binary protocol.” “It’s far too slow.”

HTTP has had all kinds of criticisms leveled at it over the years, and yet it prevails. It’s the basis for all web traffic and the vast amounts of secure e-commerce conducted over it, and a whole lot more besides.

A lot of its power comes from incredible simplicity: both computers and humans can understand HTTP commands and headers. Whether you’re a proxy server or an overworked systems admin, HTTP is easy to deal with. A proliferation of tools have been built to support it, further strengthening its foothold.

Dig deeper into its details, and you’ll find a lot of very sophisticated and smartly-designed features: encoding negotiation, authentication, encryption, caching, resumable downloads, redirection, compression, locale matching, and hooks for easily making custom extensions.

And heck, it must be good given that after 20 years it’s still only at version 1.1.


Without the adoption of TCP/IP as the network protocol of choice for the Internet, the world would be a very different place. Coming up on nearly four decades of existence, the ubiquitous packet-switching protocol that is used in almost every server, desktop, laptop and mobile device has become synonymous with the word “networking.”

When was the last time you had a network issue that could be blamed on a deficiency of the TCP/IP specification? Or the last time you had one vendor’s TCP/IP stack fail to correctly implement the protocol?

The world loves IP addresses (well, maybe it loves DNS names more), and they’re here to stay. Why? Because a group of very smart people engineered a beautifully flexible and truly usable technology. And while there are some very compelling improvements being made (or proposed) right now, this outstanding work from the mid-1970′s still benefits us all today.


I’ll admit it: I can’t read XML. My eyes simply glaze over the never-ending stream of < and > characters and the duplicated start and end tags. At its basic level, it’s a reasonable language for handling unstructured data, but the awful complexity sometimes laid upon it (XML Schema and SOAP come to mind) can make it very tiresome to deal with. For many years, it seemed like every new software standard that appeared just had to be specified in XML, regardless of its suitability for the problem at hand. It looked like we were going to be stuck with it forever. And then along came JSON.

JSON evolved within the world of JavaScript but quickly won favor with engineers everywhere as a tremendously useful and simple data format. For one thing, it is completely readable, certainly more so than XML, at least to my eyes. It is also fast to parse because it doesn’t have to go through a secondary validation step to ensure compliance to some overbearing schema. Instead, semantic validation can be performed at the application level, if desired.

Now you’ll find JSON as the underlying syntax in most popular web APIs. It’s even being used as the storage format for new databases. Every modern web browser has native and efficient support for it. And when was the last time you found that your browser or parsing library failed to process valid JSON? Certainly I’ve never encountered that problem. Thank its wonderfully concise grammar for making it so easy for parsers to be created in so many different languages.

There are more…and we need even more

There are plenty of success stories to be found related to well-designed interoperability standards that have spurred innovation by being interoperable. Specifications like the Java Virtual Machine and the CLI are prime examples of hugely successful standards. But why do many other standards find it hard to get an adoption foothold?

The answer is simple. Or, to put it another way, the answer is: simple.

Interoperability standards succeed when engineers are able to adopt them en masse, and that is most likely to happen if the standard is as simple as possible. Specifications that try to boil the ocean will solve little of value because their complexity will lead to less acceptance in the developer community.

Good engineers will usually take the path of least resistance in their work, so if a standard is too complex it can quickly get ignored in favor of an alternative grassroots-driven solution or even incompatible vendor-driven extensions. Conversely, if useful tools exist that lower a developer’s barrier to entry (for example IDE support, SDKs, etc), a standard can be adopted more rapidly.

The software market cares about getting stuff done easily and quickly. If an interoperability standard helps in that regard, it will likely get adopted – regardless of whether it was designed by a committee or a community.

5 signs that you should hire a programmer on the spot

Bringing a programmer in for an interview and a coding test can lead to some interesting experiences, both for the interviewer and the interviewee. Most end up with the hiring manager telling them that they’ll “be in touch,” but sometimes a candidate just nails it. That’s when you consider extending a job offer before they get a chance to leave the building.

At TimeTrade we run a coding test during interviews that, for the majority of programmers, should take about 2 hours in total to complete. The whole test is comprised of a number of small problems to solve, each harder than the one before. That gives us a good initial gauge of performance based purely on completion time: if everything has been solved in under an hour, we’ll be smiling. But if two hours pass and even the first problem still hasn’t been solved, the candidate will most likely just be shown the door.

Above and beyond just solving test problems quickly, here are some signs that a programmer is truly awesome and should be handed a job offer before they leave your building:

1. They present multiple solutions

I recently interviewed a programmer who solved an entire set of tests twice: once with iterative solutions, and again recursively. I quickly made him an offer. Finding multiple solutions to a problem is a skill that engineers will need to use every day.

2. They write full documentation

Last year I interviewed someone who was so diligent, so detailed and so professional about his work that he created full Javadoc and comments for his code before he considered the solution complete. He even wrote fully automated unit tests and checked their coverage percentage. When I came back into the room at the 2-hour mark and found him typing furiously I initially thought he was having trouble with the test, but he was actually in the process of adding HTML formatting to his Javadoc. Engineers who do this intuitively are the kind you’ll want on your team.

3. They improve the test

We deliberately create tests that have some minor issues lurking within them, purely to see if the candidate (a) spots them and (b) is willing to fix them. It might be an inconsistent usage of quotation marks for strings, misleading variable names or anything along those lines. Candidates that look at all of the provided code as the test — not just the pieces we’ve asked them to write — are the ones who will do the same in our real product once they join our team.

An engineer who is willing to tell a potential employer that the supplied test contains problems shows that they consider the quality of their work to be more important than just agreeing to do what they’re told. Hire them and they’ll likely work wonders for your product, going above and beyond their assigned areas to make improvements where they are needed.

4. They refactor smartly

Most candidates like to get a solution working, then sit back and breathe a sigh of relief that they finished it successfully. That’s good, but rarely good enough to justify an on-the-spot job offer. The candidates that solve the problem but then jump right back in to refactor it are in a different category entirely. Their choice of algorithm doesn’t feel right, and they can’t ignore the feeling that it could be more efficient. Their code has some duplication in it, and that burns them up inside. These are the candidates who refactor, rewrite and improve their solution until it’s been crafted.

This can be a double-edged sword, though. If the candidate just keeps rewriting because they’re not happy until they reach a mythical point of “perfection”, there’s a chance they are one of those programmers who doesn’t know when to stop (and similarly, ship). However if they watch the clock carefully and are able to both solve the problem and refactor their solution before their time runs out, that’s a really good sign that you should consider an offer.

5. All other signs point to “hire”

Sometimes there are plenty of non-technical signs that you’ve found the right candidate. Your other team members take you aside and tell you, “We have to hire this lady.” Their personality feels like a great fit for the team. They have relevant and recent experience in what they’ll need to do. You know some people who have worked with them before and they tell you they are wonderful to have on a team (and that they’d hire them again in a second). The candidate is excited about the company and the opportunity and is hungry to start contributing.

If the candidate passes technical muster and all other signs point to “hire,” why wait? If you do, you may lose the candidate to another employer who knows how to read the same signs faster than you can. Instead, be decisive and make the offer fast, thereby telling the candidate how much the company wants them on board. It will help start the whole relationship off on the right foot, for both parties.

So the next time you’ve got a wonderful candidate in your building, don’t assume someone even better will arrive the next day. Make them an offer and get yourself – and the candidate – back to work.

This blog entry has since been translated into Spanish (by Maria Ramos/Web Hosting Hub) and French (by Hinault Romaric/

Web engineer looking for work? Start by rethinking your resume.

We’re currently hiring web engineers to help build the next-generation of TimeTrade’s online appointment scheduling system. Lots of resumes come my way, but 99% of them look exactly the same, following this format:


“I’m a web engineer looking for web engineering work”.
[No link to an online portfolio. No effort to craft the objective to match the position for which they're applying. Typically describes only what the engineer wants to get out of a new position, rather than what she or he will bring to the company that hires them.]



[A boat-load of technologies, old and new, sprayed onto the resume as one enormous list of acronyms. No effort made to describe which technologies they are expert in versus what they've spent 5 minutes playing with on a boring Saturday afternoon. Alphabet soup.]


[A lengthy dissertation about every place the candidate has ever worked. Yawn-inducing descriptions of how they worked there. No URLs for me to see the web applications they built.]

…and that’s usually all I get.

Is there a factory somewhere that churns these out on a conveyor belt? Should I blame Microsoft Word’s built-in resume templates? Or perhaps it’s the fault of tech recruiters who encourage this kind of lazy resume format in the name of “consistency”?

There are plenty of great engineers who could use their experience creating awesome web applications to build incredible resumes for themselves but ironically, never do. These programmers work in a world of aesthetics, creativity and technical artistry and yet advertise themselves with the passion of a 40-year accountancy veteran who enjoys working in the windowless basement of a bank and whose favorite color is gray.

So let’s fix that. Here are some tips that will help you rise far above the crowd.

Completely rethink your resume format

Why submit a typical resume at all? Check out these really creative online resumes that were found on Pinterest. This kind of out-of-the-box thinking might not get you anywhere with old-fashioned employers, but I’ll be blunt: a submission along those formats will get you noticed here, and will very likely put you far ahead of the pack with many other employers.

Build an online portfolio

One of the fastest ways for an employer to figure out if they want to interview you is to show them what you’ve already built. Web engineers have a massive advantage over server-side engineers because their work is visible by its very nature, and very often publicly accessible online. If you’re writing a old-fashioned resume, at least list the URLs for your proudest work at the top.

If your work isn’t public (because it’s only available on pay-per-use sites or hidden behind corporate firewalls) then see if you can get screenshots of your web applications in action and submit them along with your job application.

If possible, build a personal website to host your work samples and advertise yourself using the technology you work in every day. I’d be more than happy to receive a set of URLs to personal sites on a daily basis rather than a bunch of 7-page resumes.

Focus more on the “what,” not the “how”

Technology skills are important, but they’re really a means to an end. Employers want to get things done, and the technologies used to build new features and applications simply aren’t as important as the effort itself. So tell us what you’ve built in the past, the impact it had on your customers and business, and why it should matter to us. Then – and only then – tell us what whizz-bang technologies you used to do it.

Prove that you’re a human

If you’re working in the web applications space, you probably have passions in life beyond HTML5 and JavaScript. Do you hike in the hills behind your house every morning at 5am? Did you build a working life-size tractor out of Lego? Are you someone who likes to run marathons for charity while wearing a Darth Vader costume? Then tell us about it. Personality can mean a lot to hiring managers, especially with a position that centers primarily around creative and visual elements.

I’m happy to review any wonderful out-of-the-box resume sent my way and give constructive feedback. Those who follow the suggestions above are more likely to hear the words, “You need to come and work here!”.

When Outlook Attacks

Most people have had to deal with awful user interfaces at some point. Cluttered, messy applications are everywhere from Windows to Mac, Android to iPhone. There are already plenty of examples online of terrible user interface design, but there is another problem which gets a lot less attention: unwelcome interruptions.

Microsoft Outlook is possibly the worst interrupter of all. As the application that receives and manages all of your private email messages, it makes an astonishingly concerted effort to completely ruin that privacy on a regular basis. When you first install Outlook, it enables – by default – one of the worst user interface components ever conceived: the “Desktop Alert“.

From what I can tell, the Outlook Desktop Alert feature was designed to:

  • Show the contents of your incoming emails to anyone looking at your screen while you’re giving a presentation, demo or web conference
  • Completely interrupt your train of thought and distract you when you’re in the middle of important work
  • Turn your email management experience into something more like an instant chat session

Studies show that a single new email notification can break your concentration for more than a minute, but that’s not the most egregious problem caused by this dreadful feature. The real issue is one of privacy.

Let’s imagine that you’re having a very busy week as a manager. It’s a tough time for your company and you’re helping your boss reduce the costs incurred by your team. You also happen to be meeting with one of your employees and going over some documents with him using your laptop, and both of you are reading intently from your screen. That’s when your boss happens to drop you a line:

The next day you visit a customer who is on the verge of signing a deal with your company for a significant product license. You’re in the final stages of negotiation with them and using your computer to show them an Excel spreadsheet with a pricing breakdown when this appears:

You get back to the office to interview a potential new hire. All is going well, and you’ve convinced them that it’s a great place to work. Sadly, while showing them your company’s software product on your laptop, this is what they happen to see:

Dejected and depressed, you hope that your last appointment of the week will cheer you up: you’re due to present your company’s product to a local user group. But just as you start your PowerPoint presentation and begin projecting your slides onto a 10-foot wide screen, your friendly boss sends you another quick email, which everyone in the room can now read:

Of course, Outlook isn’t the only offender. Skype also has a very noisy default, telling me when each of my contacts have crawled out of their beds and opened up their laptops. Every week, more and more applications offer interruption notification services (and Growl on Mac is making it even more common).

If you’re a software developer responsible for creating a communication tool, please consider carefully how noisy you want your features to be. There’s a really good chance that your users would prefer to focus on their task at hand rather than be constantly bombarded with information that doesn’t require immediate action on their part. Just because a user has graciously installed your product doesn’t mean it’s a good idea to interrupt them over and over again.

More importantly, please remember that a computer screen isn’t always a private work area. Until features like the Outlook Desktop Alert are turned off by default, users who want to maintain their privacy are forced to either turn it off or get rid of it completely.


Get every new post delivered to your Inbox.

Join 32 other followers

%d bloggers like this: