Based losely on a series of tweets I made last year.
10. Documentation & planning may not be fun but they can be the difference between being promoted & being fired.
It's easy in support and operations to get sucked into the mantra that documentation doesn't matter, or more likely, that yes it does matter but not as much as getting things done.Documentation is part of getting things done. Making and using documentation is a vital part of being an IT Professional, as opposed to being someone who is good with computers.
Ideally you should have several sets of documentation that are useful on different occasions, e.g.
- A service catalogue - this helps define service boundaries as per Limoncelli's three empowering principles.
- Special events such as DR operations, datacentre full shutdown and cold start-up processes.
- Backups - hopefully I don't need to explain why keeping notes of how these work is important.
- Change Management - this doesn't need to be a big formal ITIL-type thing if you don't want it to be, but it's a good idea to track any major changes to your systems, consider the impact of a change, and always have options for "roll-back".
- Procedural guides for carrying out complex operations in a consistent manner.
9. Keep it simple: "less complex" is always more robust and reliable that "more complex".
This applies to us IT Operations types just as well as it does developers. The best solution is nearly always the simplest one that solves the problem completely. This isn't always the case but it is true often enough to make a good default design principle.Failing to respect this can often prove to be an exercise in futility.
8. Your time has value. Remember that when deciding whether to buy a $500 utility or spend 10 hrs coding your own.
This isn't a comment on open source but rather on people. Anyone who thinks a project can be implemented at zero cost because the software is open source or it's a product you already have licences for is either proposing that people work for free or is getting divide by zero errors.7. Never forget the big picture, or your place in it.
It's very easy to get caught up in the details of the technical issue you're battling with, but always keep sight of what your technical achievements mean to the business. Make sure your priorities align with those of the business.I know this one seems especially obvious but lots of IT people seem to have a problem with seeing the business needs ahead of their wish to build the perfect network. The tail must never be allowed to wag the dog.
6. IT is a science, not a religion. Your users and your managers do not know this. Don't tell them, SHOW them.
I've already blogged about this but to turn it around slightly back on to us as a profession, we need to communicate better if we want people to have an understanding of what we can and can not do for them.