Dunning-Kruger, no matter that it doesn't predict the competence of a person based on their confidence, has significant consequences. For example, take a large group of people. Note that their competence in some field is a random variable with probably a gamma distribution. In other words, most people are around average competence and as you move into higher competence, there are considerably less people. Now allow those people to self organize and choose leaders. To make things simple, lets split everything up into groups of 10 people. 10% are leaders. They are chosen for their self confidence and outgoing nature.

Interestingly, this will favour the less competent people, because they will be more confident. In fact, because most people are grouped around the middle, it will be difficult for them to distinguish competent from incompetent. This could make the incompetent candidates very much more successful. Now consider a second round. We are going to take 10% of the leaders and make them super leaders. They will be chosen by their peers based on their self confidence and outgoing nature. But now most of the people making the decisions are of lower competence. This will favour the incompetent even more.

This is the beginning of a "talent inversion". Incompetent, but confident people rise to the top while competent, but cautious people stay at the bottom. Now imagine the politics that will evolve from this very simple starting point. Every time an incompetent senior person asks for the impossible, an incompetent junior person confidently strides up and promises results. Because they are both incompetent, they can happily fail, but convince themselves that they have actually succeeded. If you have ever worked in a big company, then you probably don't have to imagine.

In other words, because of Dunning-Kruger life is unlikely to be a meritocracy. There are clear advantages to being competent, but one should not overlook the network effect of a group of confident, but incompetent people. Understanding that *you must deal with these people to ensure success* is key. In my career, I have found that borrowing some confidence from an "incompetent" co-worker, while lending some of my "competence" has been very successful. In fact, it is so useful to me that I have redefined my definition of competence. In truth, I was never very successful until I learned to look at things from other perspectives. No matter how right you are, if you can't act on it, it doesn't make much difference. And even if you are very wrong, acting often wins the day.

It's a bitter pill to swallow for someone whose ego is bound up in their competence. But life is not fair.

Code coverage tools will not tell you if your tests are sufficient. They simply tell you what lines of code were hit. They don't tell you whether or not the line of code was hit while doing a meaningful test. In fact, it is trivially easy to write "tests" that exercise 100% of the code but have no expectations at all.

What code coverage tools tell you is what code you definitely haven't tested. If you haven't run that line of code in your tests, you definitely haven't tested it. This is useful information, but not essential if you have a good team. My current team is quite comfortable writing tests. We do most things TDD and without trying hard our average code coverage is 96%. I occasionally wander through the other 4% to see if it is worth testing and most of the time it isn't. Occasionally I will find the odd piece of logic that was jammed in hurriedly without tests, but on our team it is quite rare. On the other hand, I have worked on teams that were not comfortable writing tests and mostly wrote them after writing production code. On those teams we would get about 75% test coverage with holes you could drive a bus through. A code coverage tool was very useful for educating people on the need to improve the way they wrote tests.

I feel very confident I could TDD my way through a tetris implementation and get 100% code coverage without undue effort. I don't think I would find all of the corner cases without help, though. A code coverage tool wouldn't help me in that instance.

There is a big difference between teachers and programmers. I know because I've done both jobs. Teaching is the more difficult one to do well. Good programming requires rare skills and an ability to concentrate more than most people can imagine. Good teaching does not need any unusual technical skill. The material you are teaching is really quite easy compared to what programmers have to contend with. The tricky bit is turning around lives that have been destroyed by circumstance and incompetent parents. Excellent programming requires a top notch mind and a devotion to learning. Excellent teaching requires a damn near miracle of people skills and good judgement.

Here's the kicker. If you staff your programming team with poor performers, chances are (sooner or later) your business will die because of them. The complexity that bad programmers add to a problem when they are coding eventually becomes so heavy that you just can't move forward. If you staff your school with poor performers, the students still graduate. The schools still operate. In fact, you can cut the budget of a school just about as far as you want, driving out any teacher that cares about money. The students still graduate. The school suffers in that it becomes a center for incarcerating delinquents, but the students still graduate. You just keep lowering the standards and society pays the hidden price.

A gifted programmer can name his price. A gifted teacher? Gets lost in the shuffle. His only reward is what he makes of it.

When I was living in Japan, a friend asked me to send him a copy of Inu Yasha volume 1 so he could give it to his daughter. She wanted to use it to help study the Japanese language. It was her favorite anime and she wanted to read the manga. I was about to send it to him and noticed that there is a scene with Kagome (the heroine) bathing naked. She's meant to be 14. Not wanting to get my friend involved in importing child porn, I ended up not sending it. It is a shame that a 14 year old girl can't read her favorite manga because there is a picture of a naked 14 year old girl in it. Laws are laws, though...

