I’ve been a software engineer for over 25 years. Over that time, there has been a pendulum in the industry that swings between demand for developers as specialists or generalists. As new architectures, development methodologies, and organizational structures emerge, development teams need specialists. As technologies and methodologies become assimilated, developers need to adapt and incorporate new skills as generalists.
Going back to the 1990s, there was desktop software for the PC boom. In those days, businesses were hiring specialists in Windows, OS/2 and Mac. Client/server was the next revolution. Networks were getting more prevalent and faster. Companies wanted to manage data and storage centrally but make use of the great interfaces that could be built on Windows and Mac. Here again we used specialists for both the client and server.
Then N-tier architectures for web-based applications became the hot new thing. Instead of desktop GUIs, companies wanted to take advantage of the cross-platform capabilities of the new web UIs. First there was HTML, then scripting with VB Script and JavaScript. Later, DHTML and Web 2.0 (AJAX) became state of the art. As companies started to have a real web presence and SaaS became more prevalent, the need for operational specialists grew as well.
Now single page apps (SPAs) with highly responsive UIs and slick interfaces reign supreme. This quick technological revolution requires people who maintain their skills with ever-evolving standards and languages, such as JavaScript, HTML, and CSS. On the server side of things, companies still need people with expertise in business logic and database.
Today, most companies are looking for generalists who can do it all – what is termed the full stack engineer. These developers work on web applications and can operate in any vertical tier of the application. They write HTML, CSS, and JavaScript for highly performant and functional UI for the front end. They can also work from the server side to develop the business logic to support the UI. Behind that are the database schema and queries used to move data in and out of the application.
The Shift to Agile and DevOps
The swing back to generalists is evident in the shift to Agile and DevOps. Back in the day it was not uncommon to have 50+ person teams building applications using the Waterfall methodology. From a technology perspective, development was kept in silos for each specialty. It was uncommon for a developer to straddle specialties such as development and quality assurance.
When the Agile methodology became prevalent, we saw the teams of 50 reduced to teams of 6-12. More and more, developers were expected to write unit tests for their software, and there was also a rise in test driven development or TDD. Quality was becoming a skill that developers needed to do their job. Quality engineers also started to code and automate some of their testing, further blurring the lines between developers and QA.
From a technology standpoint, developers started to do more work across the tiers. This was driven by two factors. The first was the reduced team size of an Agile team. Less people meant less room for specialists and less time for handoffs. The second was the need for speedy delivery of software to the customer that was part and parcel of the benefits of Agile development.
Enter the Full Spectrum Engineer
DevOps has ushered in a new trend. Teams are moving from batched releases of functionality to single-piece flow. In other words, we no longer think about collecting the work of multiple engineers over multiple sprints into a release. Our ability to bring value to the customer as soon as possible and out-innovate the competition is driven by releasing the work of a single engineer as soon as it is ready. This will typically be accomplished through a CI/CD pipeline directly from the source repository through all manner of automated testing, and finally deployment into production.
What does this mean for the individual developer? Plenty. In the next blog post in this series, I examine the major capabilities software engineers need to thrive as full spectrum engineers.
