(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?
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.
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.
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.
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.
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."
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 firstname.lastname@example.org.