DerbyJS? Never heard of it.
Should a company’s tech stack influence your job hunt?
If you’ve looked up Lever as a prospective employee, you may have discovered a couple of things:
- It’s a great company with rave reviews on Glassdoor, InHerSight and other job platforms
- It’s a mature startup with lots of technical roles to grow into
- It’s built on… DerbyJS??
Hmmm OK so everything looks good, but do you want to deal with learning a new framework?
You are facing the same decision most engineers will need to make at some point in their career. Should you invest your time in learning a technology which you can’t take directly into your next role?
The case against the custom framework
I have made this argument myself many times. Custom, unknown or bleeding edge frameworks all carry a certain amount of risk and uncertainty.
The most compelling is that a well supported framework with a big community will inevitably get more bug fixes, features as well as a larger body of knowledge on platforms like Stack Overflow.
Furthermore, if you have worked for a couple of years as a React, Angular or <insert framework here> engineer, you can probably confidently walk into the next job and ramping up will be easy.
It’s well known within Lever’s engineering teams that new Engaroos take a little while to wrap their heads around the tech stack. For that reason, we make space to learn and explore during your first months.
Be an engineer first, not a <blank>-engineer
You will probably find yourself working in a particular field or community over your career. It makes a lot of sense to specialize, given that you will more easily build confidence and progress faster into the next role.
However, it is possible to specialize yourself into a plateau or a slump. Once you’ve learned everything there is to know about your tech stack, you may find it difficult to switch to something else because of fear of the unknown or not wanting to “throw away” the knowledge you’ve already gained.
But experience and certain skillsets transcends technologies and will always remain useful down the road.
There is a big difference between ten years of experience working with different technologies, companies or disciplines and ten years doing the same thing. Companies benefit more from someone who’s seen a lot of different approaches and can identify good and bad ones.
Nothing is created in a vacuum
Switching between languages and frameworks never truly means forgetting everything you know and starting over. Many of these frameworks, DerbyJS included, were created around the same time and were born from the same collective subconscious.
The underlying principles are often related and familiar once you’ve learned one. For example, both React and Derby have Components, reusable bits and pieces used to create applications represented as visual markup and code. They each contain HTML markup with placeholders for properties. They each have a lifecycle which can be hooked into at various stages. Though their individual usage and implementations differ, the foundational ideas are transferable.
Similarities between frameworks can muddy the waters for new engineers learning the ropes, but it is mostly beneficial to be able to equate a concept in a new framework to a concept that is already familiar. The conversation usually goes: “This is sort of like that, except for these parts, which we do here instead.”
As Terry, one of our Toronto Engaroos who previously worked with React put it, “I almost didn’t want to apply to Lever because of it, but did anyway. I ended up nerding out during my interview about it. It actually had a lot of interesting similarities to react. Reactive methods duh! Another thing is because it’s niche, it means that there is plenty of opportunity to grow it, which I think is very appealing”
Custom can be a good thing
When a product is built against a largely controlled and stable framework, it is protected against fluctuating trends. It happens from time to time that a framework goes through major versions, which can disrupt teams when they need to fundamentally rewrite their software in order to keep up. Similarly, as a once popular technology falls out of favour, it my become increasingly difficult to support it.
That being said, the only way a custom framework can work effectively is when the company is willing to invest money into it. If there is no community support, the support must come from within the team. Those team members should have enough resources to work on maintaining the framework, fix bugs and build the features the other engineers need to create a beautiful product.
The future of DerbyJS
As a new member of the framework team at Lever supporting DerbyJS and its related open source dependencies, I’m excited to see this level of investment and to discover what the future holds for us.
Of course the framework is only a small part of Lever’s tech stack. If you are interested in learning more about our other technologies, we have another post that takes a deep dive into everything Lever was built on, including more information on how and why DerbyJS was created.
If you are interested in a career at Lever, take a look at our careers page.
