Your job is not to “help”

Some people define their role as inflicting help on people. Don’t do this. If you are a consultant, do not define your role as helping the team. If you are a manager of a team, do not define your role as helping. If you are in business as a smart technical person do not advertise yourself as offering help. If you find yourself doing this then translate the word “help” to “annoy” and you will see more clearly.

To define your role as “helping” is condescending and passive. The ego it takes to define your role in life as helping others reflects a fundamental misunderstanding of the universe. Instead, redefine your role to define what you are individually doing, what you are accomplishing (and this cannot be helping). Then as a secondary role you can be open to providing assistance to people who request it.

Suppose you are a consultant who primarily trains teams in development processes. Do not define your job as helping teams to implement good processes. Instead define your job as providing training. If in the course of providing training someone asks for your assistance then by all means help them. By focusing on providing training rather than helping, you will focus on getting your job done rather than focusing on all the deficiencies of your client and your responsibility to fix them. You will turn your critical eye on yourself to learn how you can more effectively prepare and deliver training.

While defining your role as helping sounds quite generous and charitable it actually reveals an unhealthy, egocentric attitude.

Tell the team when you mess with a shared server

You are working on a distributed team. There are a handful of other people working on the team. You are sharing a server. When you do anything disruptive on the shared server you must tell the team.

This means you must tell the team when you do things like:

• change the system configuration
• start/stop a shared server process
• run a resource intensive operation
• start/stop the server

At some point, everyone on the team is trying to understand why the server is doing what it is doing. Often it seems the server has a life of its own. There are enough wrinkles of complexity and unexpected dependencies in the operating system and the applications and in the network interactions that it can be very hard to understand what the server is doing. This problem is compounded greatly when there is a person on the other side of the world, invisibly making changes. Now the system really does appear to have a life of its own! The other person has effectively become part of the black-box everyone is trying to understand.

So whenever you are messing with a shared server tell.

Even if it is just a dev server tell the team.

Even if nobody else is online, tell the team (they are going to come online and they are going to wonder what is going on with the server).

Even if 99 times out of 100 nobody cares about your messages, tell them (you can never tell when it will be the 1 time out of 100).

Even if everyone says they don’t care about the messages, tell them (the messages are only “un-necessary because you are sending them).

The goal is to create a virtual, shared work room. In a virtual, shared work room you could see if someone stood up from their desk and walked over to the main server and started punching buttons on it. Everyone would notice this. Even if they did not care at the moment, they would still notice and have a basic situational awareness of what is going on in their world.

So tell the team when you mess with a shared server.

Requirements, people, and monsters (part 3)

The second major system in a development effort is the team. The key distinguishing characteristic of the team is: it is composed of people. People in all of their irrational, emotional, egocentric, and goofy glory.

People are not parts. People are not resources. People do not equate simply to developer hours.

You can’t even get along with the people in your family. How are you ever going to get along with the people on your development team?

For some the answer is a stern “professionalism” that pursues an illusion of the lack of any kind of emotion and requires team members to do the same. Thus sweeping their people-ness under the rug.

For others the solution is a harsh command-and-control environment. “I am the boss, you will do what I say. I don’t care about your personal issues.”

The stereotype of computer guys is that we like “hard science”: numbers, code, engineering. Not soft things like: psychology and people and emotions. Then one day you realize the people around you form the most complex system you will ever have to work with. People are the ultimate computers. People are the most complex software system we will ever deal with. The interactions between people form the most complex systems we will ever see.

But more than that, people are the most significant things we will encounter in our computer careers.

When you realize these things you will be driven out of your computer science hole and into the field of learning about and trying to understand people. Here are some key lessons about people.

People are all the same

Everyone else is just like you. We look at another person. We have a natural tendency to think we are categorically different than they. The stupid manager who has no idea what the code is doing. Our first thought is that they are a different type of person than us. The reality is they are the same type of person as us. The fact that they look stupid to us is more about where the two of us happened to meet. We meet after the manager had gone down his management path and I down my coder path. The difference between us is based on relation to each other, not fundamental differences in the kind of person he is and the kind of person I am. In your future you will go down a similar path and be viewed in a similar light.

But, even if you never become a manager, someone will accuse you of being a stupid manager some day. In the same way that politics works. Someone is a staunch liberal all of their life. Then they say something vaguely pro-business. Suddenly they are labeled a right-wing conservative.

With that in mind, consider:

The idiot programmer who can’t figure out the API. That is you.

