Monday, July 30, 2012

Take Pleasure in Absence

We spend our professional lives seeking things. We want confirmation of bugs. We want new features. We want affirmation that our bug fixes work. We spend all day every day doing things.

Sometimes, though, there is pleasure in not doing things. There is pleasure in absence, and only when we stop doing can we start seeing.

Give yourself five minutes while you're making coffee tomorrow morning, put down the iPhone (Twitter can wait!), and consider:

  • The worry no longer felt
  • The fear not realized
  • The pain not seen
All that absence! All that not seeking! Feels good, doesn't it?

I'm not going to tell you to stop seeking; after all all that absence came from seeking improvements. Instead, take one small breath and notice the beauty of the absence.

Tuesday, July 24, 2012

You Do What Again?

This weekend my aunt, uncle, and about-to-go-to-college cousin were in town visiting. We were catching up, and one of the things my cousin said was, "So what do you do all day?"

As background, you should know that both my aunt and uncle are physicians. They don't know what software engineers do all day, either! (Granted, I don't know what physicians do all day, so we're even.)

So what do I do all day? In any given day, I'm probably going to do most of this:

  • Modify some existing code
  • Send a bunch of emails
  • Write some CSS
  • Test a feature someone else wrote
  • Respond to a customer request or problem
  • Attend stand ups and/or scrum meetings
That really doesn't sound very interesting. Those are the tasks I do, yes, and there is joy in many of them. I actually really enjoy writing code - it's a game to make the software do what I want. I also like playing with someone else's feature and seeing how they interpreted it. There's value, too. Because I write an email, a customer knows what to do. Because I wrote some CSS, a page looks as good as a designer could make it. Because I fixed a problem, a client saved time. That's pretty cool.

Those aren't tasks, though. They're accomplishments.

So what do I accomplish in a day?
  • Help others see possibilities
  • Make a system do something useful that it didn't do before
  • Make a web page more beautiful
  • Save time for customers
  • Offer my customers abilities they didn't have before
That's better. That's what I really do.

What do you do?

Friday, July 20, 2012

Synonyms for "Will Work All The Time"

The pendulum swings again. Remember work-life balance? Sooooo four years ago.

Now we hire honey badgers, apparently. We also hire people who want to have a beer at 6pm... as long as they're doing it at work. Hello, brogrammers. Oh yeah, and we'll take a ninja and a rockstar, please! As this guy put it:



In other words, we want people who are going to work very long hours and still be good at what they do. Oh, and we want them to be fun. The drinking is really only incentive to stay at work.

And that's fine. If you have an all-consuming dream, it's easy to expect others to want to believe in your dream just as much as you do, and to work tirelessly just like you are. That's the kind of thinking that brought us Facebook. Also the Internet. (Okay, so it's not all bad.)

Unfortunately, not every effort is the Internet. Some efforts are the next big toy. Or some niche thing. Or - let's face it - something that won't change the world. Some efforts fail. Some are just a bad idea, even if they are a dream.

And here's the thing. It's trendy to want people that will work all hours and do it well. The number of people willing to do that for anything is limited. The number of people willing to do that for any dream that is not their own is even more limited. The number of people willing to do that for your particular dream is even smaller. You've severely limited your hiring pool, and we haven't even started talking about things like talent or skills!

So be careful before you decide you're only going to hire rockstar ninja brogrammers. Be willing to consider something talented, even if they only want to work 40-60 hours a week. That's 40-60 hours a week more than you're getting from having nobody working for you.

Tuesday, July 10, 2012

Baby Sysadmin

Herein, a rant.

If you're a software engineer of any form - developer, tester, support engineer, or any variation thereon - you should know your tools. That's pretty basic. Java engineers probably ought to be able to compile something, and to know what a library is, and how to set up a class. It's reasonable to expect that Rails testers can describe the difference between factories and fixtures, and when each is useful. We spend time training support engineers in our tools and procedures specifically so they'll know how to use available tools effectively. Pretty basic, right?

But software does not live alone. It's been decades since the software we wrote was the only thing involved with running our program. Our software runs in an environment, complete with operating system, other programs, drivers, hardware, third-party dependencies, etc.

Shouldn't we know our environment?

Some of the problems we solve in our software are related to the environment. We have to handle the case in which our logging can't write because the disk is full. Or we have to test for what happens when our software and some other piece of software both try to use the webcam simultaneously. Or we discover that the hang in our software is actually the user's browser crashing for some unrelated reason.

Just like we use tools to create software, we use the environment to create software. We use disk space, or the webcam (and its drivers), or the browser (another piece of software). So just like we need to learn our tools, we need to learn our environment. We need to make ourselves into baby sysadmins.

We don't need to know how to do every sysadmin task, but there are some basic things that we should know:

  • How to view what processes are running and basic information (status, memory and CPU utilization)
  • Where to look for indications of hardware problems
  • How to view network information and utilization
  • How the operating system handles disk usage and I/0
  • Where the operating system or virtual machine (e.g., JVM) logs and how
  • What environment variables are required and how they might be set - both by our software and by external software
  • What limits are implied by libraries (e.g., 32-bit versus 64-bit software)
  • Roughly how the operating system works, including dependency management
  • Roughly how any containers - JVMs or browsers - work, including loading order and frequency, and other dependency management
None of these things are particularly difficult, and they're all directly related to how your software behaves in its environment. So go ahead, embrace your inner baby sysadmin.