Tag Archives: work

Keeping track of work / life balance

Working from home is great. No commute. Really good coffee 50ft away. Being able to get started as soon as I wake up. Being able to break for exercise / food / etc when it fits in my natural flow, instead of having to work around an office / commute schedule.

There are some drawbacks. One of which is there is no real signal on when the day is done. Not realizing the building has emptied out and you shouldn’t be there any more either. I had a few weeks early in the new year where I was completely burnt out and grumpy by the time I got to Thursday. Doing some quick mental math, I realized I had put in far too many hours those weeks.

I have a pretty solid work from home routine. I work in my home office (and that’s almost the only time I’m in there). I have a fast desktop computer that I do all my work from when I’m home. Enough so that I’ve written automation around the screensaver events to do things like mark me away on IRC. This seemed like a natural way to keep track of how much I was actually working at my computer through recording all the lock / unlock events.

screenshot_216

The latest version of this program records these lock events week by week. It can then add them together and give me a view on how long I’ve worked both today, and this week. A Linux desktop notification is sent every time the screensaver is unlocked, as well as every time it hits a round number. It’s just enough of a signal to realize it’s time to stop for the day / week.

I’ve been doing this for a month now. The results are interesting. First, I learned out much I was actually working. It was far more than I had realized. So I consciously started capping days and weeks when I got to a number I felt was fair. This often means that Friday is a pretty light day, and includes a long family lunch outing. It also means I never miss a chance for a family walk in the middle of the day, because I have time for it, I even have numbers to prove it. (Note: I’m mostly proving it to myself so I don’t feel guilty when I put down the computer, as I work in a great organization where no one else cares about this as a metric.)

It’s also had an interesting impact on free time hacking. I now still have enough energy in my tank at the end of the week to still be able to do interesting things with computers that aren’t strictly work. Saturday mornings before the girls wake up has become tech exploration time again. This has included relearning elisp, and actually writing some emacs extensions recently (fly-hack, stacktest). I also made progress on my home weather station code for the first time in a year.

It’s amazing what happens when you measure a thing, not for anyone else, but for yourself.

Biking to Work

As I clock in on my 36th birthday, I finally have started doing something I’ve wanted to for a decade: ride my bicycle to work. It took another friend at work to start riding as inspiration, and it took planning a route that lets be on non car accessible paths for 50% of my ride, and reduces my interaction with busy roads to < 10% of my ride. The road bike I bought 12 years ago, and barely used until now, is now seeing it’s day in the sun.

I’ve now bike commuted twice to the office, and it’s glorious. It’s 9 miles each way, which is about 40 – 45 minutes in, and 50 – 60 minutes home. In comparison, my car commute is 20 – 25 minutes. The way home is always going to be slower, as I’ve got to gain elevation over it, and it’s a lot warmer at 6pm than at 8am. I’m only going to ride in good weather for now (not raining, high < 90), but even with that I’m hoping to make this a 3 day a week thing.

When you start biking something that you’ve always driven, something in your brain flips about the scale of the universe. What used to be teleporting via you car, a disconnected universe, is now a much more present, and connected journey. This ride is interesting and varied, cutting through Vassar’s campus and some of the quiet neighborhoods of Poughkeepsie. I ride past the houses of two friends, and the work place of another. I’m sure one of these days I’ll actually run into someone I know during the ride.

And lastly, I get this incredible clarity and decompression during the ride home. The ride, the exercise, just clears your head in an amazing way. I love it.

My only regret is that I started doing this so late in the year. Once we get late into September waning daylight is going to make the ride start touching sundown, at which point I’ll need to give it up for the winter. But I think I’ve started a new habit, and I’m absolutely loving it.

 

Standing Desk

After an interesting conversation last weekend about sitting vs. standing while doing computer work, I decided to jerry-rig a standing setup at my desk at work to see if it would work for me. I’m now at the end of the first week of at least 2 weeks experiment, and some interesting things so far.

You need to get used to standing. I sort of knew this from vague memories of working at a deli in the high school / college era. Day 1 is pretty brutal, and you find yourself only able to do it for about an hour at a time. You also are spending all your time thinking about standing, as your body is really not used to doing this on it’s own. Don’t worry, that changes over time. By Day 3 doing 3 hour stints (which between meetings and lunch is about the longest run I’m going to get anyway) is fine. If your back starts hurting (it will, it’s not used to it), sit down until it doesn’t any more.

