We just wrapped the 2013 edition of RailsConf, and I’m both exhausted and excited. There’s nothing quite like being surrounded by 1500 of your peers, all sharing knowledge, experimenting, and having fun for a few days.

Every year at RailsConf, we have a job board – and every year, it fills up on the first day. Hundreds of hands shot up when we asked who was hiring on the first day, and being around that many people thinking about jobs and recruiting and whatnot meant that I got to explain why I’m funemployed (and what would cause me to leave it) several times in the last few days.

When asked that over the past few weeks, I’ve been telling people basically the same thing, so I thought it’d make sense to set it out here. This, then, is what I want to do:

I’m fascinated with feedback as the primary mechanism to improvement. I love the research on the development of expert performance, devices that measure and report on your activity, and experiments that show how our behavior is shaped by the way people and the world respond to us. I’m intrigued by self-tracking, to the extent that when my Nike Fuelband stopped working I bought a Jawbone UP to get me through the couple of days it was off for replacement.

The Fuelband, UP, and other devices represent to me the culmination of a march of progress (that I’ve referred to before). For any given domain,

1. You start with no tracking
2. Then, you start tracking – but it’s intermittent and subjective (I ran today)
3. Next, you start to track events when they happen (keeping a running log in your car)
4. After that, you start to add technology so that your recordings are more objective (I ran 3.2113 miles in 29:42 – thanks, GPS!)
5. Once you’ve got technology, you can move to automated recordings (automated tweets of your progress)
6. And finally, when the tech is small, light, and low-powered enough you can keep it on all day long and measure all activity, not just designated runs

This process describes a continuum from a complete lack of tracking, through sporadic, subjective, imprecise recordings, all the way to objective, continuous, ubiquitous tracking. That’s what I’m interested in – applying that process to different domains, specifically so that people can then look at the data, understand what they’re actually doing every day, and make changes for the better.

These efforts do exist, but for the most part they’ve only advanced in the health field, and more specifically in the general-physical-activity field. Fitbit, Nike Fuelbands, and Jawbone UPs are great, but I see an enormous amount of potential for this same process to take place in other aspects of fitness (for instance, weight training), reading and publishing, software development, and more.

So: if you’re working on something like this, let me know! I’d love to chat, even if I’m not an exact match for what you’re doing.

I’m taking advantage of being funemployed by taking a few online courses, including Dan Ariely’s A Beginner’s Guide to Irrational Behavior at Coursera. I’m very familiar with Ariely’s work (I’ve read each of his books and cited various pieces of his research in my talk at SXSW a few years ago), but I’ve been pleasantly surprised as each week has taught me something new.

Case in point: fairness, specifically as it relates to salaries. It’s rare to see developers paid in multiples – even if the 10x developer is a myth, it’s certainly true that some devs are several times more valuable to a company than others. Even in those cases, however, it’s exceedingly rare to see salaries that vary by the same magnitude as the value the worker brings.

As it turns out, research implies that “fairness” as a concept depends more on effort than on results. Imagine how much you’d be willing to pay two people to accomplish the same task (say, fixing your car). The first person takes eight hours and is clearly struggling the whole time, while the second person barely breaks a sweat and fixes it in fifteen minutes. Most people are inclined to pay the first person more, despite the fact that the outcomes are the same – and that the second person imposed much less of an opportunity cost on you (since you’ll have seven and a half hours to drive around in your car that would’ve been lost in the first scenario).

So there’s the problem: concerns of fairness predispose us against paying people according to their actual value, instead moving us towards paying based on the effort they exert. Thus, we probably overpay inexperienced developers (who have to exert more effort to produce a given amount of value) and massively underpay our best developers (who create much more value more easily).

Note that hourly consulting rates codify this intuition – if a task takes longer, you pay more – and that’s only partially offset by different rates. Flat fees for a project (based on the projected value the project will bring) are the clear alternative, but there are known issues with those as well.

A couple of weeks ago, I posted about my upcoming funemployment (which has since begun). I mentioned in that post that my past jobs have helped me figure out how I’m most productive, and I’ve had a couple of people ask me what exactly I’ve learned about that. So, here goes.

I don’t think I’m particularly unique with any (or at least most) of these items, but I’ve found it helpful to be clear about them to myself.

Timing

Like everybody else, I prefer fairly lengthy stretches of uninterrupted time. Being easily distracted, I find it easiest to get those stretches early in the morning or late at night – I’ve been known to wake up at 3am when I really need to churn on something to hit a deadline.

Location

