When Solomon made his famous statement there’s “nothing new under the sun” he clearly wasn’t thinking about the world of javascript frameworks. It seems like almost daily I get word of another framework being announced. Of course I’m only joking as the fundamental underlying concepts remain relatively similar the implementation strategies are often quite different. And the functional differences are where you have to be careful in selecting the choice that’s right for you.
Part of my job is staying aware of all the new technologies and then evaluating them to ensure that things I work on stay on the best path in regards to our future technology stack. All this tech is usually labeled with a rather aggressive term: "Bleeding Edge". I'll use this throughout the post, so if you aren't familiar - read up real quick (remember: keep learning...)
As I work with these different frameworks there are a few criteria I realized I was almost unconsciously applying to each platform I worked on. I realized since these were criteria I used when evaluating things it might be interesting to share and offer it to you to do with as you please.
Advice for bleeding edge technology
Remember that today’s bleeding edge code and methodology will be yesterday’s standard. However, I would recommend caution in this part because as with anything else, you have to pick the right horse (not a racetrack gambler myself but I think the analogy holds true). This can be tricky because it’s frequently very hard to know or to determine. But there are ways to make an educated guess.
Don’t get distracted by shiny objects
Even as I write the title to this section I feel slightly hypocritical even suggesting such a recommendation. I am very easily distracted. It takes constant attention and focus to ensure I don’t get off track. Things like ProductHunt, BetaList and others are constantly proffering the latest and greatest shiny new toy and they pull on my /need for new/. Fight this urge (as I do) until you have the free time to explore these wares for your own entertainment. Shiny objects don’t automatically equal great tools or even the best tool you should consider for implementation. For this reason I suggest not getting distracted by these at all.
Do listen to what others are talking about
The best source of information is the trusted source. Those friends, colleagues, and leaders you look up to. What do they recommend, what are they talking about, what are they excited about. Those are the bleeding edge things you should explore. These aren’t shiny objects (usually) when they are being talked about by others. *There is confidence in a multitude of advisors.* These are the tools you should keep an open mind towards.
That’s important, don’t overlook it. I’m speaking from personal experience here and I’m embarrassed to even mention it but I will for your benefit: I have ignored incredibly valuable advice more times than I care to admit because I failed to /listen to what they were excited about and predicting to be popular/. Don’t make this same mistake. Listen.
Problems using bleeding edge
But working with bleeding edge software is not always unicorns and butterflies. There’s all sorts of issues. Sure, you feel like a hero when you get something right but 99% of the time you’re absolutely about to blow a gasket because you can’t get it figured out. And it’s not always your fault even! Here’s a few of the common problems I’ve come across working with bleeding edge software.
Most bleeding edge software has terrible documentation
No joke, I know it’s common for engineers and technical circles to make jokes about how much they hate writing documentation. And then there’s the common line, “my code is so clean you don’t need documentation” (I love that one.) So user docs are usually non-existent and technical docs are basic at best. Don’t lose heart. This shouldn’t stop you from pushing ahead - just prepare yourself to become a master of your search engine.
Bleeding edge software changes constantly
I can tell you with authority, almost every single bleeding edge product I have used has experienced changes rapidly. In fact, there have been times that between the time I close my laptop in the wee hours of the morning and when I open it again only a few short hours later the code has changed, the method improved, or the result different. This can be absolutely exasperating. Again, don’t lose heart. The reward is worth the pain.
Okay, I’m going to stop at two, I’ll lose my own desire to keep “fighting the fight” if I continue to list the negatives and the problems. (I’m speaking tongue in cheek of course) So now that we’ve seen a few reasons for bleeding edge and a few problems we might encounter let’s look last at a few tips for working with bleeding edge software.
Tips working with bleeding edge
Working with bleeding edge is both challenging and rewarding. Overcome the challenges and you’ll find deep and visceral satisfaction with your successes. Here’s a few tips to help you.
- Seek out multiple sources for information: If the software has met the criteria listed earlier (not just a shiny object) then you’ll be able to find multiple sources, implementations, and most importantly (at least for me) several different examples.
- Move fast and break things: I recently wrote about the balance between startups and stability. This is one of those cases when you simply must move quick and break things. You’re more than likely working on a local environment, don’t be afraid to try something different. Use proper Git versioning and you can easily roll back changes that don’t work right.
- Be prepared to re-think your thinking: Sometimes you’ll find yourself unable to perform what you expected following your preconceived idea or strategy. Instead of giving up, or forcing a situation. Stop. Re-evaluate. Explore alternative ways to reach the same goal.
- Know when to walk away: Don’t become so entrenched in what you’re attempting to do that you abandon common sense. There will be times when you need to write your work off. Chalk it up to experience (You will have gained knowledge) and move on.
Your takeaway should be simple: Bleeding edge code is exciting and significantly rewarding, but the risks, pitfalls, and failures are inevitable. If you remain self-aware in this regard you will find the adventure very rewarding. (Sounds a bit like a cheap fortune cookie, and I apologize, but the sentiment is genuine.) The last word I’ll leave with you is a simple reminder. Sometimes all you need is a clear head. Get up, take a stroll, let your ideas and your problems soak for a bit, then come back and look at things with fresh eyes. Keep learning. Keep asking questions. I'll leave you with a question: What is something new you're learning now?