Context switching is different. I can’t yet say better or worse yet, just different. There is inertia involved in sitting down, or more importantly in standing back up.

Pair Programming is easier. There is just a different notion of space in standing vs. sitting, so showing someone something else seems less intrusive.

There is no afternoon slump. I’m someone that definitely suffers from that afternoon slow down where you get kind of sleepy. That’s entirely gone away.

Sitting starts to feel unnatural. By friday, I was just itchy to get back on my feet after any time I was in a meeting and needed to sit down. That wasn’t entirely expected, but I think it’s a good thing.

I’m going to run this experiment another week, then if it looks like I’m able to get back to the same concentration levels standing as sitting, I’ll look into a more permanent standing desk setup (probably also one at home). I’ll also probably get another pair of shoes, as doing A / B swap of shoes is really helpful when you are on your feet all day. I’m actually less tired when I get home, though it’s possible that’s just a result of it being a change of any sort, not specific to the kind of change it is.

If nothing else, it’s good to try something different from time to time just to shake up your world a little bit.

Rands in Repose: Bored People Quit

This was a very solid top item on Hacker News today:

Much has been written about employee motivation and retention. It’s written by folks who actively use words like motivation and retention and generally don’t have a clue about the daily necessity of keeping your team professionally content because they’ve either never done the work or have forgotten how it’s done. These are the people who show up when your single best engineer casually and unexpectedly announces, “I’m quitting. I’m joining my good friend to found a start-up. This is my two weeks’ notice.”

You call on the motivation and retention police because you believe they can perform the legendary “diving save”. Whether it’s HR or a well-intentioned manager with a distinguished title, these people scurry impressively. Meetings that go long into the evening are instantly scheduled with the disenfranchised employee.

It’s an impressive show of force, and it sometimes works, but even if they stay, the damage has been done. They’ve quit, and when someone quits they are effectively saying, “I no longer believe in this company”. What’s worse is that what they were originally thinking was, “I’m bored”.

Boredom is easier to fix than an absence of belief.

For the engineering sector, this nails it, and matches well with a tweet I saw yesterday:

@johndbritton: Q: “Do you know any good developers that need jobs?” A: “No, that is an entirely unheard of scenario.”

This all especially struck a chord as I’ve been organizing my Google+ circles, and noting how large the population of used to work at my employer is.

 

CMS vs. Wiki

This past week we had the second meeting of the Hudson Valley Drupalers, over at Marist College, which was really impressive. Vonn gave an overview of some of the really amazing things you can do with Taxonomy in Drupal, which I’d not even thought about. It was incredibly inspiring, and making me think about how I’ve created content types in all my sites, and how to do it better. And it’s really gotten me thinking.

At work we largely work with Wikis. Over the years I’ve been really a big supporter of wikis (heck, the wiki that our division uses is one that I started for our department years ago that got successful enough for our infrastructure folks to take over), but as I watch a current effort to organize some information on an internal wiki, I see how tough it really is. Wiki is largely a write only medium. Yes, with lots of effort, you can create something like Wikipedia. But you have to remember that 100x more effort goes into editing to keep it consistent then the initial content creation. Content Management Systems are really read mostly media. You only get to change a small amount of the page, then that content is sliced and diced in many ways throughout the system. This may seem like a trivial distinction, but when it comes to organizing information, the power of that slicing and dicing is huge. There doesn’t need to be only one way to see the data, there can be many ways in, and many ways through.

Maybe it’s time to try to introduce the CMS model in our area, and see if it would help productivity. I might make that a “Think Friday” activity once the Day of Service is over. The wiki experiment from 2004 took this path, and eventually got adopted on a broader scale.

Why Context is Important

Recently at work I got a question about tools that our project uses. I get these sorts of questions at various times somewhat regularly for a number of reasons. As a responsible answering party I asked what the context of the question was. And, this time got no response, which means that my answer was probably crap.