The slacker who quits working and leaves you hanging when the deadline arrives. That is you.

The stupid manager who is blind to what is really happening. That is you.

The hotshot kid who thinks he knows everything. That is you.

The inept programmer who created an unmaintainable mess. That is you.

The clueless project manager who is completely. That is you.

Those are all you in the sense that they are people like you who are dealing with their circumstances and trying to get through the day as best they can. Someday you will look like them to someone else.

People are all different

You learn a bit about people and you start to categorize them. People hate to be categorized (at least I do!).

People hate to be labeled.

People hate to be psycho-analyzed.

People hate to feel like someone else has them “figured out”.

It is dehumanizing. Like reducing a person down to a “database administrator”. When you pigeon-hole someone you don’t pay due respect to their people-ness.

We are all unique and must be dealt with as individuals, not just as members of some categories.

The agile movement also brought these issues to the fore.

…we have come to value: Individuals and interactions over processes and tools…

Agile brought us daily meetings where you talk to each other. Agile brought us the idea of developers estimating their own work and signing up for their own tasks. Humanizing ideas.

To summarize then:

• People are the core of the development process
• People are the most complicated and unpredictable system in the process
• People are the most significant things we deal with
• (Oh.. and we all are one)

So go learn about people. Maybe read a classic like Peopleware. Or learn from a master like Jerry Weinberg and books like:

• The Secrets of Consulting
• Becoming a Technical Leader
• More Secrets of Consulting

WARNING: These are not your typical computer books. They may take you far outside of your comfort zone.

TANSTAAFL

I think I am like most developers. I tend to like working with code. In most cases I would rather not mess with pesky users. And I certainly don’t want to spend time fighting production problems. Recently I found myself in a position where I was isolated from users and production problems. I certainly wasn’t going to complain. Although I would often think to myself, “boy, it seems like I should be talking to our users”. I ignored those thoughts and just enjoyed the isolation.

I was wrong.

That isolation has been removed and I see that all of my work suffered from working in a vacuum. Previously I was cutoff from feedback from real users. That feedback is what should have been keeping me growing and learning how to make the system better.

I should have paid attention to what I knew to be true. I should have pushed myself into the user world. I should have taken the pain in order to learn and grow.

I should have remembered Heinlein’s advice, “There Ain’t No Such Thing As A Free Lunch“.

Deliver information in a broad, shallow structure

Web sites should be broad and shallow, not narrow and deep.

Imagine a user FAQ site for a product.

It can be built to require many clicks and give just a small bit of information. Click to choose what area you have a question about. Click to choose a specific question you want answered? Then you see one answer. Maybe just a sentence or two.

Or it can be built to provide much information with no clicking. The entire user FAQ is provided as a single web page. The user has easy access to all of the content.

There are pragmatic reasons reasons why it is better to provide all of the content on a single page. Users can hit ctrl-F to search the single page of content. Users can print the page and have a complete printout of the content. This approach also requires less work. There is no need to artificially create a structure to hang small bits of content in. Rather the content itself provides the structure. For example, the questions in a FAQ become the headers for each answer.

But there are deeper reasons why a single page of content is better. It fits the way humans think. People are good at scanning through large amounts of information to find what they need. They can see patterns, pick up subtle cues, and generally use their eyes and brains to browse the information and find what they need.

People quickly become frustrated with systems that show a tiny window of data and require repeated clicks to navigate. The reason is that this mode of receiving data disrupts the user’s cognitive processes. Users experience this disruption as an unconscious frustration with the system. Users feel like they are constantly walking down long narrow tunnels trying to find what they want. Which means… people won’t like your site.

This is hard lesson for computer people to learn. We are so enamored with hierarchies we over-categorize everything.

The expert on this topic is Tufte.

Show, don’t tell - make screen videos with Windows Media Encoder

Add screen videos to your toolbox. If you are on a Windows box then download Windows Media Encoder. This allows you to record what is shown on your computer screen along with the audio of you describing what is shown.

I recorded a demo to show how to record a screencast.

This technique of “showing” is much more powerful than written words.

1. Videos are very efficient. You can capture a large amount of information in a short time.
2. You convey many details that you would never take the time to write down. Viewers see more than what you are explicitly demonstrating. They see how you use the tools and how you organize your work and many other details that you would not otherwise document.
3. Information that is seen and heard is quite memorable and can make a deeper impact than written words alone.
4. A video can be watched over and over again by many people. This makes it more powerful than merely explaining something in person. It can be leveraged and used many times.

