Geek Philosophy

I’m a big fan of working with students, trying to instill in them real world skills that university can’t (or just doesn’t) provide. It’s for this reason that I do a guest lecture at least once a year, and it’s the reason that for the past two years I’ve signed on as a mentor in the UBC Computer Science Tri-Mentoring program.

I met with the student I’m mentoring yesterday afternoon and tried to answer several of his questions. As with most students I’ve talked to, the initial questions were a mix of technical and financial. Students tend to come up with questions along the following two themes:

• What programming language should I learn?
• How much will I make?

Don’t get me wrong – these are valid questions. However, I don’t think that salary discussions and language wars are the most I have to offer a student, so I tend to try to steer the discussion on to topics that I think students can benefit from most. Most students will figure out what programming language to learn based on what job postings are available, and when you’re starting out in the industry you don’t often have a lot of say as to what salary you’re going to get. The biggest thing I think students should learn are soft skills – communication, translation, conflict resolution, and so on.

Students learn languages in school. They learn algorithms, they learn math, they learn artificial intelligence and networking and computer graphics. All of these are important, interesting and worthwhile topics. However, if, as a developer, you can’t convince your product manager that you need to use https to secure your site because you’re throwing around jargon like key strength, public-key cryptography, firesheep, and packet sniffing, those years of getting a degree are wasted. You know what you want to build, and it’s technical sound, but someone is paying you to do something else. This is an extreme example, perhaps, but every developer has to deal with a non-developer at some point, and being able to translate is a key skill which will differentiate a new hire. After all, that HR manager interviewing you probably doesn’t care about the neural network you built, but they may care that you’re articulate and understandable.

There’s more to communication, of course – books could be written (and have been!) about how to successfully use email for communication, or how to manage your manager, or how to be a good team member. I just think that by getting a head start on such skills, students can gain a competitive advantage, accelerate their career development, and very likely grow as people as well.

A month ago, I bought a Prius, which, according to Urban Dictionary is the “Most Liberal Car Ever” (warning, site contains highly judgmental definitions). So far, it’s been an excellent purchase.

My wife and I have been part of the local Car Co-op for years and have really enjoyed their services. We’ve lived in the lower mainland for over ten years, and haven’t ever considered buying a car. Recently, though, we’ve found that our monthly car co-op costs were similar (if not more) than car payments, insurance, and gas, and that’s without even factoring in rental cars that we use to travel around the province. Overall, we stand to save about $1000/year, and that will go up significantly once the car is paid off.

Why a Prius? Well, the co-op car that we’ve been driving for the past 1.5 years has been a 2004 Prius with 150,000km on it. Co-op cars are driven by a lot of people, and unfortunately many of them are not nice to the cars. For example, we once had to bring the co-op Prius into the shop once because the previous driver had driven about 100km with the e-brake on. And still, the car drove very nicely, got great gas mileage, and was generally enjoyable to be in.

Given that it was what we were used to driving, and we knew it held up well to abuse (and a lot of use – almost all taxi cabs in Vancouver are now of the Prius variety), a Prius was high on our list when we went looking for a car. However, a new Prius starts at about $30k when taxes and everything are included, and we weren’t looking to drop that much coin on a vehicle. We test drove a few cars, including a new Honda Civic, a new VW Jetta, and a new Toyota Corolla. We also had our eye on a recent used Jetta or two. However, thoughts of other cars flew out the window when we saw a (very) reasonably priced used Prius sitting on the lot of the Toyota dealership. A test drive, a lunchtime discussion, and a nervous few hours later, and we had our first car.

It’s not quite new, but it’s only 3 years old and feels great on the road. We haven’t taken it on any highway trips yet, but it’s getting 5.3L/100km around town (impressive, given that we live on a mountain and all trips require going down and up). Better yet, it *feels* like a $30,000 car – it’s smooth, we love the trim, keyless entry and bluetooth are neat, and we’re enjoying the 6 disc changer more than we thought. We’re very pleased with the purchase so far, and we’re definitely looking forward to our first road trip.

This blog isn’t all geek – there’s some philosophy too!

Although I don’t consider myself a Buddhist in the religious sense, I find that the philosophy and thought processes espoused by Buddhism really resonate with me. I especially enjoy listening to seasoned practitioners discussion interesting topics. Whenever I’m looking for something new to listen to, I first turn to Audio Dharma. An online collection of several hundred talks on a variety of topics, Audio Dharma also has guided meditations and series of talks focusing in on particular issues.

