.shock - Fotolia
The network engineer is dead, long live the developer.
While this notion of changing network engineer qualifications has gained traction -- especially with the evolution of software-defined networking -- it is fundamentally flawed. It is too extreme, too final. Here's why.
Since the dawn of modern data network interconnection -- let's call it BA and AA for Before ARPANET and After ARPANET, respectively -- the role of those building links and connecting systems has swung back and forth. They may have begun as industrious computer scientists or engineers who wrote code to represent necessary steps to accomplish desired tasks. Over time, they transformed into specialists that designed, configured and maintained connections from system to system and, eventually, network to network. Only in the last 15 to 20 years has network engineers' work included isolated job functions, and even then their impact has bled into almost every other IT discipline.
Evolution of protocol stack reflects engineers' skillset
Consider something as prosaic as the protocol stack. In the early days, most systems connected via specialty means; among them custom media such as Local Talk, Token Ring, ProNet and Ethernet. On top of those began the communication-building protocols between systems. To get systems onto these networks, the communication networking stack had to be written, and those stacks had to support specific requirements.
By and large, those stacks were likely coded by a network-savvy engineer, based on existing documentation and assistance from the developer community or specific vendor.
And as such, the network engineer's role transformed from computer technician to software developer. Indeed, the modern network engineering profession -- and by extension network engineer qualifications -- is constantly evolving; by its very nature it must.
Yet the evolution of network engineer qualifications is often overlooked by many in the industry today.
Want more proof? Consider the examples above and apply those to how closely the network engineering function correlates to that of a developer:
- Configuring routers requires knowledge of a proprietary language and command structure.
- Understanding protocols means familiarity with each standard's criteria, hierarchy and core competency -- much like knowing programming languages.
- Understanding that different network platforms have distinct uses -- much like different programming techniques and tools have dissimilar core competencies, such as embedded, interpreted and compiled.
There are differences, obviously. The immediate feedback from a VLAN change or route metric adjustment is not the same experience as building a modular application over time. However, coding up a script to change the format of a MAC address is not terribly dissimilar from tagging VLANs through a large enterprise network or renumbering point-to-point segments across a WAN. Each takes time to see the results and requires intimate knowledge of the syntax used to accomplish the task.
Only in the modern age of computing has the dividing line between engineering and programming been this sharply drawn. Moreover, it's a phenomenon largely industry-created, both by frameworks that are meant to compartmentalize employee function and by vendors building ecosystems around syntactic-sensitive certifications.
The network engineer is dead, long live the developer?
By the logic of that statement, all system administrators are defunct in favor of the operating system developer, and the automobile mechanic is rendered obsolete in favor of the driverless car.
Will network engineers be replaced by IT generalists?
Why network pros don't need to become programmers
Developing network engineering SDN skills