Archive for February, 2009

Body Language

Wednesday, February 25th, 2009

Not everyone says what they mean, but according to Navarro and Karlins in What Every Body is Saying, our bodies are more truthful. Apparently people are prone to look at faces first for meaning when they should be looking at the feet, torso, arms, stance and posture. The central idea of the book is that our physical actions are governed by our limic system which controls the fight or flight response. If you didn’t like someone, you might unconciously lean away or turn your feet away from them. If a person puts you at ease, you may find yourself copying their posture, e.g. crossing your leg in the same manner they did. Recently, I saw someone report a delay to a manager. The manager suddenly dropped their cell phone, thinned their lips and looked to their left for 10 seconds, a clear indicator of the manager’s emotional state. Because it was a departure from the previous behavior and occurred in response to a statement (“the project will be late”), I could make a compelling case that the manager was upset even though no displeasure was registered verbally. The book trains you to use body language as a way to make educated guesses on the emotional state of people. You can’t tell if people are lying, but knowing if they are anxious, upset or pleased can help you communicate effectively. The book is well-written, contains copious case studies and citations which makes interesting and credible reading.


Do Cubes Make Sense?

Monday, February 23rd, 2009

The people who need solitude the most, software developers, quality engineers, etc. are working in noisy cubes with constant interruption. Meanwhile, managers, whose job is to primarily communicate and organize, have offices. Yet managers spend much of their time away from the offices, communicating to people not in their offices.  Developers who would benefit from doors to close, rarely get them. The logic is managers need doors to close to discuss private matters. In my experience, if I am closing my door a lot, I’m doing something wrong. Why businesses should give developers offices is well-covered in Peopleware, yet most developers remain in cubes.

Cubes made sense, once. In the age of mainframe computing, your IBM 3270 was not portable as it was hardwired to the server. To work, programmers needed to be at their desks. The idea of programmers working from home was not feasible early on. Most everyone in the data processing industry had a cube. Eventually we got modems, SLIP, PPP, broadband connections, laptops and now, wireless. Today, where you can sit, you can work. Beds, coffee shops, couches, air ports, trains are all potential work locations. Why do we still have cubes?

Some people like a small space to personalize that is separate from their home. For some working from home is more distracting than in a cube. Some people like the distractions and opportunities to socialize with co-workers.

Many larger, slow-to-change, businesses have yet to figure out that cubes are overhead and a waste for those who don’t want or need them. Sometimes, corporate culture can be slow to change.

Companies fear that people not co-located won’t work together effectively. I’ve had employees work from home and from the other side of the world effectively. If you have competent people that are motivated, you can trust them.

What would I like to see? A quiet-as-a-library work area, with desks, chairs and couches. Near the work lounge would be numerous small rooms for teams to collaborate. Adjacent to that would be a large space where people could talk, have many white boards, sit down, eat and be noisy. However, some people may need or want a cube – give it to them. However, split some of the cost savings for those who choose less expensive options like working from home or shared work areas. I don’t see a problem with cubes, but if less expensive options exist with equal promise, why not try them?

Ironically, though, after we transition to shared work areas, cubes will become a a luxury. Imagine that.


Be a Leader

Friday, February 13th, 2009

A friend gave me invaluable advice on management: Be a leader. Managers delegate tasks, but leaders are the people you turn to when you have a problem. You want to go to a leader because you know they will help.

To me this means, I have to be:

  • Competent
  • Clear
  • Humble
  • Trusting
  • Consistent
  • Honest

And one more that’s different from the others:

  • Creative

More frequently than you’d like, you’ll be caught between upper management your team. On the line will be your team’s goal to do the great work of which they can be proud. Being creative helps you see the middle road between the black and white areas. In other words, the solution that you didn’t think of right away that gets everyone to where they want to be.

Creativity is different, because it’s the only one you can’t learn or practice. You have it or you don’t, like the ability to learn pointers – not everyone has it. However, the other traits you can learn through practice. Many people go very far that were competent, humble, etc. but not creative. Because rather than having subordinates, these leaders had a dedicated group of supporters who were always there for their leader. It’s arguable that a slightly flawed leader is easier to follow, because you feel that leader needs you.

