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.

Last night I went to the most recent VanDev talk, “How to Fail (and look good doing it)”. Matt Walters‘ presentation covered what to do when things go wrong, stressing that yes, things always go wrong eventually.

Matt’s talk was a summary of the actions and mindsets of successful managers and leaders when faced with failure. Failure can be anything – a bug that escapes to the wild, an embarrassingly bad product review, or missing data on the production server. A good leader knows how to handle such situations, deflect blame from the team (and onto himself), manage expectations, and come out at the end with the respect of his team and everyone else in the organization. Matt stressed the culture-changing effect such responsibility can have in an organization.

The presentation really resonated with me, since I’ve been thinking about many of these topics recently anyway. I mentioned the similarity of Matt’s approach and the Christopher Avery’s Responsibility Process, which he hadn’t heard of (good ideas arise independently!), and the organizational learning aspect reminded me of Declan Whelan’s Agile Vancouver talk as well. The questions and discussion after the presentation were spirited and interesting, more of a round table than a traditional Q&A. There were skeptics and believers, and I think everyone got something out of the conversation.

Like the last time I visited VanDev, I stayed for an hour after the talk was finished, chatting to various people in the local software community. There was a good cross section of people (product managers, project managers, developers, testers managers), and everyone seemed interested to learn. I don’t know what January’s talk is about, but I’ll very likely be going – unless I’m snowed in, of course.

Since I’m not feeling particularly inspired to write about any specific topic today, I’m going to go with the daily writing prompt from the NaBloPoMo website and link to a few blog posts / articles that I’ve liked this month.

• Ze Frank’s Guide to Quantitative Easing

I’m an armchair economist at times, and I love a good Jon Stewart-style political mocking. In this video (a take-off of the iPhone 4 v. Evo 4g video that was popular a while back), we are introduced to the concepts behind quantitative easing. It’s pretty funny and worth a watch if you know anything about the banking system.

• Breaking The Web’s Cooking Jar (Coding Horror)

Jeff Atwood is a bright guy, and I love a programmer who knows how to convey technical topics (both simple and complex) to non-technical users. In this post, he discusses Firesheep, a Firefox plugin that has trivialized session stealing. He describes what’s going on, why it’s not a lot different than what’s been possible for 15 years, and what you can do about it.

• Deadly Terrorism Happened Before 9/11 (Salon)

This Salon article does a good job comparing the terrorism events of the past (and the reaction to them) to the knee-jerk, over-reactions of today. An interesting read if you’re the type that grumbles about not being able to bring a 200mL bottle onto a plane (while being allowed to bring ten 100mL bottles), or if you think that security should have less of a theatrical component.

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.

For the past two years, I’ve been managing a software team. This role has a lot of requirements, and I think I’ve been fairly successful, but there’s one thing I used to do that I never really do any more – program. Sure, I review a lot of code, and occasionally pair with people or help problem solve, and when asked I give my opinion on architecture, but it’s been a while since I’ve sat down with some code to myself and tried to get something done.

Well, I’m trying to change that. I’ve realized (through a few false starts) that I’m not going to pick up a new programming language, hop into an open source project, and start contributing. I think I have the ability to do so, but definitely not the motivation. Instead, I’m going to chip away at small improvements in my product’s code base that will hopefully make life easier for my team. For now, I’m going to stay away from changing a lot of production code – I want to ease myself back into the groove slowly, and while I’m not afraid that I’ll write a bunch of awful code and ship to customers, I don’t want to get too bogged down in our automated test rig at the moment.

I’ve got two little projects going on right now. The first is to add Perl::Critic tests to all of our packages. Perl Critic is a highly configurable automated code style critic, inspired by Perl Best Practices, that can help you detect all sorts of wrongness in your code. It’s easy to add a test, and then a lot of fun (for various definitions of “fun”) chasing down all the failures and getting your code up to snuff. I’ve only added the test to one package so far, but it’s a package with over 100 files so it took me a while to clean up. Subsequent packages should be easier, and it should be self-enforcing going forwards (as all of our tests are required to pass before a build is produced).

The second project is to ease our use of CPAN modules by rewriting part of our build system to use cpanminus. Our current system makes it difficult to import CPAN packages, or even upgrade the ones we have easily, so I think this could really benefit us. Replacing some of the packages we’re still using from 2002 would be most welcome, and there’s a lot of exciting stuff being developed for Perl right now that would be ncie to experiment with. So far I’ve got just been playing around a bit with cpanminus, but I’ve already managed to find a bug (I think – I’ve filed it anyway). I may write more on this once I’ve got it working.

These aren’t exactly monumental bits of code I’m fiddling with, but it feels good to get back into it, and the important thing is that I’m actually motivated to do this coding. I have no desire to go back to being a full time developer, but it’s nice to keep up my technical skills.