You don’t know everything

A related pathology is the belief that you must know everything. Somebody says something to you. You have only a vague idea of what they are talking. Do you tell them that? Of course not. You say “uh, yeah” and nod your head.

Stop that.

If you don’t know what someone is talking about then say that. Ask them a question. Sure you will show you don’t know everything, but as I said last time… everyone else already knows that you don’t know everything. The only one your fooling is yourself.

Another way of looking at it is that this is your duty to make communication happen. If you don’t understand someone it is your responsibility to let them know.

Everyone else knows you are not perfect

People sometimes think they must be seen as perfect. So when they make a mistake, they try to make excuses and explanations. They want others to keep thinking they are perfect.

The problem with this is… everyone else knows you are not perfect. So when you make a mistake it is not a big surprise to anyone else. It threatens no ones world view but your own. There is no need to try and explain that you really did not make a mistake. You only make yourself look like a fool if you dance around making excuses.

Working with graphic designers

I have had the opportunity to work on several graphic design projects recently. I am working on them as a customer trying to get good looking logos, web sites, and advertisements. This is hard.

It is hard because I don’t know the principles, tools, lingo, and technology of graphic design. And my artistic abilities are not well developed. I end up in a position where I don’t know how to describe what I want. I fear if I ask for something then I will get what I asked for but not something good. I imagine this is what my customers feel like when I do software projects for them.

Here are some guidelines I am developing from my experiences with graphic designers:

1. Learn about graphic design. I have learned a small bit about graphic design. Small things like using a color wheel to find colors that go together. Making important things much bigger than you think is right, because it looks better. Paying attention to allignment of design elements. I know these are incredibly basic ideas from graphic design, but just knowing these has helped me communicate what I want. I believe that I should continue to invest in learning the basics of graphic design and this will help me get better results as I work with graphic designers
2. Be careful what you ask for. My worst fear when working on graphics projects, that I will get what I ask for and it will be bad. Find a way to describe characteristics of what you want without prescribing a solution. I know that coders thrive on being free to express their creativity in a solution. I assume that designers value the freedom to show their creativity just as much if not more. I really want designers to pour their creative energy into the projects. I need to get better at unleashing their creativity rather than stifling it.
3. Be specific with examples. One of the best ways I have found to communicate with designers is by pointing to samples of what I like. At first I would do this in a very rough manner. I would deliver a list of web sites that I liked. The problem was the work would then copy the things I did not like and ignore the things I liked. For instance, the designer might copy the layout when what I really liked was the colors. The answer is to be specific. Say things such as “I really like the banner on this site”, or “I like the font selection on this site”. I have also found it very useful to be able to point to a category on Design Melt Down. This lets me communicate a complex, rich idea with a single link.
4. Work in iterations. When starting on a project you would like to just jump to a fabulous visually stunning solution. Maybe somebody knows how to do this. I don’t. What I have been able to do is gradually increase the quality of the work. For instance, the first step is to create a first version. If you want to have a website, first you need to make a website. Create an initial version, start putting some content in, just get the project moving somewhere. Then go on the web and find some free style sheets that kind of look nice and have some aspects you like. This will produce a site that is not very compelling but at least has something. Now bring in a graphic designer, point them at the site as well as several sites you like and ask them to create a design. So far this approach of “booting” up seems to be working.
5. Roll up your sleeves and work on the project. You can’t just hire a graphics person, give them some vauge direction and expect them to create a design that delivers just the message you want. You need to work out what you want. You need to know what the main message is, you need to know what the supporting details are, you need to provide the copy to use, you need to think about what is most important. You need to pour much work and much thought into the content of the design. You are the one who knows your product, you are the one who knows your industry, you are the one who is responsible for the message.

Those are the main things I have learned so far. I am anxious to learn more about the subject though. If you are a graphic designer I would love to hear your thoughts, please use the “comment” link to send me a message.

Don’t try and look like a big company

Many of the companies hiring developers to work on the web are small companies. Small companies prefer to work with other small companies or individuals. Small companies don’t like working with large companies as vendors. It is not comfortable. Large companies don’t deliver well. Large companies try and use their size to push the smaller companies around.

Therefore, when advertising your services don’t inflate yourself to look like a big company. Don’t create web sites that look like those of the large faceless corporations. Use your size to your advantage. Keep your personality present in your communication. Dont’ say “we” say “I”.