There is an urban legend that unified Cameroon (French/British) did trucks one month, and cars the next.

I'm pretty sure it was a joke, but my grandfather (who died in '76) did work there at the time it would have happened.

As Roger Needham quipped, Multics was design for the real-time processes of geological processes.

I'm still waiting for the pun.

I wouldn't be surprised if I had said syndrome, and I certainly have peeped with discontent often enough, but only at incompetent management.

But I'm going to disagree with both "maturity" and "creativity", although I'll stick fairly close to the latter.

Rather than maturity, what is important is the competence to be able to make a good estimate about when something will be finished (including documentation). Unfortunately the vast majority (80%+) of programmers aren't very good programmers when working in teams. I'll get back to that in a bit.

And rather than creativity, I find imagination, lateral thinking and problem solving in particular, to be more important. A similar 80%+ majority of programmers who's work I've had the pleasure to maintain are extremely creative in using the wrong tool for the job, etc. Again, competence is most important.

I'm going to make it more personal now: I'm unemployed and haven't worked with Delphi for more than 5 years professionally. Unfortunately that's where I put all my eggs. Although after 2020 I'll probably be able to find some maintenance work (just as the COBOL guys did in 1999, hehe), I'd like to be developing new stuff again. I had one agency who I had worked through to mutual profit regularly in the past, only for the incompetent agent to - after saying I couldn't get the job because my French wasn't good enough reversing that when I wrote her in French - then tell me I couldn't get the job because my Delphi experience wasn't recent enough DESPITE the version being asked for (5) being 2 years prior to the end of my professional usage (7), and this being clearly visible on my CV.

Somewhat ironically, for my very first Delphi job opportunity, when I'd waited for 32-bit Delphi (2), the job agency (a temping one back then) had been asked for someone with 5 years Delphi experience, so I didn't get that job either. My 10 years (at the time) Pascal experience counted for nothing, and I sometimes wonder if they ever found a bullshitter who claimed 5 years experience with a product which had existed for only a year. Competence.

The reason I stopped developing was stress-related. I was working for a seemingly friendly guy on a niche product (version 5) of which the source to version 4 had been lost. This was at half my usual rate, but with the understanding I might take the company over when he retired. I told him up front that although I am an excellent developer and test my own code, if I were to develop from scratch I needed a tester, and since he was the only other person, that meant him. The first thing I didn't know is that he was supremely competent at the art of fine bullshit, and for the first six months I hammered out functionality at an extremely fast pace, while he supposedly tested it. Actually, he only did so cursorily, and instead spent most of his time fighting the tax man on his evasion and bullshitting customers into upgrading to the new (as yet non-existent) product. But the second thing I didn't know is that he actually had a demo CD of a competing product, which I tested on a lazy day in summer to see what the opposition was up to. And this may be why this post gets moderated funny: the opposition were on version 3.0 of their product, and not only had a development team of about 100 for this product alone (recall we were about 1.1), but their functionality and data were both at least an order of magnitude higher, and similarly the price was an order of magnitude lower. Not only that, but their budget was, on researching, discovered to be 9 figures. Yes, that's a hundred million dollars. The only bright side is that presumably they used their own tools to develop this competing program. The name of their tools probably started with the word "Visual". Yeah. Laugh with me or cry for me ;)

But let me return to what is important: competence. I know what I'm competent at. I also know what I'm incompetent at, although I've learned the hard way. Note that competence is unrelated to brilliance: I've met many competent colleagues throughout my years in working on Delphi projects. I've certainly come across more incompetent managers than fellow developers, but given "promoted to their level"... that doesn't mean much.

That said, we are talking about the "best programmers" here, so we aren't talking about just one aspect anyway - but even then, competence comes top, in my book at least. But I've never met anybody without both strengths AND weaknesses, and that is where the team comes in.

For example, although I'm a supremely competent programmer (almost 30 years in total, 10+ with my favoured language Pascal BEFORE I used it professionally - apart from teaching it to undergraduates at Cambridge while I was a graduate student there writing a C compiler (in C) as a project - horrid language (tongue firmly in cheek - C++ is the horrid on)), I know that I'm not great at "exhaustive testing of my own code". Although at least I can match parentheses, so maybe there is a future in LISP. I've never found documenting difficult, but in Delphi documenting is rather easy anyway.

My competence comes not from my brilliance though, it comes from thinking before implementing. The reverse is an instant indicator of incompetence. If a programmer spends 8 hours a day typing code, he's doing something wrong. If a programmer spends at least an hour just thinking, not much more than an hour in meetings and discussions, perhaps half an hour documenting (on average), just 4 hours per day actually developing, and spends a few sessions a week on other things, be it a personal project "a la Google", or Monday morning and Friday afternoon focussing on something different (be it company rigmarole or reading trade magazines such as Dr. Dobbs.), and perhaps a couple of sessions testing the work of a partner dev if she finishes planned work for a day early, the programmer will be much more balanced.