Not sure how many employees Cisco has left (didn't RTFA), but a quick glance at Wikipedia indicates that they still probably have more than 50K employees. Of course not all of them are engineers, but I have worked in organizations of that size before. If my experience is common (and I believe it is), they have already gone well pas the point you indicate. Even if they only have 5,000 engineers, it is practically impossible to hire anywhere near that many good people. You are stuffed to the rafters with dead wood. Not only that, but quite a lot of that dead wood will have made it up to management level -- the engineering and political skill sets are orthogonal, and people who are good at politics get promoted.

This means that the management probably has absolutely no idea how to separate the good engineers from the bad. In other words, just by growing the company to the size that they have, they are in a position where they can't evaluate talent. A 30-50% turnover rate is another way of saying 2-3 year attrition rate. I agree with the manager. This is common in large companies. Because they are unable to distinguish good from bad, they simply cycle through the available talent in a random fashion. They have chosen to go with quantity over quality and his statement makes absolute sense.

I don't think it is possible to do (for a variety of political reasons), but lets pretend that a company of 5000 engineers could cut back to their top 10% of talant. You'd end up with a solid core of 500 good engineers. Then, let's pretend that you knew how to do whatever it took to keep that talent for 10 year. Would the company be better off? I'm not so sure. I work in a former start up that is trying to scale itself up now. Since I'm fairly senior (possibly indicating I'm better at politics than engineering??? ;-) ) I'm exposed to more of the business end of the company. The CEO is demanding that we double our development group. He knows that this will throw the group into chaos, but he also sees a way to grow the revenue of the company by an order of magnitude if we can do some very specific work. Crucially, it doesn't really matter how badly we do it. It just needs to mostly work.

Which is better? Grow your revenue by an order of magnitude today and destroy your development team, or carefully grow your development team and trust that opportunities will show up when the team is able to handle them? It's a very difficult call. Personally, I can't fault companies who expand quickly (like Cisco did) and who take the opportunities that were presented. That's what the business guys are paid to do.

Luckily, the company I work for is wholly owned by the CEO and he has decided (for now anyway) to adopt a more sustainable growth for the company. Again, I am very lucky that our CEO views our team as being the engine of the company and values long term viability. He doesn't have investors trying to take their money out and has the ability to make the choice that leads to a very good place for me to work. Not every company has that luxury.

I use Arch for my day to day programming machine. I would not use it for an outward facing server mainly because it does work as well as some other distros for nailing yourself down to a known, stable set of versions. For a dev platform, though, it is fantastic. I've got bleeding edge everything (in fact, it is hard to stop it from being bleeding edge) and it is highly configurable.

The best thing about Arch is that most of the configuration for packages is not done by default. You have to do it yourself. While this is indeed a pain in the neck most of the time, it is awesome for keeping bloat away from your machine. The netbook I'm using to type this post on, does not have NetworkManager, Avahi, Pulse Audio, etc, etc, bt *does* have Gnome Shell on it. Try doing that on an Ubuntu machine... I use this box for hacking around on the train and for practicing programming, and despite being many years old it's absolutely fine. My main dev is also running Arch, manly because I get rolling updates and bleeding edge updates. Occasionally I have problems with stability, but nothing I can't deal with fairly quickly. It is much, much better than having the big bang upgrade every X months.

At work the other day someone said to me, "I've heard a lot of devices are running Linux, but they don't do the stuff that I want. For example, I don't want Android. I want something like my Linux desktop, but I don't know what to call that".

It was the first time that I could say to a normal user, "What you want is called GNU". I will know I've lived too long when normal people start asking for software freedom, unprompted. But the world is changing. What used to be flame war material for programmer geeks on obscure mailing lists is now starting to be relevant to the average person. Already I have people telling me how they just heard how stupid software patents are and how I have to get behind the movement to stop it. Most of the 20 or so programmers on my team have never programmed using proprietary software libraries ("What do you mean you don't get the source code? How would you be able to use it?")

I think what you say is probably true for the moment. I wonder if it will be true forever.

OMG! A rant about Emacs vs VI with a sub-rant about indenting with spaces vs tabs!!! And you even throw in a story about locking someone out of CVS (although in my day we used RCS and we were damn happy to have it).

You know how to make an old man feel young again.

The cool thing about Gnome shell (for a programmer) is it's customizability through Javascript. I was perusing the documentation for the Mutter bindings and the things you should be able to do is incredible. I don't know... maybe things don't work (I've never actually tried it), but I wonder if programmers are overlooking just how powerful Gnome shell extensions can be. Do you *really* want to set options through endless dialog boxes and wizards????

I have to admit that I use Awesome most of the time these days, but I would love to get a very minimal Gnome shell (with none of its assumed dependencies that bloat everything to hell) and hack out my perfect workflow.

The first 2 have been banned on my machine for quite a while (many years). The third I picked up because Gnome forced it upon me. I have now abandoned Gnome.

The other system that is off my machine for good is Network Manager. If I could find a replacement for Bluez I might even be able to have a stable machine...

From my experience, normal JR rail is almost as punctual. They have special gear that goes out and checks the rails after every earthquake. Typhoons usually don't even make the trains late. I got used to that service when I was in Japan. In 5 years I can only remember the train being late twice (both due to suicides on the track). I spent the last 2 years in England. They don't even count the train as late if it is less than 10 minutes late. Even with that, the train near me is late nearly 20% of the time (some times in the year it is late over 25% of the time). I'm glad I have a forgiving boss. I come in 30-60 minutes late at least twice a month due to the trains :-P

