How to Talk to Humans

I have a natural aversion to buzzwords like 'leadership,' but I've come to realize that it's just another word for 'problem-solving'.  In a recent training, I was taught that leadership is primarily about dealing with emotions, both yours and your co-workers.  After all, it's hard to solve problems if you can't work well with others, and this involves messy emotional stuff.

Thinking that my ability to deal with emotions might be due to being dead inside rather than being empathic, I decided to read How to Talk So Kids Will Listen and Listen So Kids Will Talk, another Jeff Atwood recommendation.  I don't even have kids, but this seemed like a better alternative to books like How to Win Friends and Influence People.

What's really great about HtTSKWL&LSKWT is that shows why it's so important to give recognition to the emotions people experience.  Imagine, the authors suggest, you have a bad day because your boss chews you out in front of your co-workers for not completing an assignment on time.  Later, you run into a friend and tell her what happened.  What are your reactions to her possible responses?

1. Denial of feelings:  "There's no reason to be upset.  It's not a big deal."
2. Philosophy:  "Shit happens.  Deal with it."
3. Advice:  "You know what you should do?  You go to your boss's office and tell her about it tomorrow."
4. Questions:  "What did you do to make her so mad?  Wasn't there some reason?"
5. Defense of the other person:  "I can understand why your boss would be so upset.  You're lucky you didn't get into more trouble."
6. Pity:  "Oh, that's so terrible.  I feel so sorry for you."
7. Amateur psychoanalysis:  "Bosses are stand-ins for parents.  You're not getting back at mommy by handing in your work late."

What these responses have in common is that they all deny the reality of an emotion.  They try to get past it.  But that reality is still there for the person feeling it.  When you deny an emotion, you deny a person's reality.

You'll probably agree that the only good response is something like the following.  It shows that your friend recognizes the emotion you're feeling.

8. Empathy:  "That must have been rough--to have been called out in front of all those people.  You must have been really upset!"

In order to provide an empathic response, you need to listen with attention, acknowledge the feeling, and give a name to the emotion.  Perhaps later, you can provide advice, but don't be too quick to do this.  If you start trying to problem-solve before you recognize someone's emotions, they will probably feel like you haven't listened to them.

Another important thing I realized when reading this book is that the emotion isn't the person.  No one wants to have negative emotions, but it can't be helped.  Emotions just happen.  I think of them as a separate entity entirely, or a different system from the well-reasoned, conscious person we all want to be.

Once I started trying to recognize other people's emotions, I noticed that they felt like I was listening better.  In fact, I was.  It's not just a bunch of psycho-babble, akin to 'I feel that you feel that I feel, etc.'  I actually started to empathize better with what others were feeling.  When you say, 'It must have been hard to be chewed out by your boss,' it's hard not to imagine how you'd feel in the same situation.  Moreover, I started being able to label my own emotions better.  I even once had an epiphany, 'Oh, I'm feeling stressed out!'

Technical Problems and People Problems

'The major problems of our work are not so much technological as sociological in nature.'
-- Tom DeMarco and Timothy Lister

Not the catchiest title

Why is a 25-year-old computer book still as important today as it was 1987? You're not likely to read a programming book from the 80's in order to learn anything useful for your job today. In fact, one of the small hardships of being a serious developer and spending much of your free time improving yourself is that every book you buy is out of date a year after you buy it.

So what's so great about Peopleware? Despite the constant changes in technology, there is an element of development that has little to do with technology and that will never change. It's people.

Check this out. DeMarco and Lister analyzed hundreds of failed projects over a decade and found that in all cases there was 'not a single technological issue to explain the failure'. This is a remarkable fact. Very few developers are dealing with bleeding edge technology that may or may not live up to the job. Most of us are just solving problems with other smart people. Coming to agreement about what the problem is that we need to solve is the hardest part.

Peopleware is written with the manager in mind, but, since leadership is not synonymous with management, it can still help you work on a team successfully. It can also help you determine if your current or future boss is a good manager. As DeMarco and Lister write,