If you’re looking to learn a bit more about the Buddhist way of thinking, or if you’re wanting to deepen your practice, Audio Dharma is highly recommended.

If you’re getting sick of my many reviews of Much Ado About Agile presentations, you’re in luck – not only is this my last review, but it covers two sessions (albeit on the same topic, by the same speaker). I’ll likely do a conference summary post after that, and then I’m on the hook for coming up with 19 more posts this month to keep up with NaBloPoMo.

On the morning of the second day of the conference, I listened to Christopher Avery speak about responsibility. I really didn’t know what to expect from this talk, and I hadn’t heard of Christopher, but the summary appealed to me – leadership is an area that I’m increasingly interested in developing. I spent all of Thursday in a tutorial with Christopher on the same subject – this post will cover both segments.

Christopher’s talk was centered around The Responsibility Process, which is a framework that describes how people react to adversity. Here are the five main states that someone’s mind can be in when approaching a problem:

* Responsibility

* Obligation

* Shame

* Justify

* Lay Blame

The idea is that when something bad happens, people’s minds land in one of the states above, almost always at the bottom. Often you’ll work your way up through the other states, stopping somewhere before responsibility.

As an example, let’s say that my team has accidentally shipped a critical defect to production. What immediately springs to my mind? “Whose fault is this?” This isn’t a particularly useful state of mind – blame doesn’t get you anywhere, and besides, most problems are system problems, not people problems. So, I say “well, this got out because we didn’t have time to test, and we have no budget for more testers, so I guess we’re stuck.” This is justification – I’ve explained away the problem, and now don’t have to worry about it any more. Unfortunately, the problem (or at least, the root cause of the problem) is still there!

Let’s say I realize that we don’t have the budget for testers, but I also realize that, as the manager, I’m ultimately responsible for the quality of the code. This realization could move me into Shame – “how could I have let this happen? I’m such a bad manager”. Many people stop here, and often shame is rewarded and treated as “responsibility” – if I asked my team who coded the bug, and someone put up their hand and admitted it, saying “thanks for owning up to it” would be rewarding shame.

Obligation is another state that’s mistaken as responsibility. Obligation is when you are trying to solve the problem, but only really expending energy and effort to be barely adequate to pass. Showing up to that meeting that you don’t want to go to, because you have to? Obligation. Almost everytime you use the phrase “I have to”, you’re talking about obligation. It’s important to remember here that the Responsibility Process is a framework for addressing your state of mind when faced with a problem or upset – in-depth analysis is not required when you say “I have to go catch my bus” or “I have to go to the bathroom”.

Spending too much time in Shame or Obligation can lead to a psuedo-state called Quit. This doesn’t mean you’ve actually quit the company, it just means that you’ve mentally checked out. The person who “has to” go to a meeting, then comes along and opens their laptop to read email, surf the web, or do anything else but be present in that meeting – they’ve quit. Christopher says that Shame, Obligation, and Quitting are the trillion dollar problem in information work today. By focusing your work hours on things where you’re truly excelling (instead of being barely adequate), the company will benefit and you will have higher job satisfaction.

How do you move from Obligation to Responsibility? This is the tricky part – it’s the idea of moving from “have to” to “want to”. You have to want to be responsible. That meeting that you don’t want to go to but you “have to”? If it’s truly a waste of your time, and you’re not getting anything out of it, talk to your boss and convince him that it’s not a good use of your time.  Now, if there’s really nothing that can be done about going to the meeting (for instance, if your boss convinces you that it *is* necessary), you need to re-evaluate and see if you actually have a problem.

This kind of thing is hard to explain, especially with contrived examples. Furthermore, as Christopher says, you can’t apply this stuff to someone – you need to teach it so that people can self-apply. The class on Wednesday focused on the concept, and the the tutorial on Thursday focused on how to teach it. This included hands-on group work (trying to convince others of the concept in face of resistance), and an in-depth look at the “Keys To Responsibility” – Intention, Awareness, and Confront. I found the tutorial quite helpful, and it was useful to work with others to find examples, counter-examples, and issues that would come up when trying to teach the Responsibility Process to others.

Christopher is a great speaker with a smooth presentation – think motivational speaker, not time share salesman, but without any sort of evangelical zeal. You can tell that he really believes what he’s saying, which I suppose is only right since he’s been researching this approach for 20 years. For me, this smooth presentation simply meant that I enjoyed a nice delivery of content that I could relate to, but I know of at least one other person that attended the first day’s presentation was turned off by it. This surprised me – a coworker suggested that this was a consequence of (over-generalization alert!) people in the software world not being used to dealing with talented professional communicators. There was also a definite “self-help” bent to the presentation, which I know I find more appealing that some others. Overall, I feel that it was definitely worth my time, and I’ll be trying to apply what I learned to help myself and my team.