I’ve built a Cave for myself in my home office, and I love it. I’ve got a bright orange wall, six huge bookshelves bursting with evidence that I loved reading before I got an e-reader, boxes of comics, a couch, a whiteboard currently hosting a 3,000 piece jigsaw puzzle-in-progress, and everything else I might need to relax and get amazing amounts of stuff done.

My Cave also serves as our guestroom, and it’s when other people are in there that I really understand how essential that room is to me. I’ve lived in the house with my Cave inaccessible for over a week, and I nearly pulled my hair out. If I’m close to the Cave but can’t use it, I’m essentially useless.

That said, if I’m far from the Cave – at an actual office, at a conference, or something similar, I can cobble together places to work where I can still be productive. The key for me is being free to move; instead of the comforting sameness of the Cave, I need variety. Coffee shop, hotel desk, hack room, comfy bench – I can work at any of them as long as I can move to another place easily. (This is why I get almost nothing done when visiting family; I can work for a bit at the in-laws house, but it’s rude to up and leave for another venue after an hour.)

That need for freedom also plays into my opinions on on-site vs. remote work. I can be tremendously productive on-site, up to a point. For my best work, however, I need to get out of the office at times and just focus full-bore on the problem. Similarly, I’ve done a ton as a remote employee, but I do need to get into the office periodically to check in and reset relationships with co-workers.

People

I’ve made great friends at every one of my past jobs, and I much prefer working with friends to mere acquaintances. Friendship makes communication easier, which has made otherwise difficult remote positions (which are always constrained by communication issues) very successful.

I also love working with people who are smarter than me. Luckily, that’s no so hard to find; the challenge is making sure I take advantage of it. I end up being more productive when I force myself to talk things over with colleagues.

Products

For much of my career, I didn’t care that much about the specific product I worked on – I was much more focused on enjoying the technical aspects of the work, instead of the effects of what I was building. I can still do that and be productive, but I’m unable to maintain that indefinitely. In fact, the length of time I can “look past” what I’m building to enjoy the process is shortening – it’s probably no more than a couple of months now.

Of course, with increasing time spent on a project, you have the potential to become more productive (as your knowledge of the domain increases, etc.) Thus, I’m going to end up being more productive when I’m in love with the project and can see myself spending a long time working on it.

Ownership

The other problem I had with consulting was one of ownership: even when I was passionate about the project, as a consultant I was largely subject to the whims of the client. Regardless of the strength (or rightness) of my opinions, I could always be overruled by the person writing the checks. I’ve since had the opportunity to work on projects where I had much more control and ownership, and I think that I’ve been much more productive as a result.

Creativity

The last thing I learned is that I have to build things. I can survive for a while without writing code, but if that continues indefinitely then I eventually become useless for almost any task.

So that’s about it, for now. At the moment, I’m trying to look at these factors and figure out how they should influence my search for what’s next. If you’ve got any suggestions, please let me know!

I’m at Monitorama this week; it’s been a great conference, but a weird one for me. This is the first conference I’ve been to in years where I don’t know a significant minority of the attendees, and it’s the first non-Ruby/Rails conference I’ve been to in even longer. I’m enjoying the feeling of not-quite-knowing what’s going on, since I’m not deeply embedded in the DevOps / monitoring movements.

One thing that struck me yesterday during the talks was an issue of vocabulary: many of the speakers seemed to use “monitoring” and “alerting” almost interchangeably – it’s almost as if the purpose of monitoring was just to enable alerting, which is all that matters. (I don’t think that anyone actually holds that opinion, but that’s the way it came across at times).

Later in the day, I had a chat with Mark Imbriaco about just this, and he pointed out that there’s a third term that we need to care about as well: trending.

So, here’s my naïve attempt to clarify the definitions involved here:

Monitoring is the process of gathering data. It provides the foundation for both alerting and trending, but on its own just fills up hard drives and makes pretty graphs.

Alerting is the process of detecting anomalies in monitored data and announcing them to interested parties. This is what most of the DevOps movement appears to care about at the moment, because 1) alerts are what wake people up at 1am when the server’s on fire, 2) alerts are by definition exceptional and require a response (even if that response is “meh, it’ll clear”), and 3) current alerting technology is woefully inadequate, lacking context and even basic intelligence in many cases. Alerts inspire reactive action.

Trending is the process of looking at monitored data for patterns. This is the concept that I think is underemphasized in many current discussions, because alerting is so top-of-mind for everyone, but trending has one huge benefit: it allows you to be proactive. Looking at disk space usage trends may allow you to find and fix a log rotation problem days before it generates a wee-hours alert. Watching page load times may help you optimize code and generate an immediate bump in the number of people who complete a registration process.

