The Curse of the Competent

Cursing the Competent

As long as the Internet economy was happily bubbling ahead, the Peter Principle reigned supreme: Peter joined a startup and got promoted quickly. Invariably, he would land in a position where he not only started failing, but dragged the entire startup down with his incompetence. Which of course didn't quite matter, since the Peter Principle was (and is) democratic and made everybody else look just as stupid as Peter himself.

The economy turned sour, Peter's startup died as everybody else's, and he scrambles to find a new job. Of course, he will want a stable company, with lots of cash reserves, good management and excellent products. Since he is good, he lands The Job, invariably at three hierarchy levels below where he was, with maybe half the salary. But who complains?

Around Peter all the people that have been there before him. They are a little afraid, since they know they kept their position because their company did well, not because they were better than poor Peter. Russian roulette of startups. The manager might not even have been able to get hired in Peter's old company. But that really doesn't matter.

Peter works hard, as he's used. He solves any problem in half the time that anyone else takes. Which doesn't make him a popular guy on the block. In particular, his manager knows how she will be followed in her every action with the critical eye of someone that used to supervise her likes. And that's when Peter is hit by the Curse of the Competent.

The 10 Most Common Mistakes by Tech Job Interviewees (and How to Work Around Them)

The job market is very tight and even if you are the smartest guy around, with tons of experience, and no salary requirements to speak of, you might find it a tad difficult to find a new position. That's particularly true for those that are just starting out, or who have been out of the game for a while. Unless someone is actively pushing your name somewhere, you'll see it's harder and harder to get that job landed.

Having witnessed literally hundreds of interviews, I can speak with some authority on what works and what doesn't from an interviewer's perspective. There is outstanding advice out there for general interviewing ("Check your resume for spelling mistakes!", "Nobody has ever been refused a job for wearing nice clothes!", "Do not become confrontational!") the advice is scant for the technical portion of your interview. Here my Top 10 mistakes made, and how to avoid them.

Femininity - the Missing Half of Science and Technology?

I am a man, in the most stereotypical way imaginable. I suffer from all the symptoms of the condition - the hair slowly starting to grow where it shouldn't, the quick temper ready to flare up for virtually no reason, but most of all for the way I think.

You could possibly try to call me sexist because of saying this, but there seem to be marked differences in the way the male and the female brains work. These differences seem to relate to evolutionary advantages, and they seem to confirm a stereotypical notion of gender roles in the incipient human community. I am at the butt end of the evolution, but I can see how we got to me.

Let's start with the unproven assumption that men were the hunters and foragers, while women were the nurturers. Let's add the assumption that humans, like many primates, were naturally inclined to form societies. What does that yield?

The Role and Importance of Quality Assurance (QA)

There is a moment where the young and enthusiastic learn that seat-off-the-pants is quick but eventually leads to catastrophe. You can tell at which stage engineers are by asking them what they think of QA: if they think it's an occupation for the lesser divinities of programming, they aren't there yet; if they have enough experience, they will think of QA engineers as demi-gods whose verdict makes and breaks months of coding.

Having been on for decades, I am of course a very, very strong proponent of mandatory QA. To me, this last step in the development process fulfills three main goals:

1. Interface stability and security Making sure that the code does what it is supposed to do especially in boundary conditions that developers typically overlook. The most common scenario is that of empty data (null pointers, etc.) somewhere code assumes there to be an object, but testing code for SQL injections is another, perfectly invaluable example. This has nothing to do with the functionality of the code, but with its ability to behave properly in unusual conditions.
2. Performance and stress testing Checking how the code behaves under realistic scenarios and not in the simple case the developer faces. Instead of 5 users, make 500,000 run concurrently on the software and see what it does. Instead of 100 messages, see what the system does with 100,000,000. Instead of running on a souped up developer machine with a 25" display, look at your software from the point of view of a user with a $200 netbook.
3. User experience and acceptance Ensuring the flows make sense from the end use perspective. Feel yourself into the user and try performing some common tasks. See what happens if you try doing something normal, but atypical. For instance, try adding an extension to a phone number and see whether the software rejects the input. 

Security Matters

When I was little, I recall watching this popular science program in which Peter Ustinov popularized the theory of relativity. There was a rocket, a man on the rocket, a launch of the man and the rocket, and a transmission from the really fast man on the really fast rocket. The man on the really fast rocket saw earthlings slow down. Conversely, the earthlings saw the man talk really fast. Makes sense?

No, it doesn't. A cursory understanding of relativity tells you that the other's time must slow down or accelerate for both observers, not just for one. So both the man on the rocket and the earth station would have observed an apparent slowdown in the other's time. Of course, that seems confusing, since once the man on the really fast rocket returns to earth, time will have passed much faster on earth than for the man - but the reason for it is not speed, but acceleration.

This intro serves to explain something that has been bothering me for a while: the way people misunderstand information security concepts and continually use the wrong thing for the right purpose. It's really not hard, since there are only a very few and very distinct concepts - yet people get them wrong all the time. It's a little as if people take "security" as a one-size fits all umbrella, and doing something secure means doing everything under the umbrella.

Web 3.0

People have been thinking about the next generation of Web ever since Web 2.0 landed and got its incarnation in Friendster, MySpace, Facebook, and Twitter. No conclusive Web 3.0 road map has ever convinced me, though, so I started thinking about my own one.

I started looking at what made Web 1.0 and then Web 2.0 and decided that the trend could be extrapolated from there. The approach, I thought, should be Hegelian: every manifestation of the Web should solve a problem, create a new problem, and find its own solution in the next one.

What made Web 1.0? The problem we were having was information. Mainly the availability of information anywhere. People were paid for information back in the days. They were in a huge industry of information gathering, sifting, sorting, and selling. Web 1.0 was all about that information  - easier ways to distribute it, easier ways to connect with it, easier ways to share it.

Open Source and Interfaces

One of the things that complicates the development of software in the open source world is the enormous variety of different interfaces you have to deal with. This is eminently an architectural problem: interfaces need to be defined ahead of coding, and if you just start developing your own project, you have no need for uniformity across projects.

Initially, of course, there is no standard and hence no interface. Later, separate projects come up and they make a point of having different interfaces to better spread and create incompatible ecosystems. That was the whole enmity between KDE and Gnome, or the many different brands of SQL server implementations.

There is nothing wrong with competing projects, especially nowadays. It dawned on people that copying from successful efforts is a good idea, and the availability of source code makes it easy to get not only ideas, but also implementations moved. It so came to be that the outstanding networking code in BSD became the forefather of the networking layers in many UNIX-ish operating systems.