'Most managers are willing to concede the idea that they've got more people worries than technical worries.  But they seldom manage that way. They manage as though technology were their principal concern. They spend their time puzzling over the most convoluted and most interesting puzzles that their people will have to solve, almost as though they themselves were going to do the work rather than manage it. They are forever on the lookout for a technical wiz-bang that promises to automate away part of the work. The most strongly people-oriented aspects of their responsibility are often given the lowest priority.'

One big problem with IT management is that most developers become developers because they like development. If they have the leadership abilities to become managers--or if they get promoted anyway--it's hard for them to help themselves from getting involved in technical problems, to the detriment of the sociological or people-issues that they should be dealing with. It's just too easy to fall into those old habits. I think I could be a good manager, but I know that I like development so much I'm not sure I'd be willing to give it up--at least not any time soon.

'Democrat' and 'Republican' have become dirty words--hopefully 'Business' and 'IT' haven't done the same in your office

Of course, it's not only in IT that people tend to ignore the sociological or people element. The same thing happens in politics all the time. In my work at the Kettering Foundation, I saw that people will almost always try to talk about technical fixes rather than getting down to discussion about trade-offs, winners and losers, and sacrifices. We trade 'solutions' (small government or big government), but we don't really talk to one another about what we'd be willing to give up to get what we want. We don't discuss what we want health care or immigration reform to do, but we have no shortage of technical fixes to make the problem go away.

Even when we know what the solution should be, like a two-state solution for the Israel-Palestine conflict, we often have no idea how to go about doing it. That's because solving people problems is a lot harder than coming up with technical solutions. What we can do is a whole lot easier than how we're going to do it. For this reason, Peopleware is going to stick with me a long time.

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.

Technology and Collective Problem-Solving

"Technology" signifies all the intelligent techniques by which the energies of nature and man are directed and used in satisfaction of human needs; it cannot be limited to a few outer and comparatively mechanical forms.
--John Dewey

In a previous post, I explained how many philosophers, including Heidegger and Marcuse, see a rift between ethical reflection and technology. They worry that the means-ends thinking at the heart of technology can cause us to ignore other kinds of reflection--especially about who we want to be, what we hold to be just, and how we can lead more meaningful lives.

There is obviously a difference between painting a picture and developing a manufacturing plant to make paints and brushes, but what's wrong with solving problems? Is it really so dangerous as philosophers--who aren't typically known for being technologists--seem to think? John Dewey says no, arguing that all inquiry has a technological component insofar as it is meant to solve problems. If moral inquiry helps us solve problems, it's as technological as lasers and airplanes are. Theories are just tools for solving problems.

Understanding technology as problem-solving may seem impossibly vague, but it's actually very powerful. Whenever considering a new gadget, theory, or way of doing things, Dewey suggests we ask: what is the problem this is meant to solve? Remarkably, many new products don't seem aimed at solving any problems, or at least not any serious ones.

What about the problem of collective decision-making? Humans have created two lasting technologies for this purpose: representative governments and markets. Governments are good at ensuring certain behaviors that its people think should be ensured. They define and enforce justice, including the means of determining what justice is. This wasn't always the case and took many years of trial and error. Life used to be filled with a lot more anxiety, because the world was so much more unpredictable, and the means of determining fairness were uncertain.

Althingi, where Icelanders have solved problems since 930 CE
Governments, however, can only solve certain problems. They're bad at picking market winners, for example, and they're slow to react to change. They are good at prohibiting certain behaviors, but it's hard for them to make citizens moral, healthy, intelligent, or cultured. As Cass Sunstein argues in his book Nudge, the best governments may be able to do is incentivize certain behaviors so that people will make the right choices on their own.

Markets, on the other hand, provide a highly responsive way of determining what people value and what should be produced. As Friedrich Hayek recognized, markets aggregate people's individual choices and values and thus collectivize intelligence in a very efficient manner. Markets will always have the input of more people than governments as well as higher levels of participation. And, since people often know what they want better than 'experts,' markets can be more rational than governments.

Unfortunately, many things cannot be quantified in dollar values, such as the environment, health, or justice. We can adjust markets so that they take hidden costs into account, as cap-and-trade systems do, but these work best when you have a metric that can be easily tied to cost. Another criticism of markets is that people do not always act rationally, as Daniel Kahneman and other behavioral economists have shown. Even if we know what we want, we can't be sure to act accordingly.