To finish, since I seem to be rambling/ranting, I trust I've shown that I'm as weird as any of you, and please trust me that I am as competent as any of you. Although I need to get from 50 to 100 solved in Project Euler sometime, and I don't think it will be as easy as the 4 or 5 afternoons I spent to get to 50! I doubt any of you needs a Delphi Guru soon, but on the off chance, I'm available - if you don't mind someone weird ;)

Bernard Madoff (Great Merchant) has been born in New York (Dubya).

There isn't any better advice, but you ALWAYS have "really important" data.

The most likely things you are going to want to back up are documents and spreadsheets, pictures, videos and of course code. If you can't afford more than one external drive, or even don't want to spend anything at all, the big G (yeah, I'm a fanboy, but there are probably equivalent options) provides help. Google Docs for the first two: search for "google docs synch" and the first option is freeware (not that I've used it - nowadays I just use Docs itself). Picasa allows you to keep pictures unpublished, not so sure about youtube etc. And code you can mail to yourself, (g)zipped, although it might be on your home test/dev machine and also on your commercial web server.

Internet in the Netherlands is already taxed with 19% BTW (VAT, not quite sales tax), let alone all the other taxes - Water is taxed about 6 times if you count 'em all (at least the rate is 6% after drinking water, what a fucking great silver lining that is).

I can understand the concept of having certain taxes being related to usage - no road tax unless you own a car etc. - but in the Netherlands you pay anything up to 50%+ income tax (which has been pre-taxed by employer's tax), and THEN everything you want after that is taxed extra already.

If - as a nation - you have fucking (50%+) high income tax, then fucking budget it to cover basic needs, like sewers and roads. If you have fucking (19%) high sales tax (more for cigarettes), then fucking use it to cover whatever is being taxed.

I can even live with the idea that old media and new media are part of the same thing, and thus some of the sales taxes on the lot of them might be spent disproportionately on ailing media. But the real problem for the "quality" print media is that every station in the major cities has free print media, which readers can consume during a commute and typically leave on the seats of buses and trams everywhere.

metronieuws.nl and spitsnieuws.nl are getting sufficient print readers to encourage advertisers to read.

Fuck the Dutch and their fucking tax attitudes, though.

The problem with proofs has nothing to do with logic.

It is necessary to be able to understand proofs, but duplicating them under exam conditions means you have to memorize them by rote.

At a certain point (for me it was the Cambridge maths tripos part IB) you are going to get exposed to maths you have to do but don't fully understand.

People who can memorise the proofs but only understand them partially do better than people than those who understand the material better, but prefer to "solve a problem" and struggle to memorize a proof verbatim.

"... and lower than all but three Asian countries (Japan, Australia, and New Zealand)"

I read the fine article, but not the whole report. Wondering where this came from!

You have some insight, but not into how compilers work, nor how good programmers improve code. It has been a very long time since I wrote any C, but it was writing much of a (non-optimizing) C compiler. It must be said though that one reason I didn't finish it was looking at all the cool ways to optimise :)

If I were writing/designing a BIOS (which I must admit I am glad I am not) I would also pick C as the "best" language for the job. I'd then write the cleanest possible implementation of the design, using assembler only where absolutely necessary - which would likely be for platform dependent bits in >90% of the cases anyway.

The code need not be fast (as long as it performs), and it need not be tiny. But it needs to be 100% accurate, and sufficiently well documented to be easily readable.

By not using assembler, developer time until now has been relatively low. No premature optimisation has taken place. The next step is profiling, for which a benchmark suite is set up. This suite will ALSO be used to test that alternative implementations return the same results!

In parallel, the BIOS would be used in Virtual Machines; no ROMs need to be created, to get a good picture of how often various functions are called.

On the basis of this, it can be decided where to focus optimisation efforts. The historical target used to be primarily to get size down to 64k, since the 8088/6 booted to F000:FFF0. Assuming this is still a primary issue on many platforms, the first point of call for optimisation is to reduce any "big" functions - like those which use large (lookup) tables as their easiest/cleanest implementation (an obvious example might be the ascii characters in raster format).

Simply writing multiple versions of a routine in a HL language and then profiling may be enough to achieve the desired performance level (IIRC Jon Bentley wrote on this as one of his "Programming Pearls"), but even then an improvement may be possible by going right down to the silicon.

Admittedly it takes people like John Carmack and Michael Abrash to get everything out of it, but if everybody has a week to optimise a 20 line C "inner loop" function for speed, those who can read the produced assembler will do better than those who cannot, and those who can edit it will do even better.

Of course, over 20,000 lines of code, the C expert will manage better in a month, since rather than fixing 4 functions to perfection, they may be fixing 20 to 95%.

One final thing to note: optimising C compilers are known to have occasional bugs in their optimisation. When you are going to eventually write something to a (flash) ROM responsible for booting your computer, that is not an acceptable risk. That means that you don't want to rely purely on an optimising compiler to do your work for you.

Yes, a 1048576-node supercomputer, 1 billion wire taps, and root access to the internet.