The last talk I attended on the first day of the Agile Vancouver conference was put on by Linda Rising. If you haven’t seen Linda Rising give a presentation, you’re missing out. Her talks are a blend of psychology, chemistry, sociology, software development, and many other subjects. I loved her talk last year on “How We Deceive Ourselves” (I’d link to it but the Agile Vancouver website seems to have lost the videos from the past few years… UPDATE: The videos are here. Thanks @rbeier!), and was really looking forward to this talk.

Titled “Coffee, Tea, or Agile?”, Linda walked through the dawn of the industrial revolution, a critical time in human history which brought huge career moves and many elements changing at once. She focused on some of the developments that made it possible.

Clocks, which were not in widespread use before then, became essential as people needed to fit into schedules and shifts. Before the advent of clocks, people would generally sleep while the sun was down – an average of 10 hours a night, more in winter, less in summer. This is the way humans have been pretty much forever, which is concerning given that the average amount of sleep an adult gets nowadays is 7 hours – sleep is considered a waste of time!.

Caffeinated beverages played another critical role. The average European drank 3L of beer a day in the early 1800s – it was much cleaner than the water! The increasing popularity of plants that contained caffeine (tea leaves, coffee beans), that just so happened to release their caffeine in hot water, made boiled water (and thus perky, less drunk people) the norm. It also helped to break people out of their normal sleep cycles.

Linda then launched into a summary of caffeine’s prevelence in the workforce. It’s the most popular drug (she cites a study that says up to 80% of the world’s population consumes caffeine daily), and although it has been studied and considered relatively safe in does of around 300mg a day, (or two cups / 500ml of coffee), there’s a whole lot of people who drink way more than that each and every day. Have you seen the size of a Starbucks cup recently?

Next came the negative effects of caffeine, both directly attributable physical effects (decreased size of hippocampus, premature brain aging) and secondary effects (considerably less sleep). These effects were contrasted with what Linda called “the productivity myth” – namely, the idea that caffeine (and the extra work you do while buzzed) actually helps us be more productive. Although it may make us feel like we’re being productive (thanks, dopamine!), and being perky all the time helps us avoid napping (after all, no one naps but old people and babies, right?), study after study has shown that caffeine is no better than breaks! This is counter to soceity’s (and the software industry’s) notion of problem solving – the way to solve a hard problem is to down a ton of coffee, spend 13 hours straight in front of a computer, and emerge victorious. This equating of effort and productivity is starting to be addressed in some circles (such as lean’s belief that utilization is a poor measure), but the idea of “flow” (i.e. uninterrupted work for long periods of time) is largely taken as Truth.

Linda presented a number of interesting facts that she’s gleaned from studies:

• caffeine mildly improves performance of extroverts, but decreases the performance of introverts – not good given the programmer stereotype!
• human attention span / concentration is cyclical, not continous – see promiscuous pairing and the pomodoro technique
• naps are a learned technique, and finding our your cycle of sleep (and wakefulness) can accelerate learning and development
• in 1985, Jolt cola came out with *gasp* 72mg of caffeine in 12 oz. Now? You can get beef jerky with 150mg. Caffeine has become more pervasive and is used in greater amounts than ever

How does all of this relate to an Agile conference? Linda’s conclusion is that, since one of the main principles of Agile is to make it more about the people, why do indviduals (with organizational support!) revert to a command and control style of personal sleep / wakefulness management? Why, though most software developers know Brook’s Law, do we insist on tackling a difficult problem strictly by throwing more efffort at it? She advocates a re-evaluation and beginner’s mind approach to the subject of alertness, concentration, and productivity. If you dispel the productivity myth, work to find an individual’s learning and attention span cadence, and use proven methods of productivity enhancement (breaks, naps, regular context switches, exercise – treadmill desks!) instead of disproven ones (energy drinks, burning the midnight oil, “sleep is for the weak”), you can see real and tangible improvements in both worker productivity *and* happiness.

I was only a 4-cups-a-day person for a few months (while I worked in the games industry – never going back!), but I know of several people who were in Linda’s talk, myself included, who have vowed to get more sleep, cut down their caffeine intake, and even take the occasional cat nap.