I’d love to see trending attacked with the same focus that alerting is currently getting.

(Of course, it might be, and I’m just too far on the outside to see it. If so, I’ll happily accept pointers to that work.)

First off: thank you to everyone who sent their thoughts and well-wishes. It was extremely heartening to open up Twitter or Facebook and see people hoping that I’d be OK.

OK, so a bit more information on my ill-timed hospital stay. After a hard (but not unreasonably so) Crossfit workout on Tuesday and being sick with a fever on Wednesday and Thursday, I went to the doctor on Friday to get checked out. As it turned out, the levels of creatine kinase in my blood were slightly elevated – normal is 20-300, whereas mine were over 60k (we don’t know the exact level I had because the lab’s scale only went to 60k). I got the call and went to the ER that night, missing the last few hours of Morgan’s birthday.

Extremely high CK levels are the calling card of rhabdomyolysis, which is the result of severe muscle damage. There are a lot of potential causes for rhabdo, including crush injuries, burns, a number of viral infections, and overexertion, among others. Basically, the damaged muscle cells spew their contents into the blood. This can be bad for the kidneys (which can’t filter muscle proteins and can fail as a result) and other organs (as various chemical balances can get thrown for a loop).

In many cases, rhabdo itself is untreatable – the muscles are damaged and you can’t undamage them. (Some of the potential causes result in ongoing muscle damage, but those are very rare.) What you can do is treat to prevent the other problems, the kidney damage, etc. So, once I was in the ER (and for the duration of my stay at the hospital), I was pumped full of IV fluids to keep the kidneys from getting damaged by the muscle proteins in my blood. Luckily, my blood tests showed no evidence of any kidney or other organ damage; all I had were the high CK levels. The hospital was able to be more specific about those levels, though, which was good. On admittance, I was at 65k (200+ times the normal level).

The doctors pretty rapidly agreed that the workout on Tuesday was not the sole cause of the problem given my description of it and the next few days. What they weren’t able to do, however, was settle on the other contributing causes. I might have been predisposed to rhabdo by a viral infection (which are very difficult to detect and basically untreatable anyway), by the flu (takes a while to detect and also untreatable by the time they were looking for it), electrolyte imbalances (impossible to detect after the muscle damage, because the rhabdo itself hides the original issue), or something else entirely. One doctor told me directly that I was a “confusing case,” and several expressed frustration that they weren’t able to narrow it down more fully.

That said, by this morning my CK levels had dropped into the low 30k-range, indicating that the muscle damage wasn’t ongoing. Given that and the excellent condition of my kidneys and other organs, they determined that it was safe to send me home (with the proviso that I drink a ton of fluids and avoid intense exercise for a couple of weeks). I’m to follow up with my primary care doctor for bloodwork on Tuesday and again the following week to confirm that my levels continue to drop – and potentially to see if an electrolyte balance or anything else becomes visible as the rhabdo itself recedes.

So, there you have it: my rhabdo journey. I had a mild-to-moderate case, with no complications and almost no visible symptoms, so I count myself lucky despite the lack of a real explanation about how I ended up with it.

Will I be going back to Crossfit? Absolutely. It seems pretty clear from talking with the doctors that the workout itself wasn’t enough to cause this, and the best way to guard against exertion-caused rhabdo in the future is to continue to improve my overall fitness. I love the people and the supportive atmosphere at Crossfit 919, and I can’t wait to get back there once I’m cleared to exercise again.

Will I be more careful about how hard I push myself and how I eat and drink when I’m sick? Definitely. Even if the respiratory crud I’ve had for the last several weeks or an electrolyte imbalance didn’t contribute to this, it’s a wakeup call that those things are even more important when you’re ill.

Would I eat the grilled chicken caesar salad at this particular hospital again? Nope. The chicken was heavily spiced with cumin, giving the whole dish an unwelcome Tex-mex taste that didn’t go well with the dressing.

I’ve gotten into a really bad habit when it comes to my work: every job in software development I’ve ever had has essentially been an (extremely fortunate) accident:

1. My first gig (nearly 14 years ago) was just something to occupy my time after my first year of graduate school in philosophy.
2. From there, one of my volleyball buddies needed a web developer for his team at Nextel, and I thought it sounded fun.
3. Once I decided to leave Nextel, I found my next job at Viget through Craigslist. I had a competing offer for that move, though, so I did make at least one decision about what I wanted to be doing.
4. As I prepared to leave Viget, I started looking for my next move under the radar. I talked to a few companies, but only got into real depth with two, and once I visited Heroku in San Francisco I was convinced – they seemed like the best match for the direction my career was moving.
5. After some time at Heroku, I realized that I’d misunderstood my ideal mix of evangelism and building-things; I chatted with some friends at conferences, and ended up responsible for email at LivingSocial.

