How To Keep Up With Web Development Trends (Or, How I Got Tickets To Hamilton)

You might’ve heard of Hamilton. It’s the biggest thing on Broadway right now. When the rumored date of lead actor Lin-Manuel Miranda’s final performance hit the news, the resale value of tickets for that day soared to nearly $10,000. I saw Hamilton back in December, and while standing in line to get into the theater, a group of girls came up to take pictures of each other posing in front of the Hamilton-branded entrance. They didn’t have tickets and were in awe of the people standing in line. In light of all the hype, we felt some awe ourselves standing outside this incredibly exclusive show holding tickets we had purchased for face value. 

“How did you get tickets?” the girls outside the theater asked.

Unfortunately, I didn’t have any special secrets to divulge. The answer is, simply, I bought them before they sold out. If you could go back in time to when my friends and I were planning our New York vacation, knowing what you now know about Hamilton, you might squirm watching us purchase these tickets. We hemmed and hawed over dates and sections. We deliberated and procrastinated. Tickets to Broadway shows aren’t cheap and we wanted to make sure we were making the right choices. 

We didn’t really realize that there was an invisible clock hanging over our heads, ticking away. Mere hours after we made our purchase, the New York Times put out their rave review of the show and since then it’s been as sold out as a show could possibly be. If we had waited to see how the critics reacted, we would’ve had no hope of getting a seat. 

Risk and Reward

In the world of web development, we have some of our own Hamiltons—there always seem to be a myriad of new trends being labeled “game-changers,” which may or may not live up to their hype. For developers, there are a lot of choices available in how we go about structuring and building a website. There are frameworks we can use to avoid reinventing the wheel on common tasks. There are tools that can automate portions of our workflow to keep our work quick and consistent. There are different schools of thought when it comes to the actual code being written—how things should be named, where they should be placed, and how parts of code should or should not intertwine. While there isn’t typically a moment when a tool or concept “sells out,” we can’t be left behind while competitors are innovating, and we certainly can’t cling to tools and practices that are becoming obsolete or weigh down our projects with inefficiency.

The lesson of my Hamilton tickets might, at first glance, seem to be one of jumping on promising opportunities as soon as they present themselves, lest you get left behind. In reality, it’s not that simple. Trying new things—both things that are new to you and things that are new, period—is inherently risky. 

Learning, for example, has a cost—are there people involved in the project who will need time to familiarize themselves with a new tool or technology? What about in the future, if new people need to be brought on board? If roadblocks are encountered, how deep is the team’s knowledge of the new method—will it take longer to troubleshoot problems than if they were working with a more familiar option? If the “next big thing” does turn out to be a bad choice, how big of an impact will it have on the project—what is the worst case scenario?

When it comes to bringing in code or tools owned or maintained by people outside the project, this has its own risks. When they work well, being able to leverage existing solutions can be a huge benefit. For example, you might host your company’s marketing videos on YouTube, which has a development team of experts whose full time job is dealing with the ins and outs of video hosting. It doesn’t make sense to try and recreate what they’ve already accomplished if what they’re offering is sufficient, as your organization doesn’t have all of the resources they have. This means that you become a little dependent on YouTube, and if their site has bugs or if YouTube as a whole gets shut down, then it has an impact on you, too. 

YouTube is not a particularly risky choice—parent company Google has a reputation for reliability and the site’s success means it’s probably not going anywhere anytime soon. Other choices, however, can be less straightforward. Recently, there was an incident where some high profile projects were crippled when a very small piece of outside code they were leaning on was yanked out from under them—this sparked articles and blog posts like NPM & left-pad: Have We Forgotten How To Program? that criticized the practices that led to this problem in the first place. It was a reminder to programmers everywhere that dependencies, if excessive and not properly managed, can make a project overly complicated and a little fragile. 

The Waiting Game

CSS pre-processors are a valuable tool in web development and when they first became prominent, there were multiple solutions rising to popularity simultaneously. There were differences in how they approached the concept but for the most part, they were trying to accomplish the same things. In these cases, inevitably some solutions become more successful than others, leaving some early adopters stuck with a runner-up that might not be viable into the future (much like those who championed Betamax over VHS in the video format wars of the 70s). For some people, the appealing option may have just been to wait and see which technology rose to the top. But, of course, the longer you waited, the longer you were going without all of the benefits of CSS pre-processors and potentially falling behind in your skillset. Other people were eager to charge ahead—to not just witness the progress of these tools but to actually contribute to that progress.

Coincidentally, Hamilton itself might be asking us to consider something similar. The show presents a contrast between Aaron Burr, who avoids controversy and waits to “see which way the wind will blow,” and Alexander Hamilton, who “doesn’t hesitate” and “changes the game.” Here’s what I remember from my high school history classes: Alexander Hamilton is the father of our banking system, the man on the ten dollar bill. Aaron Burr is… the guy who shot Alexander Hamilton. (Plus, the musical isn’t called Burr. Caution does not often get a person’s name in history books.)

Here’s the other thing about history: it is, as they say, written by the victors. For every developer blazing trails, there are websites built with tools that are no longer maintained, in a language few people are versed in, based on conventions that never became best practices. They can be, at best, a hassle to maintain, and at worst, unable to evolve or even continue fulfilling the purposes they were built for in the first place. Sometimes these outcomes are only obvious in hindsight. (To bring it back to Hamilton, Alexander Hamilton was always making enemies and ultimately died in a duel, so things didn’t necessarily work out too well for him, either.)

Everything in Moderation

So you can’t resist change for too long, but it’s also dangerous to go too fast. You need to be efficient, but you also need to build things that are reliable and lasting. How do you find middle ground?

I try to approach my development choices in the same way I approached my Broadway show choices. It’s definitely fun to see a Broadway phenomenon in its early days, but rumors of Hamilton’s imminent success were not why I bought my tickets. The real goal was to put together an itinerary of things that my friends and I would enjoy based on our needs and our tastes. It just so happened that this thing that we found appealing ended up appealing to other people, too.

This might seem like common sense—taking risks when they seem like the right choice for the project at hand—but it can be easy to lose sight of this when you’re feeling the pressure of staying on the cutting edge. Fear of missing the bandwagon should not be the sole reason behind any decision. The assumption is that if something is generating a lot of buzz, then it must be offering something potentially valuable. But it’s up to us to understand and evaluate that for ourselves and our unique situation. Something can be good, but not good for us. Sometimes, we will find that popular opinion did not align with our personal opinions in the long run. And although that’s unfortunate, it is not the worst case scenario—if we get value out of something and it makes our work better than it would’ve been without it, that’s not a failure. 

It’s also prudent to avoid introducing many new tools or concepts on a single project. Besides the fact that the risks are multiplied, often these things need to interact with each other and the complications of that can be difficult to foresee if they’re all unfamiliar to the developers. Without a lot of experience to reference, the initial planning of a project can be full of uncertainties. The safer route, when possible, is to let our tools and processes evolve over time, building upon them and trading out pieces that aren’t working well for ones that will work better in a measured way.

The best part about having tickets to Hamilton is not (or should not be!) the bragging rights of being ahead of the curve. The best part is that you get to actually see Hamilton. The same goes for web development: the best part is ending up with a quality project. We can’t be sure all of the choices we make will be the best and most enduring in hindsight, but we can make sure our risks are smart ones (and remember that not growing and improving fast enough is a risk, too!) The first step is remembering what we’re trying to achieve in the first place: a website that does what it was designed to do, not one that is built upon trends for trends’ sake.