The web as we know it is changing. The technologies, the software that they power and the talented minds that write them have all been experiencing a dramatic shift in the past few years.
This shift didn’t start accidentally. We certainly did this to ourselves. The human condition to want things faster, more engaging, and flashy has pushed web technology further than we ever thought possible in its humble beginnings. In fact, I can trace it back to the one day that brought us to where we are.
It was a mild spring day: May 27, 2009. The economy had just taken one of the worst hits since the gas shortage of the 1970s. Nobody was in a particularly good mood to begin with when an unassuming repo on Github pushed a commit that said, “Major refactoring: program name now "node."
Soon after, technical debt began to skyrocket with a little program called node package manager (NPM), which allowed developers to load libraries of code into their websites and deploy it all via a few simple commands on the terminal.
This was also the start of something even more interesting. From here on out, the scope of a front-end developer (FED)’s job exponentially changed and expanded.
To illustrate, this is what I typically think of when it comes to the division of labor from ten years ago:
|HTML||CMS setup||Initial design|
|CSS||Hooking CMS into static||Desktop mockup|
|Front-end architecture||Templates||Mobile mockup (maybe)|
|UX decisions (partially)||Form/interaction||UX decisions (partially)|
This chasm that has been created not only puts veteran front-end developers at a loss but blurs the line as to what is to be expected when in the job market for everyone. It’s typical for a FED to be asked to know HTML, CSS, React, redux, webpack, and deployment standards as well as current design and UX trends—not to mention the array of database architecture we are expected to know. At this point, many front-end developers are expected to be able to create a website from the ground up with little-to-no support from other departments.
We’re getting to the point in this website-building paradigm shift where we need to take some responsibility in what types of demands we put on our developers. More specifically, we need to figure out our expectations of their roles when we hire them, as well as how we compose our project teams.
Companies, decide on a tech-stack and stick with it. If you hire developers to fill those ranks, focus on the technology that you are using, or intending to use in the future. When writing job descriptions, ask your current dev team what is missing instead of listing the top 10 frameworks in the market. You will get a much better fit for the needs of the team with fewer surprises down the road.
And remember, code is cheap—developers don’t get paid by the line. Having a great problem solver, no matter the proficiency level, will trump having an average developer any day of the week.
- © 2019 Connective DX
- All Rights Reserved