Given the limitations of governments and markets, Deweyans turn to small groups for salvation. There are many interesting examples of small-scale collective problems solving, such as the rebirth of Pittsburgh or river management in Mexico, but it's hard to see how such solutions will scale. As our interactions become ever more global, we need globalized methods of collective decision making.


For these reasons, Clay Shirky and other technologists point to the internet as a possible third way of making intelligent choices collectively. It's not enough to say that the internet connects people. The idea of the internet as a 'Global Village' has become a joke, as new technologies help us filter each other out like never before. What Shirky points to is the way the internet lowers barriers to participation. Shirky's poster child is Wikipedia, which, like most internet phenomena, displays a long tail of participation. Many people work together, though the vast majority only contribute a little.

Lowering barriers is great, but it is probably not enough if we are to find a third way to compete with governments and markets. Can new technologies help us better solve collective problems? The question becomes ever more pressing as big players like Google, Microsoft, and Facebook become ever bigger and structure the ways we interact more and more. Not being evil is not the same thing as providing venues for increasing collective intelligence. What other problems should we be trying to solve?

Some Questions Concerning Technology

After you work with computers for a while, you stop asking what acronyms stand for if you know what's good for you. The answer is always long and pointless. SQL is hardly a Structured Query Language. GNU is not exactly Not Unix. And Microsoft comes up with a new three-letter acronym (TLA) every week. Luckily, most companies have turned their IT departments into just Technology departments, so we have only one letter to worry about. Though it may be a pursuit both long and pointless, I've been thinking about what technology really is.

There are two standard ways of understanding technology. One is that it's the essentially human activity. Monkeys use sticks and bees build nests, but humans take tool-making to an unprecedented degree due to their clever brains, opposable thumbs, and upright posture. Various intellectual revolutions have taken humans farther and farther from their natural state.


Another way of understanding technology is as applied science. Wikipedia says technology is "the making, usage, and knowledge of tools, machines, techniques, crafts, systems or methods of organization in order to solve a problem or perform a specific function." While science can be pursued for its own sake and without a clear view of its potential application, technology is the use of knowledge for specified ends.

There are a few problems with these definitions. For example, if technology is just part of what we are, then why do people often rail against technology, as happened in the industrial revolution, or after Hiroshima, or in today's world of hyper-connectedness? If you say technology is "natural" or "human", then it's hard to explain why some technology is good and some technology is bad.

Similarly, if technology is just problem-solving, then why does it have so many unforeseen effects? It often seems that new technologies create as many problems as they solve. In The Social Network, Sean Parker says they can't monetize Facebook because they don't even know what it is yet. Technologies as simple as email have changed they way we live--they don't just scratch an itch.

In a characteristically gerund-filled essay, The Question Concerning Technology (1954), Martin Heidegger tries to overcome these obstacles and get at the essence of technology. First, he distinguishes between the production of technological artifacts and the way of relating to things that makes their production possible. It is only when humans treat things (e.g., the sun, information, and even other humans) as means to an end that we can create technological solutions. For example, when a river is understood as a means to an end, it can be dammed to produce power. It can be understood in other ways, (e.g., a thing of beauty, a shape, a manifestation of God, etc.), but such thinking doesn't help solve problems and is thus not technological. Heidegger argues that technology, or technological means-ends thinking, is what makes modern science possible, not the other way around.

Neither science nor technology are necessarily bad things, but it's easy to take means-ends thinking as the only appropriate way of relating to the world around us. Today, as Heidegger points out, it's hard to take seriously Aristotle's four causes (material, teleological, formal, and efficient), since we are so used to thinking in terms of efficient or means-ends causality. On this model, we think we can predict the future with exactitude (given enough information, all things being equal, etc.), and even God becomes merely a watchmaker who set off the chain of causes that is the universe.

So if technology isn't a set of gadgets or the things people do to make those gadgets, if it's a way thinking that often occludes other ways of thinking, what then? It's worth noting that this definition solves the problems with the other conceptions of technology defined above, since technology is not just something humans do--it's one of many relationships we can have with other people and things. We might be able to judge the new possibilities technology makes possible, but not technology as such.

