20 posts tagged with "career"

I only heard of DevOps maybe just over a year ago.

My career has always been about knowing how the whole system hung together as a whole. So I would know a little bit about everything. Hardware, software, networks, operating systems etc.

Getting to know each area was essentially also getting to know the people who operate those areas. You would get to know developers, and how they thought. Some thinking you agreed with. Some you'd already seen in other useless or lazy workers so it's no different for them.

Balance is good. Balance is also a myth.

The Myth​

You need to work.

More than just to pay the bills, you need fulfilling work. There's a healthy amount of blogs out there explaining why the work needs to be fulfilling, but I'd like to just look at work as the thing you do during your day.

Life. That's the thing you do when you're not doing work.

So we're clear. On one side you have work. On the other is "life" (no in speech bubbles so you know I don't mean living and breathing).

Now you might be saying "no duh", because you'll see a version of this very notion every which way but loose.

But the idea of getting from A to a B you never think you'll get to, through being patient and sticking at it, is one that resonates very personally for me.

You work for a company. It's a business. It's trying to make money.

And that's fine.

You are trading your time for money.

That's also fine.

The contract will spell out what the expectations are, the conditions, the rates.

And then you conduct yourself as professionally as humanly possible. Within the parameters you've agreed to...

With all this crazy technology around working as a devops engineer it's easy to get caught up designing and building something really complex that does a lot of stuff.

Sometimes it's the demands of the job that means you created something that did one thing. Added something else to it. And before you knew it, the "thing" has become a complicated behemoth that's now critical to the operation of the company (true story, I've seen "hacks" become 'the infrastructure').

One thing I used to see a lot of when I was a permanent employee, and experience myself, was the pressure to deliver some pretty crazy project requirements in a short amount of time and the stress management that needs to happen alongside it.

By "time", I mean the 40 hours a week you are paid for. This lead to people working some crazy extra (read "free") hours worked to deliver things. I put free in quote marks because while the project and the company might think they got a massive amount of work for half price. But there is always a cost to anything, it's just not always money up front.

"Dumbest" is probably a harsh way of putting it.

But I knew I was the least experienced and had the smaller skill-set in a team of battle hardened and really skilled Engineers.

I.T. attracts some very smart people and I talk about this in my last post. And sure that doesn't always equal good things. But if you have been fortunate, like me, to end up in a team surrounded by knowledgeable and helpful Engineers (notice I didn't say "friendly"), you learn.

A lot.

Here are some of the key things I learned being the dumbest guy on the team.

Having worked in I.T. for over a decade, in my experience ego is very much part of the technology landscape. I've had the privilege of working with and learning from some really smart people.Unchecked egos and badly managed expectations create a hostile workplaces people who could knew the ins and outs of obscure Unix systems and could work out IP ranges with a subnet mask or slash notation (I still suck at this).

If you work in an office, especially in I.T., a big part of your day is problem solving and trying to do some "deep work".

You don't need a study or a statistic to know that there are an ungodly amount of interruptions that take place in your average work day. But here's an excerpt from a study anyway:

Nothing achieves getting less productivity out of your workplace like being constantly interrupted by emails, instant messaging, phone calls or the (not all the time) dreaded "shoulder tap".

But it's a 2 minute question, you can just get back to it straight away right?

Understandably Morpheus had a bleak outlook on Systems, but it doesn't have to be our enemy.

There have been many titles for this role. From IT Engineer, Systems Engineer, Systems Integration Engineer to more recently the lauded ‘DevOps Engineer’. And current reading (for myself anyway) has introduced me to the the title ‘Site Reliability Engineer’ or SRE.

Whatever the titles are or have been this post will discuss what being a Systems Engineer has been in my experience and from the point of view of my career in Information Technology.