Thursday, February 26, 2009

Mediocrity and Genius

Mediocrity knows nothing higher than itself, but talent instantly recognizes genius.

-- Sir Arthur Conan Doyle, (Sherlock Holmes) Valley of Fear, 1915
What Doyle noted nearly a century ago is now known as the Dunning-Kruger effect. It shows that people who are incompetent in areas as widespread as humor, grammar and logic are often blissfully unaware of their own shortcomings. It also shows that incompetent people are often unable to recognize genuine competence in others.

I've talked before about second-order incompetence, and about how it relates to programming. Conventional wisdom among programmers seems to be that being aware of your own shortcomings is really a sign of competence. Knowing that there are things you don't know is a sign of a wise and experienced developer.

This isn't far off the mark, but according to follow-up studies by Dunning and Kruger, it's only a first small step. The skills required for competence in a particular area are the same skills necessary to recognize competence in yourself and in others. It still takes concentrated study in that area in order to raise your competence to the level necessary to be a good judge.

Monday, February 23, 2009

Be Careful What You Measure

Paul Graham's recent post Startups in 13 Sentences got my attention with #7, "You make what you measure." If you want to improve some aspect of your business (or software, or whatever it is you do), measure it. Keep daily track of it and you'll start to notice what sorts of things cause it to go up and down. Do more of those things that make it better.

What I found particular insightful was the corollary, "Be careful what you measure." It made me immediately think of the following quote from Microsoft founder Bill Gates.
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
If you give programmers incentive by measuring the number of lines of code that they write, then that's what they'll concentrate on. It doesn't really even matter if you want more lines of code or fewer, you'll get exactly what you incentivize. Most likely at the expense of quality.

Eli Goldratt explores this idea in depth in his book Critical Chain. The relevant example in the book is a steel processing plant, but can be effectively adapted to any business. In the book, the new managers of the plant find that employees are cutting corners on quality and efficiency in order to meet their performance incentives. The managers turned the company from the brink of bankruptcy into a profitable company simply by removing the incentives. The lesson? No measurement at all is better than making measurements that cause you to focus on the wrong thing.

Wednesday, February 18, 2009

Asking Questions and Giving Answers

In 2001 Eric Raymond wrote the quintessential article on asking questions online, How To Ask Questions the Smart Way. Yesterday I think Jon Skeet wrote the quintessential article on answering them, Answering technical questions helpfully.

For anyone who doesn't know Jon, he's a programmer and an author, and he's currently the top rated user on Stack Overflow, a web site dedicated to asking and answering programming-related questions. In other words, he knows a little bit about this. Both articles are worth a very thorough read.

Monday, February 16, 2009

C++ Snippets: Print Precision

How do you print a float or a double to its full precision? By default cout only prints six digits of precision, but you can easily change that.
#include <iostream>
#include <limits>

using namespace std;

typedef numeric_limits<double> dbl;

int main()
{
double d = 3.14159265358979;
cout.precision(dbl::digits10);
cout << "Pi: " << fixed << d << endl;
return 0;
}

Use cout's precision function to set the precision to an arbitrary length. Here I used the maximum precision of a double float from the <limits> library. When I print the value, I tell cout to use the specified precision by passing it the fixed specifier.

Compile and run the snippet above and you should see the following output.
$ ./a.out
Pi: 3.141592653589790

Sunday, February 15, 2009

C++ Snippets: Time

There's been a lot of talk about Unix time lately surrounding 1234567890 day. If you read some of the recent articles you might be left with the impression that some of us actually tell time this way. Only hard-core Unix sysadmins actually do that. The rest of us can use standard C++ library functions to get the current system time and convert it to a human-readable format.

#include <iostream>
#include <ctime>

using namespace std;

int main()
{
tm* timeinfo;

time_t seconds = time(NULL);
timeinfo = localtime(&seconds);

cout << "Seconds since the epoch: " << seconds << endl;
cout << "Local time: " << asctime(timeinfo) << endl;
return 0;
}

Here I'm using three functions and one stuct from the C++ standard ctime library to get the time and display it. The time function gets the number of seconds since January 1, 1970 (the start of the Unix epoch) from the operating system. The localtime function converts the time in seconds to a tm structure representing the calendar date and time. Finally, the asctime function converts the tm stucture to a human-readable string format.

Compile the program above using g++, then run it to see the following output.
$ ./a.out
Seconds since the epoch: 1234712674
Local time: Sun Feb 15 10:44:34 2009
Naturally, you'll see different results depending on when you run the executable.