console.blog(

Convention Syndrome, or: How To Be Mediocre

Convention Syndrome

Not too long ago, I interviewed a potential candidate for a front end developer position. As part of the interview, I asked the interviewee if they had ever used OAuth2 in coordination with their JavaScript application. They had, and I asked them to show it to me.

The candidate explained to me how they had used Yeoman to install the mean.js generator. Then the interviewee showed me some code not really related to OAuth. As I watched them, I pointed out some places the OAuth handling might be done, but we dropped it before we found anything.

The last thing the candidate said regarding OAuth was "I used Yeoman to generate the MEAN application and one of the options was to set up authentication, so I said yes and it just set it up for me. I know it uses Passport."

Unfortunately, Passport has very little to do with your application performing an authentication handshake with an authentication service — except that Passport is the authentication service. The front end must handle access tokens, OAuth claims, and more.

Later, I asked the same candidate to write the FizzBuzz program. Besides taking way too long, the interviewee couldn't remember the syntax for a for loop, and resorted to writing a function that simulated a for loop using a while loop. They explained this oversight was because they typically used library iterators like Underscore's .each.

Why can't programmers... program? The one thing that sticks out — and is reaffirmed over and over — is that an affliction is spreading (has spread?) among some developers. I've called it Convention Syndrome, but it could easily be called Generator Syndrome.

What's Going On?

More and more, the tools that we use are billed as "the last [X] you'll ever need." Having things done for you is more desirable than knowing how it works. "Spin up a prototype in 15 minutes," or any variation of the amount of time, is so common that it makes me cringe just hearing it. The problem I have seen over and over is that — despite being able to present a prototype in a short amount of time — the developer is rarely able to create a truly innovative end result. A convention can only hold your hand so far, and a generator will never meet exactly your business' needs.

If I choose a tool to do each job, I have to know how they all hook together.

I have used Sublime Text for a long time, and recently switched to Atom. One of the many things these editors have in common is that they are simple. In fact, I'm writing this post in Atom right now. The beauty of a tool that does a basic task like edit text and really nothing more has many facets, but here are two:

  • It can do it well.
  • It forces me to understand the interactions.

I generally choose a tool for each job, and each tool runs independently of the others. If I choose a tool to do each job, I have to know how they all hook together. That is a positive thing.

The important distinction here is that "job" is absolutely not "get a web app working." A task is something much more concrete, like "manage routing, hashchange, and URL history on the client side." By the way, that's a task I'd earmark for Sammy.js to handle, but I'll talk about that another time.

Let's go back to my interviewee from before. As we looked through OAuth2 code, I saw something familiar:

'Authorization': 'Bearer ' + Cookie( "access" )

This is the code to add the Authorization header to a request, and provide your stored OAuth Bearer Token to the API. Sure that we had just stumbled upon the OAuth handler code implementation, I asked the candidate "where in your application is that access cookie set?" This is an application that this person built, and their answer was, "...Uh, I'm not really sure."

Reliance on generators and convention to "make our jobs easier" is doing nothing but creating a breed of developer who's no better than the documentation of their tool du jour. The ability to think "outside-the-box" apparently only applies if the newest tool on the block has a bigger box than the tool that was being used previously. Knowledge of application architecture and understanding how systems work seem to be scoped to only the tool. As soon as the tool disappears, stops being maintained, stops meeting needs, or — frankly — stops being "cool" (whatever that means), so too does that knowledge disappear, never applied again.

This is why I'm calling this Convention Syndrome: not because conventions are the problem, but because it seems that the trend has been to forgo understanding for the sake of convention. These symptoms may all stem from a central issue, perhaps a level of laziness, perhaps a desire to produce instead of understand. Whatever the reason, I'm diagnosing the syndrome, not the condition. The real issue is that the Convention Syndrome is creating a plethora of developers who appear to be wildly unskilled if you move them just inches outside their comfort zone.

The Web, A La Carte

One of the problems I haven't even touched on regarding this topic is future-proofing applications. The reason I haven't touched on it is because I can rant at length about it, but more importantly: because it's not central to the symptoms of the syndrome.

That said, however, it would behoove me to mention one piece of maintainability to help explain why a la carte is so powerful. Let's assume you've chosen a monolith to build your app. Let's call it Angelic. It does everything for you except butter your bread. It comes with some tradeoffs, like you hard code the names of your models directly into the presentation template, and you do the same thing with code to respond to events like clicks — they're written right into the HTML. You know this isn't great, but it's the Angelic way, and you get so much from the framework. Then, one day a long time from now, Angelic is no longer being maintained, and you need a feature in your models that it doesn't provide. Instead of swapping out the tool that provides your models, you're stuck rewriting your app from scratch, because... monolith.

Are you a programmer? An integrator? Or can you actually create?

Of course, the alternative is to choose the right tool for each job. Understanding how each piece of your code works with each other piece fosters not only responsible development (and developers), but it encourages experimentation and progressive thinking. If you understand what's going on under the hood, you're able to envision solutions that would have been completely obscured to you when something else was handling all of the grunt work.

So the question becomes: Are you a programmer? An integrator? Or can you actually create? It doesn't need to be from scratch, but you should at least know which parts you need to make it all work.