Operation Bootstrap

Web Operations, Culture, Security & Startups.

Thanks Seth

| Comments

There are few people I can point to on the Internet and say “you made an impact”. A few have, and countless others have contributed in various ways to the ideas I have today. No other however, has had the impact of Seth Godin. I’m sure you know who he is already, if not then I hope you gain something from this.

I try to read every post – I don’t always manage, and sometimes I read them out of order. Today I read this one. Like so many others, each having its own impact on me, this one made me pause and think “is this what I’m doing?”. Seth puts something out there every day. He always shows up & I always look forward to it.

So I just wanted to say thanks. Thanks for a variety of great books. Thanks for introductions to great people. And thanks for being a daily source of new thoughts.

That is all.

Despite Your Best Efforts, Some People Are Just…

| Comments

… asses.

You should try to be aware of your own faults, try to improve yourself and try to be patient with others. You should try to find ways to be more clear & describe your position so that others can understand it. You should work hard to overcome geographical barriers, differences in culture & background, we’re all different in special ways. You should try to put yourself in other’s positions every chance you get.

But despite your best efforts, some folks are just asses. That will never change. There are folks you just aren’t able to get along with.

Recognize this & don’t bother trying to change them – just try to avoid showing the worst in yourself in the process. Don’t be an ass too.

Find a way, some way, to still be awesome in the eyes of those who matter.

Asking for Permission

| Comments

The decision of whether or not to ask permission comes up a lot in Ops. I’m sure you’ve heard that sometimes it’s better to ask for forgiveness than to ask for permission. As with most things in life, try to put yourself in the other folk’s shoes and ask yourself how pissed you would be if nobody asked your permission. If you are a Honey Badger, skip this step.

Asking permission to make a change, as an example

When it comes to major changes I always communicate the change but I don’t always directly ask for permission – it depends a lot on how much I feel like getting feedback. Sometimes I know what I need to change is the right thing to do and I just want to know if there are gotchas, other times I want to solicit feedback and know if others think there’s a better way.

Two ways of asking that question:

“Hey all, I am planning to shutdown systems a,b & c today. They’ve been removed from service for a week. Let me know if there are any problems this will cause. I’ll be shutting these down at 2pm MDT”

vs. this

“Hey all, I would like to shutdown systems a,b & c – is this ok? I want to make sure everyone agrees with this before I move forward. I’ll bring it up during stand-up as well”

What’s the difference?

The first is saying “I’m doing this, let me know if I’m going to stumble in the process”. It’s not so much asking permission as asking for advice. The second is saying “I’m not going to do this until we all agree”. I generally prefer the first approach when I can get away with it – but often I will use that after I’ve asked about the change using the 2nd approach. It’s important to make others feel like they have an opportunity to say “hang on, I have a question” and provide input – but in some teams it’s also important to not allow habitual questioners to derail something that needs to get done.

On the other hand, don’t just start using the first approach because you always get questions. If you are getting legitimate questions it may be because what you are doing isn’t being communicated well enough or there isn’t consensus on the team about what you are doing. Respect other folks opinions & make sure they have an opportunity to be heard.

The exception, facilitation

When you are diving a meeting the power is a bit different and so is your need to ask permission. When you are driving a meeting, and in particular if you are asking for a team to participate, you need to ask permission. I run a lot of post-mortem type meetings in my current work and in that capacity I’m constantly asking these sorts of questions:

  • Does everyone agree that this is an action we should take?
  • Do we agree with the timeline in this post-mortem, are we missing anything?
  • Is everyone comfortable that we’ve captured all the actions from this event?

And the list goes on… When you are driving any meeting you have a lot of power over the outcome of the meeting, and so you need to weight decisions more toward the team and less toward yourself. As soon as you say “I think we should do…” it becomes much harder for someone else in the room to stand up and say “I disagree”. Despite that, some people still do.

The other exception, ownership

I don’t usually ask “Is everyone ok if I own this?”. If I want to take responsibility for something and own it’s completion I say something like “If nobody else is already working on this I’ll take it, let me know if you are interested in helping”. Ownership doesn’t have to mean you are going to do all the work, but that you are taking responsibility for it getting done. I haven’t found many cases where folks are unwilling to allow someone to own getting something done, but I have found plenty of cases where people want to have input into how it gets done.

Wrap up

So, go forth, ask permission where appropriate, and ship it.

Don’t Forget, Make More Awesome

| Comments

I was just thinking this morning about what I was going to do today and what I wasn’t going to do. I was reminded of Jesse Robbins awesome talk on DevOps culture and his statement “don’t fight stupid, make more awesome”. That’s the plan for today and it embodies both what I’m going to do, and what I’m not going to do.

Sometimes you have to pull folks kicking and screaming into the future – but often you have to show it to them before they understand it (and sometimes they still don’t).

My Favorite Shell Shortcuts

| Comments

I love shortcuts. I do my best to learn keyboard shortcuts, I setup aliases, and I like using anything that makes things faster. Here are a few of my favorites for a shell in Linux or OS X. These aren’t ninja shell moves that folks who’ve been doing this for a while will not know – these are basic shortcuts that everyone should know.

1) !$

I use this shortcut every single day when working in bash or zsh. This takes the last argument of the previous command and uses it wherever this variable is used. Here is an example:

Copy a file & then edit the new file.

$ cp file-a file-b
$ vim !$

If you are a zsh user you can take this one further and reference specific elements of the previous command using !!whereis the element you want to reference:

~/> touch this that the other thing
~/> ls !!2
~/> ls that
that

The indexes start with 1.

2) grep -ri

I’m sure a bunch of you are thinking “Seriously?” and I would have too until a week or so ago when I watched someone type this:

$ grep */*/*/*

I asked what the hell they were doing, they said they were checking the files under each directory (they kept adding asterisks for each level). This person wasn’t Jr, but was used to other operating systems that didn’t have a recurse option. Modern operating systems with any respectable utility have a -r (recurse) option, you should use it.

The -i argument makes it case insensitive.

3) cd –

This will take you back to the directory you were in previously. There are lots of other tricks with ‘cd’ but this is one I use all the time.

Lets say you are deep in some directory and need to hop to another directory quickly:

[/usr/share/fonts/dejavu]$ cd /var/log
[/var/log]$ cd -
/usr/share/fonts/dejavu
[/usr/share/fonts/dejavu]$

4) Reverse i-search

At least in bash & zsh, typing Control-R will allow you to search as you type through your history. This is really handy when you know the start, middle, or end of a command but aren’t sure what the rest is. Try it, type Control-R and start to type a command you’ve typed previously – once you find the one you want, just edit it (or not) and go.

5) alias

If you aren’t building aliases then you are missing out on one of the oldest shortcuts here. An alias allows you to define a command which calls another command. I make very heavy use of these and I see plenty of people who don’t.

alias vipuppet='cd ~/projects/puppet ; mvim .'

It saves typing & time.