The Programmer's Apprenticeship - 05: Know Your Users

Word count: 1.9kReading time: 12 min

 2018/09/28

This is the fifth post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

I will excerpt some wonderful remarks from the book and sometimes add my own insights or experiences. The outline of the reading notes is consistent with the outline of the book itself. This is also a method I learned from another source and have been using: “How to Read a Book”. I record it for my own frequent review and for readers’ reference. Below is the The Programmer’s Apprenticeship reading note series:

The Controversy of “homo logicus”

Among all the “bad habits” of software developers, the most serious one is probably: We think we are typical users. However, what most developers don’t realize is that we are actually outliers. We are by no means ordinary people — we are margin dwellers.

The author mentions the concepts of “homo logicus” (Logical Man) and “homo sapiens” (Modern Wise Man/Ordinary User):

Logical Man: Logical people desire to control things that interest them, and those things are complex deterministic systems. Humans are complex, but they are not like machines; their behavior is not logical or predictable. The best machine is digital because it can become most complex and sophisticated, and can be easily changed by programmers.
Homo Sapiens: Ordinary users who just want to use things simply, not control them.

For logical people, control is their goal, and complexity is the price they are willing to pay. For ordinary people, simplicity is their goal, and losing control is the price they are willing to pay. Logical people are driven by an irresistible cognitive desire for how things work, while homo sapiens desire success.

Alan Cooper listed some typical characteristics of logical people. You can see if you fit:

Willing to sacrifice simplicity for control.
Willing to fail in exchange for cognition.
Do not let go of any possibility.
Behave like sports students (treating technology as a competitive sport).

Another sentence software engineers need to remember: Anyone can make a complex software that no one will use; it’s not hard! Making software simple and easy to use is the real skill. You must stop thinking like a logical person and learn to think like a homo sapiens.

Ivory Tower Development

Ivory tower development refers to: development teams locked in a “high tower” all year round, bent on making magical software. Because of the lack of strong evidence, developers assume everyone else is a developer, which is dangerous.

The author suggests: Throughout the project cycle, try your best to expose your developers to users: attend user meetings, participate in usability testing and acceptance testing, communicate with users, and analyze user data and behavior.

The “mutual trust relationship” proposed by Eric: When people buy software from you, they have many expectations for the present and the future:

They trust that your product works properly on their machines.
They trust that if they encounter problems, you will help them.
They trust that you will persistently improve the product.
They trust that you will provide them with improved versions at a fair and reasonable price.
They trust that your company will not go bankrupt in a short time.

Consequences of Letting Programmers Design Interfaces

Excellent programmers know themselves well and know what they can do and what they cannot do. They either copy existing excellent designs directly; or stick to coding and leave the interface design work to other experts.

If you are a friend, don’t let your friend create an interface that only programmers would use.

Protect “The Intermediates”

Experts and novices are only a small part of the population. Most users with similar levels belong to the “intermediates.” You should value these intermediates. The number of intermediate users is so huge and dominant that you can give up on novice and expert users if needed.

To cater to the few novices and experts, you spend a lot of time in the software development process, ultimately just making the product worse, and neglecting the core user group.

Every User Lies

Users’ wishes and reality are almost always contradictory. We advocate observing users’ actual behavior rather than listening to their narration of what they did, because of this deviation. Observation is a powerful skill. Learn to judge by people’s behavior, not take what they say as truth.

The author mentioned the concept of “active user paradox”: The active user paradox is a contradiction because if users know a little more about the system, it will save time in the long run. But in the real world, people’s behavior patterns are not like that. Therefore, we cannot tolerate engineers developing products for idealized users, because people in reality are irrational. We must design products based on users’ actual behavior patterns.

Every user lies. Expecting to ask users if they like your software – they will certainly say they like it, because saying to your face how terrible your software is would be rude – you should follow Gregory House: Observe whether they use your software and how they use it. Design your software based on behavioral data, not on the “lies” users tell (no matter how well-intentioned those lies are).

Don’t Make Product Launch the Goal

A standard for measuring whether a programmer is successful is to see how much code they have released, but just releasing is not enough. How many users are using your software is the ultimate goal of measuring success.

Smart software developers know that their work is far more than writing code and releasing products; their work is to develop software that people really want to use. This certainly includes coding, but there are also a large number of other global things, such as writing technical documentation, interaction design, cultivating community users, and even product vision. These are crucial to the overall success of the software. If you don’t even understand this, then what kind of code you wrote doesn’t matter.

Don’t Ask, Observe

What users say they want to do is often vastly different from what they actually do. From a usability perspective, asking users what they want is futile for this reason – you must observe what they are doing. In terms of usability, you cannot act on guesses; you must observe how users use your software. There is no other way.

When designing, wouldn’t it be more reasonable if decisions could be made based on how users actually use your software? Whether you are observing users in a “low-fidelity usability test” or collecting user behavior data and observing users invisibly, the purpose is the same: Don’t ask, observe.

Is More Features Better?

Software relies on new features to drive sales, but over time, those added features are precisely the culprits that make the software worse. That subtle “feature creep” that is slowly breeding – it will destroy people’s favorite software.

A bad trend is: software companies set the priority of fixing bugs in existing software relatively low, while regarding the development of new features for the next version as particularly important. The result is that the quality of the software goes from bad to worse. (Like Flyme and MIUI).

Perhaps we shouldn’t blindly measure software as a pile of features – People always have a “capacity” limit, just like at a buffet, can you eat all that food? We should be result-oriented, measuring the productivity or effectiveness of software in helping us complete tasks.

Living Things Will Do As They Please

The author believes that social engineering is at best an inexact science, even in the cyberspace prototype. Someone once said, “In the most carefully prepared experiment,” even if conditions are strictly controlled, living things will do as they please.

When building social software, people are the root of all problems, but solving problems ultimately depends on those people.

For a Little Ribbon

The author summarized his work at Stack Exchange: What I do, what I am best at, and what I love most and more than anything else in the world, is designing large massive multiplayer games for people who like to write a few paragraphs to each other. I guide their obsession to something positive; they can learn from it and create some reusable beautiful works for the whole world — this is still what I desire, because I still retain a steady stream of obsession.

The author proposed “10 Terrible Ideas”:

Fundamentally lower the barrier to participation.
Trust users.
Life is the world’s largest massive multiplayer online role-playing game.
Bad things always happen.
Preference over money.
Rules can be fun and social.
All modern websites are designed like games.
Thoughtful game design fosters sustainable communities.
The community’s point of view is not necessarily right.
Some mediation is needed.

If you want to learn something online, you must design your software well, guide people’s innate social group impulses, and refocus them on valuable things.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”