Don't Call Me a Resource, User

"Act in such a way that you treat humanity, whether in your own person or in the person of any other, never merely as a means to an end, but always at the same time as an end."
--Immanuel Kant

A user

Recently I was working closely with the users of a reporting tool I was developing, and I struggled with the term I used to describe them. It would creep into our conversations once in a while. As a developer, I wanted to call them 'users', but this seemed like a very impersonal way of speaking. They certainly didn't think of themselves as users. A 'user' [syn: buyer, customer, end user, enjoyer, purchaser, shopper] is someone who consumes products provided to them--they don't contribute anything to the product. But this should not be the way people who will use software should interact with developers. There should be many opportunities for them to direct the creation and ongoing development of the tools they use.

Thinking about this made me recall a conversation I once had with another developer, in which he objected to being called a 'resource' by project managers. "I'm not some automaton who can produce X lines of code every Y hours," he said. Managers must have some way of keeping track of who is doing what and how long it's taking, but the term 'resource' lumps together programmers, crude oil, and encyclopedias.

I don't really have any better suggestions for these terms than the ones that already exist. They are tools that serve important purposes. I was unable to refrain from using the term 'user' in the beginning of this post. Many euphemisms invented to put a positive spin on things are awkward or silly (e.g. 'sanitation engineer' or 'right-sizing'). Furthermore, if becoming more specific about who people are involves demographic terminology--e.g., how single, over-45, white females use a product--I doubt this is much of an improvement. Finally, 'using' something isn't always a bad thing. It can connote invention and creativity, like when you use a tool to do something it wasn't designed to do. But it's worth reflecting on the words we use when we talk about people.

A resource

Perhaps what's more important than the words themselves are the ways we use them. Immanuel Kant's first formulation of his Categorical Imperative is: "Act only according to that maxim whereby you can, at the same time, will that it should become a universal law." But he also stated it in the terms of the quote at the top of this post: Don't use people as means towards ends. When we use impersonal terms, I wonder if we are any more likely to do so.  I suspect that following the Categorical Imperative involves developing relationships and practices so that, when you say 'user' or 'resource', you don't treat people like mere users and resources. How do you use 'user'?

On Leadership

"Leadership" is one of those words that used to make me cringe.  I couldn't see how it could be defined, measured, or taught.  I associated it with being a manager, something I haven't pursued--just like I haven't read Dale Carnegie's How to Win Friends and Influence People.  Becoming a leader, I thought, involved spending time away from the things that interested me most.

But, according to technical management guru Gerald Weinberg, leadership is "the process of creating an environment in which people become empowered."  A leader is someone who helps people solve problems.  It's not necessarily a manager.  The managers in your company might rarely or never be leaders--for example, if they primarily assign mountains of paperwork, engage in political infighting, or micromanage all work.

This is a powerful thought, though obvious once you've had it. A leader cares not only about their own work but helps other people get things done.  Of course, most work today is so dependent upon other people that it would be hard to get anything done without empowering others.  Being an effective leader seems synonymous with being an effective doer.

Weinberg suggests that leaders empower people to solve problems in a number of ways.  One important way is helping people understand problems and possible solutions to them.  Some people are leaders because they're great at getting to the root of a problem and convincing others that they're right.  Or, they can tell you why something you thought was a problem really isn't one.  Or, they come up with solutions that no one else has come up with.

Some of the best insights I got from the book involved interacting with coworkers.  Weinberg has found that attempts to help are often perceived as interference.  This is why it's important to ask whether or not someone needs your help.  I know people who are so eager and so full of ideas that they often cause those they were trying to help to stop listening.  "We're just trying to solve X, and you bring up 10 other things we should be doing!" they're thinking.  Similarly, when you can't understand why someone is acting a certain way, it's often best to assume they're really trying to help you.

There are plenty of nuggets in Weinberg's work, but something I'm going to try to work on is communicating my feelings, something I've never been great with.  Since you can never know how people see you or what they are thinking, your communications should not assume either.  That is, you shouldn't say, "I know you are having trouble completing your work because of issues you're having at home."  Instead, Weinberg suggests beginning with something more like, "I'm feeling frustrated that we're having trouble completing projects on time.  The only thing I can assign my frustration to is your frequent absences.  Is there something we can work out?"  This risks becoming psychobabble akin to "I feel that you feel that I'm feeling you're feeling, etc.", but I'm going to give it a try.

The Visual Display of Quantitative Information

What is to be sought in designs for the display of information is the clear portrayal of complexity. Not the complication of the simple; rather the task of the designer is to give visual access to the subtle and the difficult--that is, the revelation of the complex.
--Edward Tufte

If you're serious about data, you should be serious about charts.

Like many IT professionals, I once scoffed at charts and reports. These were for polluting PowerPoint presentations, cluttering inboxes, or bringing an end to too many trees. I certainly never wanted to be a reports writer, the lowliest of all data professionals.

 But if a picture is worth a thousand words, a good data graphic is worth tens of thousands of data points. It displays the relationships between numbers in a manifest way. It reveals causality and correlation. It shows at a glance the reasons behind the numbers.

