The Front-End Developer, Full-Stack Developer Paradox
Bridging the gap in development
When I first started out developing enterprise applications nearly 25 years ago, UI, for the most part, was just a simple way of getting the data into a system of record. If you were writing a desktop application, you would use your choice of language (such as Java, C++, COBOL) and use its UI code to make your application. For mainframes and enterprise applications you would have an even smaller list of choices. We did not have titles or the need to define a front-end developer vs. a full-stack developer. Everyone was just a developer.
I might argue that this was a peaceful time for most developers and initially, the beginning of the internet did not change most developers’ workflow. HTML was just a markup at the time and was mainly just a way of sharing content.
The first change to this workflow came in the early 2000’s when companies started to design beautiful websites with many, or large, images (Almost everything at this time was some image including an anchor link). The reason this first technology shift was significant was that many companies started using large marketing companies or internal teams to design and create these web pages.
No longer were hardcore developers creating UI, it was now in the hands of creative teams. These first websites typically did not contain much in the way of functionally other than to deliver content to the user. However, with the advent of Ecma Script, websites started to act and behave more like the applications developers had previously been building.
Websites-behaving-as-applications is the start of the divide between the two types of developers working on web applications. Moreover, this was the start of the desire to define front-end developers from back-end or full-stack developers.
Front-end developers saw themselves as only working with HTML, images, and documents they were using for visual context. Back-end developers only worked on the database, API’s, business logic, and the closest they got to visualization of the data was generating reports.
In the new paradigm, a designer could create a web-based design using some tools like Fireworks or Illustrator and a web server. This paradigm was very successful for content-driven websites. It also had a very low-cost entry point for new developers to get their feet wet.
However, it created a paradox for teams and developers interested in front-end development…
Even in large corporations, most software teams are a small group of individuals working on a single project. In fact, if your team is using Agile process, then this is all but mandated. These small teams are set up with only enough people to get specific amounts of work done in two or three weeks bursts. If you are a hiring manager, then you must look out for the whole development process, which means knowing what to do if developers are going on vacation or are out sick.
What is the best way for developers to complete the sprint and also give support for the application if their teammates are out? For managers, often the best way to handle this is to hire developers that can do development on the whole technology stack.
According to this logic, full-stack developers give managers the most options for the development process. A full-stack developer can own a feature from front to back. A full-stack developer can be rotated on and off product support if they know all the moving pieces of an application.
However, by hiring only full-stack developers you may get a team of “jack of all trades, master of none” developers. There is more to UI and UX then just creating forms or a list view for a report. A useful and engaging website must include animations, thoughtful flows, intuitive buttons, and other characteristics. Not all full-stack developers have the knowledge or expertise for a winning front-end and hiring managers have to weigh how much expertise they need in front-end development to make a product successful.
How can we avoid this paradox? There are things everyone in the tech community can do to help narrow the gap.
- Front-end Developers — Be more open to learning other languages beyond JavaScript, HTML, and CSS. Back-end developers have been doing this for years since it is a constant change on the backend, from Servlets only to Spring and all things in between. We’re happy to share our experiences with this. Learning how to write in the backend of choice can help front-end developers be a more well-rounded, and in the end be more marketable for new jobs and roles.
- All Developers- Make the argument to your bosses that they should start using something like NodeJS for development. A different tech stack for the backend can be beneficial to all kinds of developers and the company. It gives the company more flexibility to meet the needs of the market and gives them the ability to hire developers with more diverse skillsets.
- Employers — Can also do things to narrow the gap and lessen the paradox. One thing would be training for developers on both frontend UI and UX. I would argue this training should be more than take a class and consider it done. Sending your developers to conferences, group watching parties of videos on UX, set up a mentoring program, and general continual education on front-end development is needed to keep your team and their skillset updated.
- Hiring Managers — Look for developers that show a thirst for new knowledge (you’re probably doing this anyway). Developers that are continually learning new things are more apt to take up the frontend and run with it or dig into learning new languages used on the backend.
We can all work harder to undo the paradox between full-stack and front-end development and the impact it has on our teams and projects. Everyone in our technology community has a role to play in narrowing the divide. The result of this work will be better websites and apps, stronger teams, and more well-rounded developers.