Most importantly, Heidegger's understanding of technology as means-ends thinking points to the need for other ways of thinking--aesthetic, cultural, social, ecological, religious, political, ethical, philosophical, kinesthetic, you name it. I'm often turned off by tech news, because it reinforces the culture of buying the latest disposable gadget instead of the development of truly important solutions. Rather than fleeing from technology as some Luddites do, we need to imbue technology with the real world technologists often ignore. I like my smartphone, but it's a far cry from the future envisioned by the prognosticators of the 1950's.

Links:
-Heidegger's essay in a more-or-less readable format
-Herbert Marcuse's essay on the political ramifications of ubiquitous means-ends thinking

Pragmatic Programming

I'm a big fan of Andy Hunt and David Thomas's Pragmatic Programmer (2000) and the series of books they publish at the Pragmatic Bookshelf. You might think this is because I wrote my dissertation on John Dewey, a famous member of a group of philosophers called the American Pragmatists. To be sure, philosophical pragmatism has a lot in common with what we commonly mean by the word "pragmatic." For instance, the Pragmatists thought traditional philosophical questions were abstracted from the problems they were really meant to solve. Philosophers asked "What is the beautiful?" without working with artists who were trying to make more beautiful art. They asked "What is the good?" apart from the moral dilemmas of actual people. And they tried to define "What is truth?" in abstraction from rival truth claims.

In short, philosophical pragmatism eschews head-in-the-clouds questions and focuses on solving problems. Any reflection that is not grounded in solving a problem risks being disconnected from practical consequences. It might even make us worse at solving problems by narrowing our thinking by theories that are untested by experience.

Though there are dangers to pure theory, I find most technical books (and blogs) to slide too far to the other side of the spectrum between theory and practice. These books are often written in the form: "If you want to do X, do Y." If you want to build an index on a table, here is the command. If you want to inherit one class from another, use this syntax. If you want to create a web service, you must create this kind of a connection. Such books are often so focused on the trees that you never see the forest. They are pragmatic in the sense that they don't give you a bunch of high-falutin' theory that you'll never use, but they aren't really pragmatic in the sense of helping you solve real-world problems.

Why is that? Technical books are often useless because they assume you know what the problem is, and anyone involved in software development for long knows that this is rarely the case. If I know that I need to create an index on a table, I can read a tutorial on creating indexes. But maybe what I really need is to write better queries. Or perhaps I need to normalize my table architecture and make more use of clustered indexes rather than throwing non-clustered indexes at performance problems. I might be using a relational database when I should be using a document store. It could be that my company's code review process needs to be improved so that issues like this are handled by database programmers and not our support staff. Perhaps performance isn't even what I should be worrying about, and the biggest problem facing my company is writing more robust code. Once you start to delve into even the simplest of problems, you can open a Pandora's box of other questions that change your understanding of the matter at hand. The reason I like the pragmatic programming books is that they go beyond the nut-and-bolts approach and provide us with concepts to help us better prioritize and deal with the problems we actually face. In an ideal world, everyone would write perfect code. But in the real world, we are always in the process of improvement, and we need conceptual tools to determine what is most in need of improving.

One of the best recent examples I've seen of the kind of truly pragmatic conceptual tools I'm talking about is Brent Ozar's hierarchy of database needs. We all know that our databases could be more secure, robust, and responsive, but what should we focus on now? Well, if we aren't backing them up, we need to create a maintenance plan ASAP. Then we can worry about security, and so on. The point here is not that Ozar's hierarchy is perfect. As he himself says, the problem with doing backups isn't that we don't know we should be doing backups (I hope); the real problem is that the technology and business groups haven't worked together to prioritize what is most important. And a major cause of such a communication breakdown is the lack of a vocabulary to describe the problem the teams face.

I haven't seen a hierarchy of generalized software development needs, but Hunt and Thomas provide many tools to help you and your team develop your own. The base of the pyramid might be having a version control system, and then a ticketing system could come next. In the middle we'd want to make sure our code is orthogonal, or highly de-coupled. Finally at the top we could turn to documentation. Priorities will vary from place to place and from time to time, but without a language to talk about them, we cannot intelligently decide what to do next.