Is there an inherent business risk in letting your top JavaScript developers do their best work?
(What a painful thought!)
It's one thing to build with the latest tools and techniques, but what happens when the developers who led the way on a given app move on to greener pastures?
JavaScript apps are notorious for being largely written by one "rockstar," ending up dominated by the most experienced JS dev, the most charismatic person, or at least by the fastest typer.
And the first thing the people who inherit an app want to do is undertake a costly rewrite.
How do you overcome that tendency?
The problem isn't devs doing their best work. It's that the software they work on will outlive their attention span and maintenance capability.
So, are JS frameworks the answer?
One key reason enterprises choose highly constrained tools for building with JS: less room for the kind of creativity and innovation that makes a single developer's work capable of being both high return and high risk.
But tools like those can also disengage veteran JS developers who prefer flexibility and modularity.
In my years of experience working with and managing developers, I've learned that developers who are mentally engaged are most capable of amazing work. And developers who are engaged in their work have a stronger desire to keep doing it.
It's a tradeoff: the risk of losing (or depending on) a very good developer is often mitigated by the same tools that increase the likelihood they will leave—or mentally check out.
The tools that tend to make collaboration and consistency easy can leave very good developers hamstrung.
Learning a framework provides a lot of instant gratification, but we've seen frameworks and approaches come and go as the web has rapidly evolved.
Developers who end up learning a framework instead of how to solve problems in JavaScript can limit their long-term potential.
What's more, JavaScript does not lend itself well to one-size-fits-all frameworks. There are certain types of apps that make sense for certain frameworks, but it's undeniable that no JS framework is a panacea.
So how do we solve this problem at &yet?
I'd love to say we've had this down for years, but we actually stumbled upon the answer.
Our first Node.js based single-page app product, And Bang 1.0, was built largely by Henrik Joreteg and myself; I wrote the CSS and Henrik wrote the rest of the app, both server and client.
At a certain point, we decided to do a major refactor, creating And Bang 2.0.
While building the API for And Bang 2.0 was a full-team effort, getting people involved in the JS app proved tremendously challenging. Folks could contribute to parts of the app, but in the end, it was fully dependent on Henrik because not enough of our team understood the approaches Henrik was taking in building the app.
This presented a huge long-term risk. It wasn't good for the team, and it certainly wasn't good for Henrik. We all knew action was needed.
At one point, I recall a few of us taking Henrik out to a really painful lunch.
We told him that despite being the most productive developer on the project, he was no longer allowed to write JS on the app. He could only open issues, write documentation, and educate.
Soon, Henrik's work documenting the approaches he'd taken on the app sparked involvement from others on the team. Things rapidly got clearer, easier to understand, simpler, more consistent.
The conversations that emerged resulted in many of the philosophies and conventions he eventually explained in his book, Human JavaScript.
Then something amazing started happening.
Where we had previously experienced frustration getting people onboarded in working on our advanced JS apps, we suddenly started to find that from veterans to new developers, these apps "made sense," and it started to look like collaboratively authored code was the work of one person.
Our team has loved working this way.
Here's what Philip Roberts said in his first day working on one of our JS apps: "This code is a dream. This is the most organized and understandable codebase I've ever seen."
We released Human JavaScript a year ago to great acclaim beyond our team.
We've since decided to follow it up with a highly experiential and interactive training that goes even deeper than Human JavaScript.
JS for Teams: It's Aliiiive will provide a comprehensive training on the approaches we've developed over the course of years.
JS for Teams will help your team build complex but maintainable single-page applications with a modular JS approach.
Registration is extremely limited. Tickets are now on sale. Don't miss out!
P.S. If you're interested in custom JS for Teams training for your organization, reach out to us at training@andyet.com.