6 kinds of data in one image = Joy

 I've had users cry with joy at the sight of a chart. This is often hard for us IT professionals to appreciate, since we secure, transform, and display data, but often don't really understand what the numbers mean. It's also hard to appreciate the power of a chart when you can write a query to get whatever you want.

But I think the main problem with taking data graphics seriously is that they are so frequently abused. They display small and unrepresentative data sets, using more ink (or pixels) than words would need. They are cluttered and sensational, meant to grab the eye rather than convey information. They are meant to supplement a lack of data rather than complement an overabundance of it.

Perhaps the only good pie chart

A data graphic should assume that its viewer cares about the information it reveals. Any principles that could be outlined are secondary to this maxim, but I'll note a couple here.

-Use only as many graphical dimensions as you have dimensions of data. For example, do not use 3D graphics to show pure quantities

-Erase or omit any graphics that do not show the data

-Make your grids and axes show data points, not arbitrary periods

Admittedly, the architects of the charting software you'd use to create data graphics have absorbed Tufte's ideas. I have not seen too many Excel charts that made me weep. But it's worth studying the history of data graphics, comparing good and bad graphics, and trying to understand the difference between the two.

Links:

-Tufte's seminal book

-Jeremiah Peschka's suggestions for letting the users make their own reports
-DataVis's gallery of charts, good and bad

"I'm about a 7"

Many people (and sociologists!) have noticed that, when you ask someone to rate themselves on a scale of 1 to 10, they give themselves a 7 typically. It doesn't matter what it is.  For example, if you ask someone to rate how well they drive, they'll say 7. I've been in interviews where candidates are asked to evaluate their SQL skills, for instance, on a scale from 1 to 10. Their answer? "I'm about a 7."

 If everyone says they're a 7, one inference to make is that people are not objective when it comes to things close to them, like their children or their own skills. This is sometimes called the 'Lake Wobegon Effect', named after Garrison Keillor's fictional hometown in which 'all children are above average'. You can't trust people to rate themselves, it is inferred. That's why driver's tests, SATs, and other methods of evaluation were invented.

 But another, often-overlooked inference is that people value different things differently. You might value driving fast, while I might value driving safely, or in a way that shows off my car, or in a way that is fuel efficient, or in a way that doesn't remind me of a terrible accident I once had. Since driving can be many things to many people, they answer in terms of what driving means to them when asked abstract questions like, "How good are you at driving?" The reason people are a 7 at SQL is that they know enough to be able to do their jobs, but they could always learn more. There is no absolute standard of SQL-ness that they could rate themselves against. They're a 7 at writing reports, performance tuning, deploying code, or whatever else their (previous) job entails.

9 for fight scenes; 2 for plot

I think this second conclusion is more interesting and more useful. It has consequences for the ways we assess skills, since we never care about someone's skill in general--whatever that might mean--but rather their ability to perform a certain job. They should be asked questions particular to that job, and, if possible, they should demonstrate those specific skills in interviews.

The realization that people value different things differently is also important in everyday life. We'd have a lot fewer arguments about whether or not someone is a good driver, teacher, or cook, or whether or not something is a good movie. Or, at the very least, we'd have more concrete arguments.

And, maybe sociologists would ask us less bizarre questions.

On Certification

The start of a new year is always a good time to think about where you've been and where you're going. One thing on my mind lately has been certification. I earned five Microsoft certifications in the last year and a half, and I could get a few more, but I was not sure it would be worth the time and the effort. After much deliberation, I decided that I would round out my .NET and SQL certifications for the following reasons.

It's official

First, the exams are great for resumes. Let's face it--the people looking at your resume first are not going to be programmers. Certifications are one more thing to help you stand out, both because they show a knowledge of subject material and a drive to succeed that extends beyond the standard working hours. Furthermore, the exams prepare you for the technical portion of interviews. If you're up for a database job, and you can talk at length about partitioning, pivot statements, statistics, message queueing, server specs, and maintenance plans, you'll be a very strong candidate, no matter how much experience you have.

But the main reason I decided to keep at it is that certifications focus your studies. It's easy to read random programming books on a lot of different subjects, but you're not likely to retain the knowledge if you don't have to prove it in some way. This is the whole reason college was invented. One way of proving yourself after college is through side projects. Another is certification. Of course, whatever you can do to stretch yourself beyond your comfort zone is a good thing. I do this in a variety of ways, one of which is certification. (This blog is another!)


Another kind of certification
Some people scoff at certifications, and they're not always worth the effort. Make sure that a test will actually be relevant to your work, or at least the work you hope to get. Even though I code a lot in ASP.NET, the .NET Web Applications Development exam was not very useful, since I don't do much JQuery or MVC. It was hard to practice the materials, and I doubt I've retained much knowledge. Make sure you understand what skills are being tested.

One shouldn't forget the cost either. None of the tests have been easy, and failing them can be pretty costly, in terms of both time and money. I know plenty of very smart people who just aren't great test-takers. The whole process can be very frustrating, starting with figuring out what test you should actually take. But it should get easier after your first one.

Are there any other pro's or con's I missed?