I should be clear: every one of these jobs was wonderful. I made great friends, learned tons, and solved difficult problems at each one. Beyond the actual work I did, however, I also learned more about myself at each position – the things I like and dislike in companies, how I’m most productive, how to work with other people, etc. Each move was largely an accident, but they all resulted in fantastic experiences that I wouldn’t trade for anything.

So, for my next trick – as of April 5th, I’m leaving LivingSocial. I’ve been there for nearly a year and a half, worked with brilliant people, written systems that operated on a scale few people see, and gained a pretty substantial range of startup experience.

Unlike my previous moves, however, I’m leaving LivingSocial without my next job lined up. Instead, I’m joining the ranks of the funemployed for a bit, specifically to think about what I want to work on next. I’m really looking forward to talking to people and finding out what amazing things are happening in the world that I would otherwise never have known about – so, if you’re doing something awesome and looking for a senior developer with a wide range of experience, let me know!

I’ve worked remotely to a greater or lesser extent for three or four years now – ranging from working from home a few days a week to being 100% remote and on the other side of the country from the home office. In my experience:

For any given person, they’re going to be less effective working remotely than they would be working face-to-face with their team.

ZOMG, let’s all be Yahoo! and eliminate remote work!

OK, calm down. The story is a little more complicated than it might appear.

For one, remote work opens up your recruiting pool to more talented people who happen to live somewhere else and don’t want to move. If the best developers are in fact 10x more productive than average developers, then you’re much better off with them at 90% effectiveness than you are with an 1x or 2x developer at 100%.

For another, unless you have an on-site customer there’s a better-than-average chance that you’re already abandoning the “face-to-face with their team” part of the statement above, and you’re already paying the reduced-effectiveness cost of a partially-distributed team. Recognizing that and adjusting in response is the best way to reduce that cost.

And finally, there are benefits intrinsic to remote work. Separating the team makes groupthink less likely, makes intentional action more likely than reaction, helps people think twice about interrupting, and lets people work when and how they choose, which can make them happier.

In the Twitter conversation that spawned this post, Joe O’Brien put it succinctly:

@mikegehard to Ben’s point costs degrade either way, less talent or more distance. Costs could be equal depending on mix @bscofield

— Joe O’Brien (@objo) March 5, 2013

There are costs and benefits to both requiring everyone to be in one place and allowing people to work remotely. In some cases, balancing those costs and benefits may end up with everyone together; in others, they might result in a partially- or fully-distributed team. There is no silver bullet, other than committing to making informed decisions.

My friend Justin Gehtland tweet this a bit ago:

At its root, every problem is a *people* problem, because only people have problems.Without people, they are just facts and circumstances.

— jgehtland (@jgehtland) February 12, 2013

That spawned a quick response from me, Jim Van Fleet, and Ben Vandgrift. I want to refine what I said, however – and to a certain extent take it back.

First, a definition: a problem is a mismatch between the way the world is (facts and circumstances, in Justin’s formulation) and the way that some person wants the world to be. Not all such mismatches are problems (the non-existence of unicorns isn’t a problem, despite the fervor with which my daughter wishes they existed), but all problems are mismatches of this sort.

For example, here’s a problem: my website is vulnerable to a security exploit. This is a problem because the way the world is (my site is vulnerable) does not match my desires (to not have my site be vulnerable). 

Here’s another problem: a space probe sent to Mars stopped functioning the day after it landed. This is a problem because the way the world is (the probe stopped working) does not match a widely-held desire (for the probe to work properly over a long period of time).

OK, so if that’s what a problem is, what makes a problem a particular type of problem? What makes something a “people” problem?

I’d argue that we usually classify problems by their solutions. If the way to resolve a problem is by rebooting the server, then it makes sense to call it a server problem. If you have to replace a power source, then it’s a power problem. If you have to change code, then it’s a programming problem. 

So: problems are mismatches between the world and desire, and we classify problems by their solution. It follows from these two points that Justin was correct – all problems are people problems, because we can in fact resolve all problems by changing people. Specifically, we can eliminate any problem by changing the desire side of the mismatch. If I don’t care that my site is vulnerable to a security exploit, then the fact of its vulnerability is not a problem. If NASA doesn’t care that the Mars probe isn’t working, then its failure to work is not a problem.

