At the dawn of computing, the business problems being solved with the help of programmable systems were fairly small and simple and did not involve a large number of computational components. Hence, knowledge of a specific operating system and an associated programming language were tools enough to address the problem at hand. The engineers of that period were more focused on acquiring an in-depth understanding of the business domain. The programming language they used, was only a tool to enable them to build applications that addressed the end-to-end business problem. Their expertise was measured by their ability to work with registers, optimize inner loops, profile code and use cryptic language features. Their level of abstraction was limited to that of the detailed features of the programming language they used. Entire applications were built using a single programming language like COBOL, C or C++ and this was the age of the generalized programmer.
With the emergence of the specialist engineer, individuals started to gain in-depth knowledge in programming languages and the associated frameworks, but slowly started losing focus on the end-to-end business significance. However, the increased productivity and depth of expertise of the componentized approach to development far outweighed the loss of focus on the end-to-end business significance of the solution.
Shortly after this, the application development lifecycle started to move from the then traditional waterfall development approach towards the newer agile development methodology. Stakeholders started to favor the iterative nature of the agile development model and the ability to implement corrective actions with shorter turn-around times. This also provided immense flexibility to the stakeholders to introduce change with minimum impact to the overall progress or roadmap. However, this introduced the challenge of frequent integration between the various components being developed by the specialists within the agile sprint. The logical solution to this problem of frequent integration would have been to avoid the need for constant handovers between different individuals developing the components. Enter the era of the full-stack engineer.
As technology started to evolve at a lightning pace, the need for engineers who could take ownership of the functional features and build solutions end-to-end became the need of the hour. These engineers would fundamentally work along with the product owners and understand the business significance of the problem domain and craft solutions using technologies that are relevant to that domain. They would typically possess the skill to learn, unlearn and relearn programming languages and frameworks in an agile manner, consistent with the business need. With DevOps becoming more mainstream, these engineers would also need to understand the operational landscape of the solution they were building. This would mean, that they would not only be involved in creating the solution, but also be proficient in deploying the solution to its intended production environments.
Going forward, as full-stack becomes the flavor of the day, specialization will tend to move more towards technology stacks and further away from programming languages and frameworks. Engineers will begin to reskill and realign to such technology stacks as niche technology specialization loses relevance. The future of information technology may no longer be driven by Java and .Net specialists, but rather by mobile, web, cloud, big-data and IoT full-stack engineers. Despite the amount of effort taken to transition from the current format of skill acquisition to the full-stack format, organizations should make a concerted effort to move to the full-stack format as it is bound to deliver richer dividends to all; the individual, the organization and their customers.