When someone asks you to explain the context of your question, they could very well be saying “go away, I don’t want to deal with you”. But just as frequently they could actually be trying to communicate with you and give you an answer that they know you’ll get something out of. A snap answer is almost always wrong because the context and head space you came up with your question is going to be an entirely different head space that the person you are asking has been in all day/week/month or even forever. Communication, real communication, not waiting for your turn to speak, is what happens when two or more people extend their frame of reference to try to overlap so they can actually see what’s going on in the other’s head.

It frustrates me to give a useless, or worse, a bad answer because I couldn’t draw out more information about the question. Fortunately it happens rarely enough that I still get riled up about it, like today.

Set Taxonomy on Confused

Today I found myself in a requirements database where a small group of people had come up with a priority scheme composed of three levels: Very Important, Must Do, and Critical. And I was stumped: what is the relative priority of these terms?  I, as it turns out, wasn’t the only one confused by this.  I did appear to be the first one outside of the core group to raise my hand and ask the question.  (I have the answer, but I’ll leave it as a guessing game in the comments for people).

User Experience (UX) is important on many levels, some times surprising ones.  Reusing words that people think they understand in ways they don’t causes a lot of confusion and adds a lot of confusion (and thus waste) to systems.  I did propose that priority words were annotated with a number, so those outside the core could get a handle on what’s going on, which was a well received comment, and will go into the next version of this tool.

Talent vs. Practice

This is a really great blog post on Talent vs. Practice:

I am sick of hearing people say, “Oh, I love your code, I wish I could do that.” You can. The only reason you can’t is because you don’t practice enough. I used to think that I wasn’t smart enough. I was jealous of those that did crazy code stuff that I couldn’t even comprehend. Then, one day, I ran into something I did not understand and instead of giving up, I pushed through. I sat there in front of my computer for hours and wrestled with class and class instance variables.

That day was a turning point for me. It was the last time I thought that whether or not I was successful depended on my talent or intelligence. It really comes down to hard work people. Ever since then, I have attacked each thing that I do not understand until I understand it.

The real moral of this story, stop talking about things you wish you could do, just knuckle down and do them.  It’s hard work, but it’s the way you make an impact.

Manager vs. Engineer Worldview

I was in the middle of this amusing exchange the other day. Names removed to protect the innocent, and summarized a bit. I like and respect everyone involved in the exchange, but it just shows a difference of world view.

Manager: We’re told there is a list of 9000 non compliant people corporate wide. We think there are about 300 in our organization. I think it will be easiest to just email all the affected managers and figure out who is compliant and who isn’t.

Engineer: Wait, there is a text parsable list of those 9000? Can we get a copy of it? It should only take about an hour of scripting to bang out something that rips through that list, looks in the directory, and sees who eventually reports to our VP.

Manager: really?

Engineer: Yeh, plus it will mean less people have to do busy work. If we send it to all the managers, they’ll just send it to employees to sort it out, which will end up being a whole lot of man hours and time lost, and get everyone grumpy with more paper work.

Manager: right, good point.

Of course this means that Engineer has signed himself up for that hour of extra work, but that’s ok, it saves everyone else a lot of time, and Engineer in question doesn’t get to code often enough anyway. 🙂

Don’t step in the Leadership….

The last two days of work weren’t actually work per say, they were the Leadership Excellence class here at IBM. I’d heard really good things about the class from people that I very much respect that have gone through it, so was rather intrigued in what it was going to be like. This ends up being 3 – 4 weeks cumulative of classes over the course of the year, so there will surely be more on it here later.

Our first module was the 2 day Collaboration Class. What this class really was, was about Communication. We started with a behavior test, to determine our own behavior types, and that was used as the basis of a series of team exercises over the course of the 2 days. We were using the DiSC method, and I came out a strong DC, for those who know what that means.

After 2 days of group activities, including a group activity to resolve behavior conflicts over the building of the first rail road, my brain is quite full, but I am looking at the world slightly differently. If all the classes are as good as this one, I really can’t wait to see what is next. 🙂

Going through the DiSC test did make me start wondering about Myers-Briggs again however, so I was amused to find the Harry Potter MB test this morning on science blogs. I am:

Not all that scientific, but amusing none the less. 🙂