Of course, this makes calling something a “people” problem a triviality. In the vast majority of cases, we want to resolve the problem by changing the world, not our desires. So, let’s refine the classification of problems to say that it should prefer solutions on the state-of-the-world side, falling back to the desire side only if no other option is available. For my insecure website, the best solution isn’t to stop caring that my site is vulnerable – it’s to fix the code to be more secure (so it’s a “security” or “programming” problem). For the Mars probe, on the other hand, we may not actually have a way to change the world – we can’t zip up to Mars and unstick the wheels, though we might be able to push code changes if the issue is one of programming. In that case, we’d either have to live with the problem unresolved or eliminate it by changing how we felt about the situation.

Picking up on that “how do I know what I think” quote – let’s start to tie a little bit of this into topics that might be more interesting to my usual crowd. One of the most powerful things you can do in your life is journal. I don’t necessarily mean writing down your thoughts and feelings each day (though that can be extremely powerful) – I mean recording anything, reliably. Keeping a food journal is a proven strategy for improving eating habits and losing weight. Keeping a training log helps runners break through mental and physical barriers. Following GTD and keeping track of next actions helps millions of people feel – and be – more productive. This practice has become known (though usually in its more technology-enhanced forms) as the Quantified Self.

Here’s the thing: we, as human beings, are spectacularly bad at understanding what we do. Check the list of cognitive biases in Wikipedia (check it even if you’ve read it before, because you might be succumbing to a bias on the list) and you’ll see a litany of ways that our brains fool us. Read any of Dan Ariely’s books to learn about experiments that prove that we’re more susceptible to external influence than we think, that we can rationalize away enormously surprising behaviors, and to get really depressed about our rationality or lack thereof.

Journaling (or, more broadly, measurement) actively confronts some of these problems by allowing us to get a more objective view onto ourselves and our behavior than we’d otherwise have. Even journaling, however, is imperfect. If I wait until after work to write down what I had for lunch (I left my food journal at home!), then I might forget the second serving of the bread basket. One option is to make the journal harder to forget; making it an iPhone app ensures that it’ll be as close as my phone. The ubiquitous journal still requires effort, however, and allows me to inject subjectivity and error into the process. If I eat out after a hard workout, I might fudge the log on the grounds that “I earned a milkshake.” 

The real goal – and as far as I can tell this is true for every Quantified Self domain – is transparent, automatic tracking, with no manual intervention. Imagine how this might work for, say, running:

• First, no tracking of any sort. You go out and run for fun.
• Next, we add a pen-and-paper training log. After each run, you note how long it took, how far you went, etc.
• Now, we add a stopwatch and a GPS, to get precise measurements and to help prevent you from unconsciously improving your times and distances.
• Then, we switch over to Runkeeper or Nike+ so that the recording itself is automated.
• Finally, we slap on a Fitbit or Nike+ Fuelband and track movement constantly, whether running or not.

With this level of automated, objective measurement, we finally have the ability to see exactly what we’re doing without the soft focus filter that clouds our eyes while we’re doing it. The challenge then becomes analysis and response – what does the data mean, and how should we change our future behavior to better meet our goals.

OK, who’s heard of Radical Honesty? My introduction to it was in AJ Jacobs’ My Life as an Experiment. The premise is that you don’t lie, and (according to the founder) don’t filter at all. If you’re mad at someone, you let them have it with the full force of your anger; if you’re attracted to someone who is not your partner, you tell them that you’re thinking about what it would be like to have sex with them. This would seem to be the ultimate expression of the thought I expressed in On Integrity, but in practice I think it’s much too facile.

Here’s the thing: I fully believe that you have the opportunity to choose who to be. My two favorite quotes of all time are both related to this. Paraphrased, they’re:

How can I know what I think until I see what I say?

I started acting like the person I wanted to be, and I gradually became him.

The first one points to the extreme limits of our self-knowledge. We don’t control our internal thoughts and feelings, and at times we’re not even aware of what they are. That’s why flipping a coin to make a decision sometimes works so well – when it comes up on one side and we get disappointed, it’s evidence that internally we had a preference that we weren’t consciously aware of.

The second one points to the fact that our instantaneous lack of control of our minds doesn’t mean that we can’t train them to do what we want. If I decide I want to be more civil, then I can force myself to act more civil – and eventually, being civil becomes a reflex or a habit and I don’t have to force myself anymore. Per the discussion of integrity, of course, this only really works if I’m fully consistent. I can’t be civil in my non-anonymous interactions and still flame people at will on Twitter and expect to train myself away from the troll-tastic instinct.

The problem with Radical Honesty, then, is that is completely abandons the second principle. It’s all about advertising who you are now, as opposed to who you want to (and can) be.