Rise of the Stack Developer History

 System Admin - 2002
Stack Developer - 2019

System Administration, Configuration Management, Build Engineer, and DevOps many of the same responsibilities but over the years the names have changed. Listen as Darren Pulsipher gives a brief history of his journey through the software and product development over the last four decades and how so much has changed and much has remained the same.

Darren’s History

• Started as a Software Programmer
• Had Linux and Unix Experience
  • Tell Story of Mimi Larson getting me an AT&T Unix box and a manual in 1985
  • Worked as a System Administrator in College (AIX, HPUX, VMS, SunOS, Solaris, Xwindows)
• Always designated as the software developer that would do the build at night.
• Learned about SCCS and the newer RCS at my first job.
• Quickly become the configuration management grunt.
• Changes in Version Control Systems and Build systems began to collide with each other.
• Client-Server tools arose and started being spread across multiple machines. The rise of the Concurrent Version System. (CVS and tools like ClearCase)
• For you young bucks you have probably heard of ClearCase, but it was my money tree for about 10 years. The black art of ClearCase administration was my sweet spot.
• ClearCase really brought build and configuration management together with build avoidance and management of derived objects and binaries for the first time.
• Then can truly distributed, de-centralized, simplified tools like git, mercurial. Convention over configurability made these tools easier to use and the Configuration Management engineering job shifted again. Focused on more build systems and Continuous Integration and Delivery.
• The DevOps Engineer was born.
• As development cycles decreased and build cycle times when from days to hours to minutes. Development teams took a more dynamic and Release-break-fix mentality.
• Now with microservices, containers and serverless, a new role is starting to emerge.
• The Stack Developer.
  • develop new stacks of services across multiple environments (Local, Dev, Build, Test, and Production)
  • These stacks can be made of multiple services and microservices.
  • Talk about a stack being different in the different environments.
  • Simple Mean stack first.
    • Local. One mongo instance, One nodejs worker node
    • Dev. One Mongo Instance, Multiple NodeJS worker nodes.
    • Build. Build environment might be completely different.
    • Test. Multiple instances of the same product with additional services for performance testing, logging, debug turned on, etc..
    • Production. Backup, Fault tolerance, etc…
  • Creating these re-usable stack gives developers the ability to develop applications and not worry about system administration tasks.