Not all places are like that. A friend of mine put if very nicely the other day. He said he spent a long time wondering if IT was for him. It seemed really destructive to his life. He came to the conclusion that IT was great. His specific job was not. He started to look for the job he wanted.

Another wise person once said, "Not everybody needs to be a programmer". You could be a waiter, for instance (not me -- that job is waaay too hard). After 20 years, I took "a year off" to teach English in Japan. I was working 35-40 hours a day. It seemed like part time. I enjoyed my life, got married and even wrote open source software. It was Idyllic. After 5 years of my "year off" (long after I thought I would never return to IT), I suddenly came back. I'm in a great team, working 40 hours a week and having a blast. We're a bit of a crazy team and are extreme, even for extreme programmers. I don't have a huge amount of time at work to write open source software, but I don't work stupid hours and my boss recognizes the value of giving me time to work on my own projects.

Sometimes it is easy to get trapped in the box thinking that there is only one way forward. Programmers are problem solvers. I don't know exactly what the solution to your problem is, but I feel certain that you can find it if you are creative enough. Don't give up!

I have had similar experiences with pre-hypertension and having no real success lowering my blood pressure -- except with the DASH diet. Like you, after a fairly short time with DASH, my blood pressure became normal. However, if you read the studies behind DASH (rather than the pamphlet on the website) you will find that the diet is geared around the hypothesis that increasing potassium and magnesium is the mechanism for lowering blood pressure. The sodium reduction is just kind of stapled on. The original paper shows that the DASH diet tended to reduce blood pressure at all sodium levels (although it appeared to reduce it more with lower sodium intake). Unfortunately, I couldn't tell from the paper what sample sizes they were using and I have grown cautious about the statistical abilities of nutritional researchers. The published DASH pamphlet is also faulty (IMHO) as it does not follow the diet used in the studies. It has a *much* higher calcium intake. I suspect (but have no evidence to support my feeling) that the published pamphlet has been prepared with "input" from various special interest groups.

The original DASH paper is available here: http://www.nejm.org/doi/full/1...

There a some other papers available on the internet as well. I would read these and ignore the various other websites/books with information about DASH.

Your view is common. I held it myself for a long time. I have since changed my mind. The real problem is that programming is taught very badly pretty much everywhere.

I spent 20 years as a programmer and then taught English as a foreign language for 5 years. I am now back programming, but I have started to apply what I learned as a teacher to programming. Just like programming, foreign languages are usually taught badly: the idea is to teach grammar and drill vocabulary. The students jam words together using the grammar and eventually learn how to speak. The problem is that most people are not very good at this technique, leading everyone to the conclusion that you need to have some sort of talent for learning languages in order to become fluent at a second language. I have found (like a lot of other teachers) that this is a poor way to teach. It is better to use "comprehensible input" to build fluency. The idea is that if you furnish students with a large amount of input that they can understand, they will acquire language. So instead of breaking up language by category and teaching rules that students apply, you give them language in context that they can understand and have a high amount of repetition. My experience (at high school level) is that the vast majority of my students could reach a surprisingly high level of fluency.

When I went back to programming a couple of years ago, I started mentoring some of the guys on the team who were under performing. Their main problem was that they would not understand what was going on in the code and would resort to "programming by google" (i.e. just cut and paste whatever crap from stack overflow that seemed relevant into the code). I talked with these team members and asked them, "When you read the code, how much of it do you understand perfectly". The answer was "70-80%". I explained the input hypothesis and told them that in order to reach fluency with the code, they would have to understand 95% of everything they read. Or, since it is hard to tell if you understand 95%, they should aim for 100% comprehension. After a few times where they fell back and claimed that it was "impossible" to understand all of the code (and I demonstrated that it was not impossible), they started taking more time to comprehend what was in the code base. Within a few months, their level improved dramatically.

I'm not saying that anyone can be a great programmer. But, most people who are diligent enough to graduate from college can become a half decent programmer. Our team is rather special in that we provide a lot of time and support to allow people to improve. I think the reason most teams can only get good productivity with talented programmers is that they essentially abandon them once they join the team. If you don't have the chops, then you don't deserve to be here. I've actually said that before, to my shame. I now think that most people who are interested in programming can be a programmer if they are taught properly.

In over 20 years as a professional programmer, I have met many, many good programmers. In the same time period, I have met maybe 3 competent program managers (or business analysts, or whatever they call them in your neck of the woods). I'm lucky to be working with a great program manager right now and it is amazing what a difference it makes. I would easily trade half my team for that one person. There will be a lot of people here who have *never* worked with a competent PGM.

If you have people skills, organizational skills, can find a way to not go crazy listening to programmers complain about minutia, and can grasp technical concepts you can be a good PGM. Which probably explains why there aren't very many... Rather than push people who are not interested in techie things to become programmers, why not look for people who are interested in talking to people, listening to problems and organizing things. Train them as PGMs.