Saturday, October 1, 2011

"What Do You Do, Anyway?"

I get asked this quite a lot. What do I do? What value do I bring to a company? When asked, my answer is frequently "The impossible." I say this with a smile, and then explain "I do the stuff that everybody else says is too hard to do, can't be done, etc." and then go on to list some examples. If you want to see them, go check out my resume, and look at the projects at the bottom.

This answer, though, is very unsatisfying. It sounds like I'm bragging. It sounds like I'm saying I'm better than everybody else. It sounds, well ... it sounds arrogant. Since I'm on the job hunt now, I really shouldn't say this, but it needs to be said: I'm not that great, nor am I that special. I'm just a guy who happens to be passionate about his career, and doesn't shy away from some aspect simply because it doesn't fit with what I normally do.

This results in me doing such a variety of things that simply calling me by any one label is quite unrealistic.

Am I a system administrator? Yes, absolutely. I take care of systems. I maintain servers. I upgrade them, install software on them, troubleshoot problems (both hardware and software), and keep them running smoothly so that people don't get the chance to realize that problems happen. Yes, I'm a system administrator.

Am I a developer? Again, absolutely, yes. I write software. I design software programs on both large and small scale. I debug software. I profile and optimize. I analyze the libraries that are in use, and recommend upgrades and changes when appropriate. I perform testing of the software that I write. I work in whatever programming language (C, Java, Perl, Python, Javascript, etc) that is needed for the job. I work in whatever programming paradigm (procedural, object oriented, functional (my weakest one)) that is needed to solve the problem. Yes, I'm a developer.

How about a software tester, am I one of those? I devise plans for testing the entire program. Sometimes those can be automated, and I do so. Other times, they cannot, so I devise a manual plan for checking to make sure everything is working. When the software is being prepared for release, I execute those plans and verify that everything is functioning as expected. Yes, I'm a software tester.

The list goes on and on. I do some network administration, some configuration management, some release management, some build management, and frequently find myself solving problems that cross the boundaries between two of those functions.

This will seem irrelevant, but I promise it all ties together: this year, I finally truly understood the phrase "The buck stops here". We've all heard it. It's famous, and we can thank Truman for that. What we've missed, though, is what it means. If you adopt that phrase as your personal motto, it means no more passing the buck. Whatever comes across your desk is now your problem. It doesn't belong to anybody else: You must solve it. This year, when I took on my new job, that phrase came to mind, and I realized that I was entering a position where the buck stops with me. It's terrifying and invigorating at the same time.

Now, in recent times, I've begun identifying myself as an "IT Generalist". I do so many different things, and wear so many different hats, that labeling myself by any one title felt wrong. As the IT Generalist, the problems belong to me. My job is to turn problems into solved things that people say "Remember when that was so badly broken? Yeah, I'm glad we don't do it that way anymore." The buck stops here, with me.

And then we come to today, and the bit of reading I did that sparked this post. Browsing slashdot (yes, I read it, I still find it useful), I came across a post which mentioned the "Cult of DevOps". Digging in a bit, I read about it on Wikipedia, and found something that resonated with me. I understand the ideas, because I'm already living them.

It also seems too "insular", though.  The reading I've been able to do so far focuses on the idea of internal software development for a company, whereas my personal experience also looks at the outside vendors for a company. When a problem occurs, I identify what's going on. Sometimes, that means reporting it to an outside vendor so they do a proper resolution while I find a workaround that allows my company to finish the work they need to do.

I think I'm going to stick with the "IT Generalist" moniker for a bit longer, but I think I can see myself joining the Devops movement. It strongly resonates with me and how I view my career.

I'm not just a system administrator. I'm not just a developer. I'm not just a software tester, nor just anything else. I'm all of these. I'm a problem solver.

No comments: