That's a good question. It's actually not an uncommon situation at all. Some years back we discovered that posting a page to a Tomcat based server would sometimes just disappear. We spent day and night researching this, had discussions via mail with some Tomcat developers, set up probes and loggers just about everywhere, even spent a lot of time reading huge amounts of Tomcat's source code looking for a possible clue, when eventually we found the culprit: an overambitious system administrator had changed some timeout value in the AJP connector between Apache and Tomcat to an extremely low value. It was a sheer miracle that there even were requests at all that made it through. The ultimate fix that had costed several weeks worth of time, a couple of emergency meetings, starts of drafting migration plans to just about anything else that possibly wouldn't have this problem, consisted of adding I believe no more than three zeroes to this particular timeout value...

This is indeed somewhat of a problem in our profession. It's in general hard to find good metrics that quantify the performance of a programmer. Lines of code, number of closed tickets, or years of experience are all sometimes used but even though these might be indicative of performance, they all don't necessarily have to mean much.

Lines of code has been discussed quite often over the years, but it's typically not seen as a good indicator. People may use a lot of white space, or write a bunch a spaghetti code based on blindly copy-pasting stuff around. This blind copy pasting will result in extremely bad code that's often impossible to maintain. A better performing developer may actually refactor all this duplicate code and abstract it into some common class or method, in which case the LOC produced by said developer may actually be negative! Worse yet, people may check in stuff like .dia files to their source code repository, which might boost your supposed LOC productivity with thousands of lines, while all you did was draw a box with an arrow pointing to it.

On the other hand, LOC also doesn't mean nothing. I've seen developers reading slashdot all day instead of coding and as a result their daily, monthly and even yearly LOC count was extremely low. We use among others statsvn http://www.statsvn.org/ and though not perfect it does give a very crude indication of who's very active and who's basically doing nothing all day long.

Number of closed tickets is an indicator too, but just as with lines of code hard to really use for measuring some one's performance. Tickets (issues/bugs) can vary wildly in complexity and the "estimated amount of hours" and "impact" is hardly ever accurate. Given two bugs, one can be as simple as adding a forgotten quote somewhere, while the other can amount to weeks of digging through the lowest levels of some code base. Yet, on average, if tickets are assigned to developers without really taking into account their abilities, then over a longer period of time all developers should on average get an equal amount of quick&easy and hard tickets. In that case, the number of closed tickets might be indicative again. Someone who barely ever closes a ticket might not be that top performer, despite the inaccuracy of the ticket measurement.

Years of experience, which is I think used the most, is maybe also the most debatable of them all. It's a very natural measurement tool which takes no personal stuff into account. It's a very basic and easy to measure number. But here too, it can be deceiving. I've seen programmers who had some 8 years of Java experience, but appeared to be totally unable to pass a basic Java test and produced nothing but WTFs in their code like concatenating strings to each other with commas in between instead of storing them into a list, simply because they didn't grasp how a simple list actually worked! (I kid you not, I actually encountered this). In contrast with this, there's the guy (or gal) taking up some part-time job while still studying, who understands even complex stuff in the blink of an eye and produce nothing but exemplary code. But here too, given a group of all reasonable knowledgeable programmers, the ones with the most experience typically win out. When I look at my own code that I produced 10 years ago and compare it with what I produce now, I most definitely see a vast improvement.

Even though management might often have difficulties with measuring the performance of a programmer, there is one group of people who are true experts here: the team mates of said programmer; his or her fellow programmers! If you have worked in a team for some time, everybody knows who's the ace, who's the simply capable one and who is obviously trailing behind. As a programmer you actually work with the code of that other programmer. You are either able to extend that code with the greatest ease because of the elegant design and clear names being used, or you curse every minute that you have to spent in that code. As a programmer, you actually know whether the answer you get from that other programmer actually makes sense. If he or she answers your every question with a "yeah, well, uhm, it's not supposed to do that, but sometimes it happens anyway. I have no idea why, must be a strange VM error", they you simply *know* that person is subpar. On the other hand, if you almost always get an answer detailing you the exact location of some occurrence and a short but concise explanation under which condition something happens and why, you *know* this person is ace ;)

Maybe THEY do, but for US it's a lot easier to discuss code via email than over the phone.

Ever tried to orate a code fragment of non trivial size? It ain't pretty I tell ya :P

Well, it might be a distraction sometimes, but it might also help. Specific kinds of music might get you in some flow, where you just become more alert. Often at the end of the day, things can be a bit slow and developers can become a little sleepy, which is certainly not helping with thinking about problems. Music, as long as it's not of the distracting kind, can actually help here.

Next to that, not all coding requires deep thoughts about complex problems. There always is some mundane amount of work to be done. Be it moving that button from left to right, changing those Strings to Integers, replacing some hardcoded text with i18n keys, etc. I often find that putting on some music gets me through this mundane stuff. Eventually I stumble on something interesting which does require some good thinking and then I might indeed turn the music off.

Our office is one large open space without any cubicles whatsoever. The developers used to be mixed with accounting, sales, etc but this was abandoned after complaints starting to pile up. Now the developers all sit together in one corner of the office, which is an improvement although you can still here some slight prattle from the other guys.

Our music policy is somewhat relaxed though. A while back me and a co-worker of my won an iphone dev competition, where the first prize was a speaker set that we installed at the office. I can play music on this, providing it's not too loud. There basically is only one woman in accounting who can't stand music, but we either ignore her complains or we wait till she is in a meeting or something before turning on the music.

Headphones are okay too at our place. The guy who's sitting next to me turns up the volume so much though, that we can all enjoy what he's listening to. No need to use headphone really, he might as well use the speaker set :P

The two best Pizzas I had were both in The Netherlands, Europe. One was around 2002 on one of the frisian islands; Schiermonnikoog. Amazing taste and amazing quality. Went back there years later, but unfortunately the pizzas they then served were not even close. Maybe new owners, or a new cook... no idea.

The other was in a small industrial city called Beverwijk, somewhere in a residential area. Tiny pizza joint, take away only, very badly decorated and shabby looking, but oh my... what a delicious pizza! :D But the same thing happened here, when I came back later the place was revamped and obviously had new owners who served a very average run of the mill pizza.

Too bad... looks like places having good quality pizzas have problems staying in business. Maybe it's simply more economical to serve lower quality.

I fully agree with that. That's why I usually go out of my way to persuade the developers in my team to write good commit comments. Of course, source code typically can't be attached to an SCM forever, but in most production environments it typically is (or well, should be...).

Next to commit comments, don't forget a link to an issue, ticket or bug (e.g. Jira, Trac, Bugzilla) that was the reason for the code to be written or modified. I see well written tickets and commit comments as an integral part of the code's documentation. Now some people only see a ticket as an order to do some work and thereafter discard the ticket. With such a view, you don't write your tickets in such a way that you still understand a year later what the issue was. E.g. tickets like: "Fix the prod. problem that bothered bob this afternoon". For me such tickets are worthless.

• The Facade pattern is not necessarily an anti-pattern. It can greatly simplify access to a complex sub-system, but as with all things this pattern should be used moderately and with care.
• Wrappers can be overused indeed, but "every OS call must be slowed down" is exaggerating. For starters, it's just a call, you don't need to qualify it with "OS". Secondly, modern compilers and runtime optimizers (e.g. the JVM), can inline calls. Inlining calls effectively nullifies any overhead. Furthermore, this overhead is very minimal on modern systems and finally, it only really matters when doing many calls in a tight loop. The average business request which runs in say 100ms is completely unaffected by the 'overhead' of 10 extra calls.
• Putting things in lists is cool :P

Luckily, most of today's IDEs offer you variable name completion. Just enter a few letters, hit something like ctrl+space and the IDE completes the name for you. Using long variable names doesn't necessarily means you have to type more.

We deal with this by using something that can be described as code editors.

These are people that edit raw code committed by other programmers and refactor it in order to comply with a set of standards. Editing may entail just changing a few variable names, but it can also be almost a complete rewrite of the code. Of course, if code rewrites become the rule rather than the exception, something is wrong and some serious talks with the original programmer will be necessary.

As long as the code editors are knowledgeable people and agree among themselves about the specific style, best practices and architecture to be used, this can greatly improve the quality and consistency of the code.

The point of building a house is not to have a great foundation. It's to produce something that benefits the end user. The users don't care about the foundation or how cool it is. It's a thing they have to live in, in order to accomplish whatever their real goals are.

Sounds insane? That's because it is. We wouldn't want to live in a house with a rotten foundation, why then would we want to accept that for software? Without a reasonably sound foundation of the code, your product will wither, fall over and simply cease to exist. I've seen too many examples of code bases that where rotten to the core, precisely because of people like you who think it's ONLY about external appearances. I suggest reading thedailywtf a little and you'll be surprised about the horrors that result from sloppy programming.

True, although the ones who really lack any level of intelligence usually don't get the degree either. They tend to drop out in their first year, or second year at most. When I started my CS degree, we had an initial group of some 50 people. After the first semester this was down to some 35 persons and only some 15 persons made it to their second year. Eventually, 11 or so of those graduated. This by itself is a pretty good weeding out of non-talent, don't you think?

In practice I've seen more talentless people made it into a programmer job than I've seen talentless people completing their thesis.

Also, don't forget that the reverse of your statement doesn't hold at all. You say you can be stupid while still having a degree, but of course one can also be intelligent AND have a degree. Unless you can provide some prove that an education makes one dumber (I don't think you can), I would say that having a degree and being intelligent is a sure win over being intelligent but don't having a degree.

Technically speaking you're right. You could as well read the book in your own time, but for some reason people rarely do. They stubbornly tend to read the books they think are the most interesting and skip half of it since they need to get some job done. More often than not, those interesting books turn out to be about the latest hyped language.

In university however, you not only get to read the interesting books, you also have to read those books you initially don't think to be relevant. This includes stuff like turing machines in fields such as foundational cs, but also more applied stuff like the inner-workings of a compiler and an operating system. Books such as Tanenbaum's Modern Operating Systems or H & P's computer architecture a quantitative approach, are typically books you read for a CS degree.

I strongly feel that having read books such as these, making assignments about the text, discussing the theory with my fellow students etc has made me an overall better developer.

At the very, very least, a CS education simply gives you the time and means to study. Even though you could theoretically do this all on your own, you probably simply don't have the time for it next to some job.

Well, if you're in China and you're the Chinese guy running this program, then it must be extremely easy to manufacture some crappy piece of hardware. Now make sure that Windows has no drivers for this (easy, since you yourself are that Chinese manufacturer, you just don't write Windows drivers). Simply install this piece of hardware in all those qualified PCs and make sure that this Red Flag Linux supports this hardware out of the box (easy, since you control the OS).

That should be enough to keep this insidious Windows away from those poor farmers!

I think you left it lying in your flying car...