System Admin for the Software Developer

When I first joined the workforce some twenty plus years ago, I wanted to be a systems administrator, or sysadmin as it has come to be aptly called. I had tinkered with our family PC for years, taking it apart, meeting with BBS admins buying their old RAM - it was glorious.

Definition (source: Wikipedia)

A system administrator, or sysadmin, is a person who is responsible for the upkeep, configuration, and reliable operation of computer systems; especially multi-user computers, such as servers.

The first company I worked for gave me the opportunity to work with the on site principal systems administrator on my own time. I learned a lot, and after about a year was transferred from the help desk to his “team,” consisting of me.

Quickly afterwards the company decided that a particular problem required a software solution, and fortunately the full-time teams were busy on larger projects. I proposed a simple solution and was given the go ahead to implement. I ended up struggling a bit, but eventually created a web page that simply took a few fields of information in and emailed it to the help desk. It was a huge improvement in the company workflow and drastically reduced the daily phone calls received. It did not take long for me to realize that software was really my passion, but the hardware side of our shared technology house always remained compelling to me.  

I consider the time spent working with hardware, debugging network issues, and helping people with their “slow” PC’s to be an important part of my career and a critical foundation to my skill set. The system admin foundation is even something that I regularly still lean on to this day when developing software. The experience has built an empathy in me that has helped over the years when working with my technology brethren on the infrastructure side of the house. Far too often problems roll down hill and the IT department is at that bottom of that hill but by understanding how core infrastructure works, I have been able to often debug my own issues saving a lot of time as well as hassle by the IT teams. When I do need system admin support, I can often explain in better detail what I already investigated and why, often saving everyone a lot of time. We all get irritated when a customer complains about a problem but little detail is provided, and it is even more frustrating when the software team blames infrastructure in a similar way. 

So, what can be done? If you are able to do so, setting up cross-training sessions between software and infrastructure can be invaluable. For large enough teams, I would even advocate a 3-6 month stint working for the infrastructure team. IT is likely writing some type of software for themselves, and it would be a great opportunity to help build those internal systems, while at the same time learning about what those systems are and how they work. 

Obviously, the cloud has changed the infrastructure game quite a bit. However, the underlying concepts are still the same. I recently spent almost a whole day trying to figure out why my code would always report an unsecured connection when the infrastructure told me that only secure connection was allowed. For those curious, even if you do not put a load balancer in front of your AppService, Azure does it for you. This can get reported as an unsecured connection in some edge cases by the development framework, which I happened to be in. It could have been very easy for me to complain that the DevOps/IT teams misconfigured the network, and forced them to waste cycles proving otherwise.

I am a tinkerer, software engineer and architect, and as the sysadmin role is where I cut my teeth in tech, I wanted to share my experience and passion for the role and value of the position.