About Aaron Nichols

Aaron works with startups and small companies to help their development organizations move faster. He is presently the senior Operations Engineer at a startup in Boulder working on implementation of Continuous Deployment, automated monitoring & configuration management.

Why I Infracode

I’ve been involved in, and observed, some recent conversations which have me thinking about why I do what I do. Also, what exactly is it that I do? I was having a discussion about why I enjoy working in the areas I do – which I typically describe as:

  • Config management & Deploy automation
  • Monitoring infra & app integration
  • CI / Build infrastructure

I mentioned that I don’t typically contribute to product features, preferring to focus in these areas. When asked why that was, my first response was – “I suck at algorithms and I never went to school” – both true but inaccurate explanations for why I got where I am. Neither of those things really hold me back from building or contributing to a product. It also doesn’t describe why I’m passionate about what I do.

I’ve never been one to choose to do something because I can’t do what I really want to do. Well, except that if I could jump out of airplanes all day I’d probably do that – totally awesome fun. Instead I rock climb.

I love writing code. I love putting together bits and pieces and building something useful – I’m terrible at finishing coding books because without a practical problem to solve, the incentive just isn’t there. I also get bored pretty quickly. For me, having a stack of things to do is optimal – I move one to the point where I’m blocked and move to something new, I like to focus for periods of time, but then have to switch gears. Occasionally I’ll find something that really gets my attention and it’s like the worst video game addiction – my kids notice, my wife notices, nothing else gets done. That’s rare for me and I am horrible at handling those things other than to just knock it out and get done.

Managing this shifting of priorities & still getting things done is a skill I’ve worked hard to get right. At this point I’m pretty good at it, and struggle working any other way.

Operations has been this for me. In most organizations Ops are the ultimate generalists, both using their own experience to solve problems as well as being adept at engaging other domain experts. We know where the right folks hang out on IRC, we know when to call support and when to just dig in, we learn quickly and are super resourceful. We are exceptionally familiar with the tough problem cycle – initial interest, fear that this is too big, despair that you aren’t going to solve it, the glimmer of hope leading to resolution and awesomeness. I have another post brewing on that specific topic. This isn’t exclusive to Ops, but it’s something you get very used to.

Wait, wasn’t this post about Infracoding?

Yes, the only reason I’m still doing Ops work is because I get to write code. If you were to offer me an Ops job where all I did all day was figure out tough problems for other people to code solutions, I’d tell you to suck it. If you suggest that I can pair with a developer and we can fix it together, I’m happier. If I can get proficient enough to code my own solutions and have other people tell me how to improve what I did, I’d sign up. It’s for this reason that I love the pull request model. I’ve learned from both Sr and Jr team members through PR feedback and it’s a great way for folks to watch and observe what feedback others get.

But along with writing code I get to do other stuff too. Helping to debug strange inconsistencies between monitoring systems – without the ability to code I wouldn’t be able to write the small tools that make testing theories easier. Packaging up and deploying infrastructure, more opportunities to build tooling. Make it easier for Developers to provision their workstations, more coding, more variety. Building networks these days is often pretty limited if you aren’t willing to write code. I know many Ops folks have been doing this for a while, but more and more the % of time an Ops guy spends writing code is increasing, not decreasing. This isn’t universally true, but it’s true of work I am interested in calling Ops.

All along the way, as I get more proficient with coding, as I have become more familiar with patterns you see in production, I can work with developers more closely to help them build better systems. Where developers can definitely get exposed to these same patterns, Ops is pretty directly involved with how things operate in the real world. We get to pull together the resources to make things work and we get to learn in the process. This is the more traditional part of Ops for me, being the guy who helps developers understand the realities of production. But more and more that knowledge gap is closing and Ops are as much an Engineering team as the UI team is. Availability and Agility are features of your product, you have to engineer them in and that requires Developer awareness that is on par with Ops.

Alright Aaron, so what’s your point?

I don’t do feature work because frankly, it seems too focused for me, too specific. Within the Ops role I can go as deep into code as I want but then surface to work on many other things. If I want to go deep on something, there are a bazillion tools out there I can (and sometimes do) contribute to, I can build my own, or not. I get to work with the sharp edges of many tools and find ways to wrap Nerf bits around them. I get to choose when good enough is the enemy of perfection or when perfection is, in fact, the enemy.

I love Ops and every day that role moves closer and closer to awesomeness for me. Although I generally say I don’t know what I want to be when I grow up, I’m pretty sure it’ll look a lot like Ops.
 

Reference: Why I Infracode from our JCG partner Aaron Nichols at the Operation Bootstrap blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


7 − = one



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close