Archive of published articles on October, 2010

Back home

How to Understand the User


If you haven’t read Robert L Read’s How to be a Programmer: A Short, Comprehensive, and Personal Summary, do yourself a favor and read it. I want to highlight one sections in particular that illustrates my belief about what makes an effective technical artist/tools programmer:

How to Understand the User

It is your duty to understand the user, and to help your boss understand the user. Because the user is not as intimately involved in the creation of your product as you are, they behave a little differently:

  • The user generally makes short pronouncements.
  • The user has their own job; they will mainly think of small improvements in your product, not big improvements.
  • The user can’t have a vision that represents the complete body ofyour product users.

It is your duty to give them what they really want, not what they say they want. It is however, better to propose it to them and get them to agree that your proposal is what they really want before you begin, but they may not have the vision to do this. Your confidence in your own ideas about this should vary. You must guard against both arrogance and false modesty in terms of knowing what the customer really wants. Programmers are trained to design and create. Market researchers are trained to figure out what people want. These two kinds of people, or two modes of thought in the same person, working harmoniously together give the best chance of formulating the correct vision.

The more time you spend with users the better you will be able to understand what will really be successful. You should try to test your ideas against them as much as you can. You should eat and drink with them if you can.

Guy Kawasaki has emphasized the importance of watching what your users do in addition to listening to them.

It is no surprise this section is under “Advanced.” This is a skill that takes time to acquire and some people will never acquire it. Even more dangerous are people who think they have acquired it, but do not have developed programming skills and thus lack the ability to ‘create’ and truly solve the user’s problems. Likewise, the people who do have these technical skills but are not deeply enough involved in understanding the user’s problems operate at a fraction of their capacity. I’ll discuss more about the ‘tech art model’ in future blog posts.

1 Comment

Education vs. Technology


I was listening to NPR a couple weeks ago and there was a story about this school in Tanzania that had lots of speeding traffic in front of it and a dozen or two children were being hit every year. Apparently, the government had repaved the road in front of it, which resulted in much faster vehicle traffic, but neglected to put in a footbridge or traffic light. And apparently not enough people were being injured and killed to make it an immediate priority. The focus of the interview was a group who raises awareness about these sorts of conditions, and was at the school educating the students on foot traffic safety.

The whole situation had some analogues to software, and three in particular stood out:

1. Positive changes can reveal unexpected conditions.

In this instance, I wouldn’t call it a simple cause and effect. The effect of the cause is a few degrees removed. This change was sort of like ripping out a ton of bad code and then finding all the edge cases you didn’t account for (including software that relied on the ‘bad’ behavior in the old code). Society, like software (or rather, the people that write it), has a remarkable way of adapting to non-ideal conditions. I like to think of it as many fragile, ad hoc connections, that paving something (a road literally or a codebase figuratively) destroys. Amazing as it may seem, life and data has trudged on through these harsh circumstances. When you rewrite a system, you can probably estimate how long it will take to mimic functionality with the new system. But it is almost impossible to figure out how many systems it impacts indirectly. Make sure you budget time for these sorts of things, or you’ll quickly lose the will and capital needed to do those important refactorings and systems rewrites.

2. Biggest fires need to be fought first.

As cold as it may seem, the Tanzanian government doesn’t have the resources to spend to on the infrastructure needed to fix this problem. That includes investigating, planning, and implementing the solution, whatever it is, and dealing with the consequences (maintenance, lost traffic, whatever). From Western eyes, which have so many resources, and litigate injuries so widely, this seems out of whack (and I can’t really justify it and play the pluralist- I feel emotionally wrong and intellectually absurd doing so). But for less severe circumstances, it should serve to remind us that we often need to make hard decisions about what needs to get done. That means having to ignore people’s problems sometimes in order to achieve a greater goal. Developers in less structured environments (cough, games) can often lose sight of this. On the other hand, it is sometimes OK to do the unsanctioned extra work to do something you feel strongly about, and I know and you know you’re going to do it anyway, so there’s no point in telling you that, I suppose.

3. Education can impact things much faster than technology.

This was certainly the point that made the biggest impact on me. The person being interviewed (a male Westerner, of course) explained that, if the Tanzanian government decided to build a footbridge today, it would still be months before anything was done. However, in one afternoon they could educate a few hundred students. They could provide road safety education to all the students by the time the government put up one footbridge, very likely (my extrapolation, not his).

Education is obviously a very important piece of the puzzle for working with broken tools and systems. It is, though, something we often ignore or put off in the pursuit of better tools and procedures. In fact, I’ve often discouraged education about some things so that the problem could continue to be in the forefront! How Machiavellian! And sometimes it isn’t a bug, it is an entire broken workflow. We need to make education a first order concern in tools development. And I don’t mean how to use a tool- that is something easily taught by users, to each other. I mean, providing a system of documentation for hacks, workarounds, known issues, etc. And, it must be said, the workflow for this system of documentation needs to be problem-free and as easy to use as possible.

No Comments

Lack of updates


I am already breaking my more frequent blogging promise. I have a few posts mostly typed up but unfinished, and a few more that are just ideas. I should have time to post more after this week- I’m about to finish a big project, and my job is also changing at work, so I hope to kick out a few posts in the down time between those.

No Comments