“Be a leader,” was the most succint and helpful advice I’ve ever received.


Performance and Knowledge-Intensive Work

Sunday, February 8th, 2009

Sometimes your reports don’t work in an optimal fashion during their work day. People don’t come and go at the same time and some arrive very late. Not everyone works exactly 8 hours every day. Sometimes people work together on a task best suited to one person.

Occasionally, managers try to raise productivity by optimizing how people work on an individual level. Hard rules, like “everyone in the office by 8 a.m.” or “no web browsing not directly related to work,” are what I call top-down productivity approaches and, in software development, I’ve never seen any returns other than increased turn-over of staff. Bottom-up approaches, getting staff to volunteer improvements, works better. Near-universally, people want to make positive impacts and will try, if given a chance. Structure opportunities for people to improve their performance. A simple question may suffice, “How could we deliver more features in the same amount of time?” If the initial answer is, “We can’t,” then keep asking questions and continue to challenge them. Most will rise to a challenge.

Management must be concerned with performance, but past the workflow-level (i.e. where are the bottlenecks constraining my resource capacity?), it’s a mistake to try to organize how individuals perform tasks delegated to them. If you were managing a team whose sole job is to clean floors and there is one proven way to do the job efficiently, then directing people on how to work makes sense and saves money. However with knowledge-intensive work (e.g. software development), there’s frequently countless ways to do any task. Though you may know a wonderful way, is that the way your report can best implement and maintain? Likely not, if they did not pick your preferred method. It’s a trust issue – your reports were hired to think and if you trust them do their jobs and avoid doing theirs for them, they will be happier and more productive.


How Large Is a Short, Int, Long or Long Long?

Sunday, February 1st, 2009

How many bytes are in an int or a long? Most think int type sizes vary with platform between 2 or 4 bytes while the long integer is 4 bytes regardless. Though that can happen, that’s not how the C standard defines int type sizes.

The C standard allows the int types to vary as everyone expects, but C only defines a minimum size. The short integer must have at least 16 bits. Type int must also have at least 16 bits and be at least as large as the short integer. The long has a minimum of 32 bits. C99 introduced the long long type which has a minimum of 64 bits. For each type, the C Standard defines no upper boundary. Here’s a quote from the C99 draft standard:

The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. [...] Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

The previous passage is talking specifically about the definitions in limits.h, which, in the standard, have the following definitions:

minimum value for type short int: SHRT_MIN -32767 // −(152−1)
maximum value for type short int: SHRT_MAX +32767 // 152−1
maximum value for type unsigned short int: USHRT_MAX 65535// 162−1
minimum value for type int: INT_MIN -32767 // −(152−1)
maximum value for type int: INT_MAX +32767 // 15−1
maximum value for type unsigned int: UINT_MAX 65535 // 162−1
minimum value for type long int: LONG_MIN -2147483647 // −(312−1)
maximum value for type long int: LONG_MAX +2147483647 // 312−1
maximum value for type unsigned long int: ULONG_MAX 4294967295 // 322−1
minimum value for type long long int: LLONG_MIN -9223372036854775807 // −(632−1)
maximum value for type long long int: LLONG_MAX +9223372036854775807 // 632−1
maximum value for type unsigned long long int: ULLONG_MAX 18446744073709551615 // 642−1

The key point is the C standard defines minimum values and your platform may have different values than what the standard states, but if so, the values must be larger. The safe way to determine the minimum and maximum values for all C types on your platforms is to use limits.h, e.g.:

#include <limits.h>
printf("Minimum value for a signed int: %d\n", INT_MIN);
printf("Maximum value for a signed int: %d\n", INT_MAX);

In C++, rely on limits rather than climits. In C++, limits defines a template class, numeric_limits, specialized for each of the fundamental types (e.g. int, short, float, double, etc.). To determine the range of possible values in C++ using numeric_limits, for an int, you would do the following:

#include <limits>
#include <iostream>
using namespace std;
cout << "Minimum value for a signed int: " << numeric_limits<int>::min() << endl;
cout << "Maximum value for a signed int: " << numeric_limits<int>::max() << endl;

Good references on the topic are Harbison and Steele’s C A Reference Manual and Steve Summit’s C FAQs.