If you're a software engineer of any form - developer, tester, support engineer, or any variation thereon - you should know your tools. That's pretty basic. Java engineers probably ought to be able to compile something, and to know what a library is, and how to set up a class. It's reasonable to expect that Rails testers can describe the difference between factories and fixtures, and when each is useful. We spend time training support engineers in our tools and procedures specifically so they'll know how to use available tools effectively. Pretty basic, right?
But software does not live alone. It's been decades since the software we wrote was the only thing involved with running our program. Our software runs in an environment, complete with operating system, other programs, drivers, hardware, third-party dependencies, etc.
Shouldn't we know our environment?
Some of the problems we solve in our software are related to the environment. We have to handle the case in which our logging can't write because the disk is full. Or we have to test for what happens when our software and some other piece of software both try to use the webcam simultaneously. Or we discover that the hang in our software is actually the user's browser crashing for some unrelated reason.
Just like we use tools to create software, we use the environment to create software. We use disk space, or the webcam (and its drivers), or the browser (another piece of software). So just like we need to learn our tools, we need to learn our environment. We need to make ourselves into baby sysadmins.
We don't need to know how to do every sysadmin task, but there are some basic things that we should know:
- How to view what processes are running and basic information (status, memory and CPU utilization)
- Where to look for indications of hardware problems
- How to view network information and utilization
- How the operating system handles disk usage and I/0
- Where the operating system or virtual machine (e.g., JVM) logs and how
- What environment variables are required and how they might be set - both by our software and by external software
- What limits are implied by libraries (e.g., 32-bit versus 64-bit software)
- Roughly how the operating system works, including dependency management
- Roughly how any containers - JVMs or browsers - work, including loading order and frequency, and other dependency management
None of these things are particularly difficult, and they're all directly related to how your software behaves in its environment. So go ahead, embrace your inner baby sysadmin.