Recently, I helped spearhead our department’s adoption of centralized static code analysis. I worked with one of our mobile engineers to research various tools and create a decision matrix for comparing options. I’ve introduced new tools to my team before, but this was my first time selecting a tool that would be rolled out and used by my entire engineering department. It was also our department’s first time trying centralized static code analysis.
Imagine this scenario: you want to build a new house, so you hire two people: an architect to design the structure and all the plumbing and wiring and the like, and an interior designer to come up with the various features of the rooms, the lighting, the colors, the decor. Six months later, they each hand over their plans...but they haven’t actually spoken to each other the entire time. If you hand those two sets of plans over to a contractor, how likely do you think your house is to be built effectively and efficiently?
Note: This is the second post in a series about the different roles I end up carrying out as a Quality Assurance Engineer. You can check out the first post here, where I talk about wearing my Tester hat!
“MTBLS”: I first encountered this phrase on a New Relic blog. It's a half-joking reference to a concept used by reliability engineers, Mean Time Between Failures (MTBF). I was intrigued though, and thought it would be an interesting metric to track.
We have high-resolution data about our machines' health – down to the smallest minutia – but precious little about the health of our people.
Getting Started with Documentation
I just attended Monitorama 2017 in Portland, and I wanted to talk about my experience! I think it’s useful for me as a brain-dump and reflection about what I took away from the talks, but it’s also nice for other people to have some more insight into what the conference is about.
Ever since I had the privilege of attending DevOps Days Portland, I have been hearing the way people use the word “DevOps” in a whole new way. Most of the time, DevOps is not the word they should be using.