The short: to save people time as they travel the weary road of googling
The long: Although there are a lot of important things to know in IT and technology — e.g. best practices, methodology, trends, standard practice, core mechanics, etc — there is a lot of tedious stuff too. And, to borrow a cliche, it’s increasingly where to find information rather than simply what. I hope to add some decent documentation — and hopefully not too much bad — to the internet. Because, the real sin in IT is wasted time. If I bled and sweat for the solutions, maybe the next poor guy can bleed a little less.
Currently, I’m a DevOps engineer.
I’d argue that DevOps should bring the consistency and foresight of operations with the agility and “code defined” nature of development.
This is why CI, Deployments, builds, etc tend to be the focal point. It’s not that build servers and scripted deployments didn’t exist before — but there’s a renewed focus on such things (plus some buzzwording).
For me, DevOps means having enough expertise to implement robust solutions and remove the fear out of doing things by doing them over and over and over again (hopefully in better ways) until things like a deploy to production don’t fill your team with fear. I want people to not panic when they have to diagnose because we’re logging an apropos amount of information in an easily digested format.
Really, to me, DevOps is bringing law and order to the cowboy coder world while not being as ultra conservative as a traditional operations person namely due to the fact your focus is (hopefully) very specialized.
I was systems administrator by trade. I’ve worked (briefly) as a forensic analyst as well. Insofar IT, I’ve taken a shine to Powershell in Windows environments and believe very much in automation and self-service. Internally, documentation is absurdly important and is the real crux of the “streamlined process” buzzword that gets thrown around.
I believe in parameters and constraints. IT isn’t magic, and every system has its limitations / advantages. There really is no copy-pasta solution — despite best practices. At the end of the day, true service is about fulfilling those parameters set-forth by the business — sometimes, even beyond what a particular person says they want. Some in IT believe in being yes-men and others believe in shoving the “best” system down peoples’ throats. In reality, half our job is figuring out what people need and then what they want.
Under that purview, I believe very much in transparency and consistency. Although stringently and blindly abiding by rules is never good, IT as a department needs to stand resolute as a cohesive whole. If a process or policy needs to be changed, then all those it affects should come together in open dialogue to discuss it.
Otherwise, outside of the “40 hour work week”, I enjoy: gaming, beer, scotch, cooking, reading, and plotting various coups.