A quick Google chat with a friend of mine today about his company’s implementation of Kanban got me thinking – how many people out there who say they’re using Kanban actually know what it is? They may know there’s a board, and maybe some limits, but is that it? Of course, I can’t change what people in general think, but I can certainly work to influence those around me. This post is part of that effort.

Kanban is pretty simple (with respect to core rules / definition), but it’s not as simple as “just put up a board and some numbers.” Just visualizing your workflow can be a catalyst for change, but a Kanban system needs more than that. Straight from the horse’s mouth, the core practices of Kanban are:

1. Visualize the workflow
2. Limit Work-in-progress
3. Measure and Manage Flow
4. Make Process Policies Explicit
5. Use Models to Suggest Improvement Opportunities

This is coming from the guy who literally wrote the book on Kanban and has toured the world popularizing its use, training people, and watching Kanban successes and failures.

My friend’s company routinely violates WIP limits (“it’s been this way for several months” or something to that effect), and that never provokes a discussion about changing the limit or analyzing the cause of the broken limit. Product management has not fully bought into the system, seeing it instead as a generalized queue. Developers are rather independent (no development manager), and apparently sales has not been pushing for any SLAs, so no one has bothered to analyze flow, measure lead / cycle time, or anything else that can drive toward systematic improvement based on what the board is telling them.

Now, this is not to pick on my friend’s company – he’s a bright guy, as are others he works with. I’ve seen this within my own company as well. I routinely walk by other people’s Kanban boards and say “Hrm, WIP limit 4, 5 items – what’d you decide to do about it?”, which usually prompts some action. Some teams are trying to implement specific policies / standardized work, and I’m the only one that I know of trying to analyze lead and cycle times. Even there, I’m not doing everything that I could do. And yet, I still here Kanban being touted throughout various bits of the organization as “the next big thing”.

Why does any of this matter? Well, it doesn’t, really. Unless, of course, you actually want to get the most out of your system. Presumably, these teams adopted Kanban for a reason – they liked the idea of flow, had seen success stories, and wanted to see what they could do to improve their organization. Is that not still the case? Using Kanban “properly” isn’t that difficult technically, it just requires a bit of buy-in, social capital, and a willingness of people to examine the situations they find themselves in and look for improvement. It doesn’t personally bother me if you’re doing Kanban “wrong”, any more than it would bother me if you were a birth-control using Catholic or a beer-swilling pork-eating Muslim. I just think that Kanban, when used properly, can be a very powerful change catalyst, so if people have a passing interest (enough to adopt the term “Kanban”, at least), I’ll help them out if they want me to.

As previously mentioned, I’ve got a talk coming up for a UBC class. This is the required software engineering class in the UBC Computer Science program, and a class I vividly remember as being a waste of my time. Fortunately, the course content has changed quite a bit since I took it – after four months in this class, I came out with a 25 page specification package and no code written. It was one of my least favourite classes, and it convinced me that I didn’t care at all about process (how things have changed!).

I spoke at this class during the summer, but I plan to deliver quite a different talk this time. Part of this is time – this summer I had two hours, and two weeks from now I have half that. Time isn’t the only factor – the more fundamental difference is in the content. While the talks I’ve given to previous classes before have been rather broad overviews of Agile (and more recently Lean) concepts, this time I’m going more with what I know best. That means less theory, and more description of how my team successfully delivers software. I’ve talked to the class instructor about this and she also thinks it’s a good idea.

I’m still finalizing an outline, and I need to make sure I present this at a level that’s approachable to a class of students who likely have no real (professional) software development experience. I also hope to find time to polish my slides, and make sure I’m not just reading list after list of bullet points, but I’ll have to see what time permits.

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.

Although it’s no longer seen by many as a fashionable language, Perl is the first language I worked with professionally (outside of internships) and the language that I feel the most comfortable with. Although I still like Perl, I haven’t really kept up on recent developments, and my company has never had a culture of using the latest and greatest perl modules. Additionally, since I’ve only used Perl in one environment, there’s a lot that I’m sure I’m missing out on.

Lucky for me (and other Perl hackers out there), there’s a book that’s just been released that can help bring me up to speed on what Perl looks like these days - Modern Perl, a free PDF created by chromatic. While I’ve only had a quick skim of the book, it looks to be an introduction to Perl as it is today, not as it was 10 or more years ago (which most books tend to focus on). There’s ample usage of CPAN modules, and the section on object-oriented programming leads off with Moose, the post-modern object system for Perl.

While this book doesn’t seem to dig to deep into the internal workings of Perl, it’s definitely a book I would recommend for someone looking to pick up Perl for the first time, or someone who first learned the language a long time ago and still considers it to be little more than glorified shell script (if you’re calling methods as &method(), this is you!). Perl is undergoing a renaissance with its advanced features, so it’s great to have a book out there that can draw beginners into the new stuff as well.