There was a great story back in 2019 where an American security researcher bought the vanity licence plate "NULL" in California, presumably hoping that it would make his car invisible to the DMV so he could speed and park indiscriminately without consequence. Instead he got hit with $12,000 of fines from other people whose licence plates were not recorded at the time of the offence so were stored as NULL instead.

These are the sort of things I think of every time I see another question or news article about driverless vehicles.

It was a huge mistake for Microsoft to choose ' ' as the line ending sequence. They could have just stuck with ' ' that Unix used, and saved so much grief for text file compatibility. (And Apple chose ' ' for whatever silly reason.)

Back in 1985 our computer centre invested £1m in a new mainframe, however, they didn't invest £40k in a new roof which leaked. The new mainframe had to be removed and dried out!

In 1983 the Soviets had an estimated 2,490 ICBM launchers and five times as many warheads, not *4*. The claim that they only had four working missiles is from 1961. It also wasn't Petrov's decision to launch anything, he was only the officer of the day at at a western command centre (Serpukhov-15) for the Oko early warning system. He would have to give confirmation to the reports being produced by the instruments, and that is what he refused to do after corroborating the information with other sources. His superior, General-Colonel Votintsev, later arrived and backed up his decision that it was a false alarm when reporting to the head of the Air Defence Forces and the Ministry of Defence. Many cool heads prevailed in preventing catastrophe, not just Petrov's. They had their own internal computer network that was only a few years younger than ARPANET, built on pirated copies of IBM designs like the S/360 and 370, which is all the more impressive since theirs were built out of just "rocks and elastic bands". It might deeply disturb you to learn they also had a home computer market in the 80s. Very silly way to end an otherwise interesting and entertaining lecture.

I haven't been in the computer programming world for 40+ years, yet found this compelling and all but impossible to turn off. Best to this guy!

My worst mistake involved a loop without an exit back in the 90s. Unfortunately, that loop wrote a file to a drive. So I filled up an entire HDD in a split second...

That part about recursion seems either a gag for a cheap laugh, a lapse in communication, or intentional misrepresentation. It's combining Computer Science with Software Engineering in a way to completely miss the point. If you want to bash on recursion for being "just a goto", you'll need to do that for the loops as well. And all other control flow structures like ifs and switch cases. And calls are also just gotos with some added fluff you could do manually. But realistically, you don't say that ifs are bad because they are just gotos. Ifs are great because they are gotos that can't do whatever -- they are more restrictive. Same goes for loops and recursion. Loops and recursion both have their uses, but as Mark said, recursion gets praise in computer science, and it has a reason - some complex things are easier to represent with recursion. And that part about stack: Computer science, at the level I understand that term has no stack. It has no memory. It's math. Once the computer science problem has been solved using recursion, the developer is free to transform it into loops (CS has proven that this can always be done) or gotos or whatever needed by the the Software Engineering side of the problem solving. And no, Computer Science recursion will also never run forever. By definition a recursive function has a base case, which means it's over, and all other cases tend toward the base case.

In the early 1970s when mainframes started issuing electricity bills, some customers were furious when demands arrived to pay -£0.00 or else be prosecuted. It was a software glitch where £0.00 could have either a positive or a negative sign, and if negative then supposedly the customer had not cleared their bill... 😊

What a wonderful talk! I wasn't expecting to watch more than a few minutes but I had to stay for the whole thing.

There are 2 main reasons I might use recursion: - In a language with immutability loops get pretty nasty, and immutability is pretty nice. - When you have good algebraic data types, structural recursion is really nice.

I was working at Oak Ridge National Laboratory (ORNL) when it was run by Lockheed Martin Energy Systems, as were the other two plants at Oak Ridge TN, i.e., the Y-12 nuclear weapons plant and the K-25 gaseous diffusion plant. I was assigned to a team consisting of representatives from all three plants that was developing a Software Development Methodology to be used at all three plants. We were receiving comments from the Lockheed software group in Denver that was working on the MARS Climate Orbiter. They were regaling us with how good and error-free their code development was because they performed line by line code review and criticizing our work because we hadn't called for such review. After the orbiter crashed we never had another comment from the Denver group!

One pretty major mistake I found when investigating someone else's code was a for-loop (C/C++) that was, IIRC, some kind of memory copying loop. The termination clause for that loop was that the loop variable became negative. Too bad the loop variable had been declared as an UNSIGNED integer...

I had a highly egotistical boss who was NEVER wrong. And I watched as he reduced 2 programmers to quivering tears. The issue - the companies flagship program calculations was off by 1c. No explanation could be found. No code differences, nor data. Yet unbox a program and run it and you get 2.98, however unbox another in the same shelf and you get 2.99. I actually tracked it down to the fact that one development computer uses V1.1 of a popular compiler, and the other used V1.2!!! And there was a difference in the floating pount rounding routine between the two versions. Boss then screamed at the programmers for not realising these differences, abd I got myself fired for screaming at the Boss that " He was a F@cking cheapscake for never keeping the compilers up to date"

Seriously, on the first one: letting that go to the customer was definitely a QA and support failure.

Consistently one of the most entertaining and quietly funny speakers on programming I've come across. I've fallen asleep at many conferences (in an unrelated field), but would love to see a talk by Mark one day as I would be confident of not only staying awake, but enjoying a little chuckle every now and then.

Fun talk. Is it ironic or expected that the talk itself has bugs? :)

The "Dog 38" problem is easily "solved" (well, kicked down the road) as long as the Kennel Club isn't so stuffy as to demand monotonically increasing numbers and accept a sparse numbering scheme (although, show dog folks often seem quite stuffy). There are 1308 roman numerals in the range [1..3999] that can be represented in six or less ASCII characters (things get weird at 4000 and above and would probably create _other_ problems). In fact, if one just skips #38, numbers up to and including 77 can be used. So, for the "short term", just put a post-it note on everyone's keyboard at the Kennel Club that says "Woof Woof, DON'T USE 38, Woof Woof" should work fine. Eventually the post-it notes will have to be expanded to add other forbidden numbers, but they probably will need replacing by then anyway (and banning just 60 numbers yields over 250 usable ones - I think I can fit the 60 banned numbers on a large post-it note). There, fixed that -- send my my consulting check (I'll make sure to cash it before "Fido 78" arrives for registration!)

The Mars Climate Orbiter had a mismatch between units but it was NOT distance in inches vs centimeters, it was impulse measured in pound seconds vs newton seconds

Another (likely) causal factor of the Y2K bug was a general belief that software written well before the year 2000 wouldn't still be used by then. I remember writing software back in the 1980's that had code to handle dates past the year 2000, and being chided by a co-worker, who told me "nobody's going to still be running that program in the year 2000". I.e. he thought I should only use 2 digits for the year.

17:45 OMG, I know this kind of madness. In the end you get PPT Slides which document detailed contents of a Patch, line by line. And someone else has to write it down and test it again... instead of just receiving a Pull Request.

Making the unix timestamp unsigned 32 bit, actually shifted it to the year 2106... so developers can be like "I'll be retired by then.. so: not my problem anymore".

It's more of a stand up comedy show than a conference talk, I loved it😂😂😂

Sorry, but the recursion thing at 40:30 - 42:30 is bs for 2 reasons: a) tail elimination only works for linear recursion, doesn't work for binary or n-ary recursion which unfortunately does occur. b) tail elimination only works for linear recursion with tail calls, if program requires the call stack arguments while returning upwards in call stack, then tail elimination doesn't work either (without completely effing up complexity). c) linear recursion with tail elimination = goto, true, but if that's your problem, then by the same argument you could say for loop = goto, so for loops would be equally bad because they are also the same as a "goto" - this misses the point why gotos are bad! Gotos in languages aren't bad because they translate to jumps in machine code but because writing them in source goto makes the semantics hard to follow & change. (Furthermore if you have no tail elimination like in the 32 bit case then even linear recursion aren's the same as loops or gotos).

I'm constantly seeing people on the Internet claiming that Y2K was a big hoax. In 1999 I spent weeks fixing 1970s code that had the year in *two* formats. One was two character bytes and the other was a byte that was supposed to work past 2000 but instead crashed everything whenever it went over ninety nine mainly because no code expected that to ever happen. The weirdest thing was that we told our clients that our software would crash on January 1st and they needed the latest versions of everything yet a few refused to update anything. They seemed certain that we were lying about it as if it had been some kind of trick to sell them something.

I have seen that “10 IBM consultants in a room” thing far too many times 😩

This talk was very well presented, I was hooked throughout the whole hour!

The thing about the FDIV bug... Intel _knew_ it was broken before it ever went into production, but it would've taken time to correct, so they went ahead with it _after concluding no one would ever notice._ Boy were they ever wrong. (As I recall, it was discovered within days in scientific calculations. I've run into qualification errors like this with compiler errors!)

I'm only 5mins in here, I have a feeling I will have more comments.... I also shipped an "Undo New File Usage Change Kernel" (yup, that is what I called it), it was basically a boot option to revert some files on a windows installation in the other partition to a previously known good state. My UNFUCK lived in a rescue partition (the Advanced Rescue System Environment) alongside an option to access the Command Line Interface Terminal (basically a DOS prompt). The joke was obvious, but it never played out quite as well as that one time I was walking through the call centre and heard a support guy say to a customer "Okay, it looks like we can rescue your system, we just need to go into ARSE and stimulate the CLIT."

Algol W was devised by Niklaus Wirth (hence the "W"), not by Tony Hoare. I was studying computer science, and in particular, the Algol language family, under the tutelage of Professor-Dr. Peter R King, at that time.

Hmmm.... I do not think that the Ariane failure is correctly explained. As I remember it was even more insane: there was an inertial reference system that was useful only before lift-off and just continued to run after lift-off without any purpose. It was re-used from Ariane IV but not useful in actual inertial calculations for Ariane V after lift-off. They just used it for the start preparation phase. I think they kept it running after lift-off because it was originally designed to do so for Ariane IV and they wanted to mitigate risks by not shut it off or changing the code. Then the floating point error occurred because Ariane V had higher acceleration than Ariane IV and caused an exception. Which caused the perfectly running primary physical inertial system to shut-off. Then the redundancy system took over, ran into the same error and also shut off. This caused the rocket to lose trajectory and self-destruction system activated. I studied aeronautical engineering at that time and was keen about to know what happened.

When talking about dates and Cobol, it's worth mentioning that that was in the 1950s and 60s, So it was quite natural to use just the digits for a date. After all, the previous century change was prior to WWI and the next one would be after you retired.

The reason for the name 'Pentium' was they added 100 to 486 and got 585.5

Did he _really_ say that recursion is no better for safety because of how safe the machine code looks? Because that's not how compilation works.

21:30 *AKTUWALLY,* the 486 was the first Intel CPU with a built-in FPU. A version with the FPU *disabled* was indeed available, but the 80487 "add-on FPU" was literally a full-blown 486 in an incompatible package that would only fit into certain motherboards that came with an 80486SX soldered down to them; when plugged in, the 80487 would simply lock the 486SX out by shorting out an enable signal, and take over the data bus forthwith. The Pentium was the first *superscalar* CPU from Intel, meaning that it could handle more than one instruction per cycle, and it did have a *higher performance* FPU than the 486 did.

The Ariane 5 explanation is wrong. Trying to convert the 64 bit fp value to a 16 bit integer caused a hardware exception. The nozzle deflection was caused by the on board computer interpreting the resulting diagnostic bit pattern as flight data.

I can remember working on the SITA global network who backed up their leased lines with a piece of equipment manufactured by a German company Controlware. I once received an error message saying "the system is fucked". The error messages often used words like "buggered" and "screwed"!

As an aside, I find it interesting that for disasters like rockets exploding, they actually figured out what went wrong. That seems like something that could take a heroic effort.

Early in my career I was asked to implement a kernel watchdog timer as a workaround for another kernel module that would hang the system. Because I disagreed with the concept of such a hackish workaround, I labelled the feature the Basic Automatic Rebooting Facility (figure out the acronym yourself). I was planning on renaming the module before it shipped, but as luck would happen the root cause of the bug was found so my feature was not needed. Then by mistake my code made it into a production build and shipped anyhow (in incomplete form, so it caused regular reboots to happen). So customer support was having to tell clients to list kernel modules and look for one called BARF. Not quite as bad as a name with f*ck in it but did teach me the lesson of being careful with names.

The most difficult bug I ever found was on an LSI-11 Unix System VII using the Portable C Compiler. I tried everything and my code just would not work. Finally, I told the compiler to excrete the assembly code version of my program. Then I finally found the bug! The compiler was allocating 9 registers for a processor which only had 8 registers. I could then rewrite my program so that the compiler would only allocate 8 registers.

The document.all stuff is deliberate because there's code out there checking for document.all to detect IE which rightfully assumes IE will be IE(and by that I mean outdated, buggy, and barely pay lip service to any nice features). IE7 changed the behaviour of testing it's type specifically to stop people detecting IE in that way because, even though it was still a 5 years behind browser, it was no longer a 10 years behind the standards browser and they stupidly thought it was the right move to pretend compatibility.

Microsoft Excel counts 1 as January 1, 1900 @ 12AM. 1.25 is 6AM, 1.5 is 12PM, 1.75 is 6PM, and so-on. It still doesn't support any dates before 1900.

Actually, the 486DX had an integrated FPU, you only needed a 487 if you had the SX

I had to build a driver for a 'chain printer'. A chain printer has this long chain with a bunch of glyphs on them and it spins along this inked pad and these hammers slam down on the glyph when the glyph flies by the spot it needs to be placed. Awesome! High speed printing that can spit out characters as fast as the glyph can go by and the paper can go down. The problem? We had chains that were *exploding* out of the printers. Why? Turns out that people wanted 'demo' pages which would have all these glyphs on the page so they could show off how fast they could print a full page. Some bright person figured out that they could line up the glyphs in the order they were on the chain and so *all* the hammers would come down at once right as the chain came along and came into alignment. The fix was to limit the number of glyphs that could be hit at once. The noise was amazing.

PIC 9(6) in COBOL does not mean 6 bits. It means a 6 decimal digit numeric field or variable. It can’t have decimal points or minus signs. These are specified separately.

Ahh, there's also the Intel 386 bug, which meant their first few runs of 386 processor had a 50/50 chance of not being able to run 32bit software. They still sold them, just marked up as "16 BIT S/W ONLY". I'll bet that was a fun find.

"comfortably spit a rat" - I have only ever heard Ford Prefect and myself use this phrase 😄👍 The man is class

Fun talk. He's completely wrong about recursion and tail-call elimination though. Recursion is about decomposing a problem in a fashion where you don't have to simulate the execution of a machine in your head. It's about equational reasoning and referential transparency. None of which you can ever possibly get from loops.

The XKCD 2347 he talks about in 49:30 is actually about curl.

So much in this talk was just so wrong I gave up. Facts, people... they kinda matter.

Some issues with COBOL definitions here: PIC 9(6) is shorthand for PIC 999999 - i.e. 6 numeric digits. Nothing to do with 6 bits. Not used for "hyphen, comma and dot" either - that formatting would only be applied when moving to a print field.

Core memory has three wires through each core, not two. You need three to do the addressing. But, yes, they were usually assembled by women who could do this skilled work fast.

In 2007, Los Angeles Unified School District went to ERP software. The payroll was a disaster. Thousands of teachers were overpaid, underpaid, or didn't receive a check. When something went wrong, the teachers had to go in person to an HR office, which were open during regular school hours. That meant the teacher had to arrange for substitutes while they dealt with HR. The problem went on for months.

Programming mistakes which cost you millions are always fun to listen to :) Great speaker!

The argument about why recursion is bad is of course utter bollocks. By the same argument, most other useful abstractions in high level languages are "just a goto". The problem is that C# is badly designed and apparently does not guarantee tail recursion optimization in cases where this is possible. Like other high level language abstractions, using recursion can make many complex algorithms a lot easier to read and understand and thus debug. Even without tail recursion optimization, recursive implementations can often avoid stack overflow problems, e.g. by memoizing.

Good stuff John @markrendle for bringing out the fun in programming. It's serious and I wish I could be just as half as good you are. All said, that inspires and encourages many in the wider community to consider and take up programming. Having done it in the past, I wish to retake the journey even as a hobby going forward, hoping my current age (40's) won't be an inhibiting factor. Kudos to @NDC Conferences for making such good things happen.

we had to swap over two switches at my work. it took over a year of planning and hundreds of pages of documents to get it done. the old switches were crashing every other week and we lost visibility of the sensors they were connected to for upwards of an hour each time. but they were they insistent we couldn't do it because we would lose visibility during the change over. the job took just over 5min to do and in less than 10min the system was up and running again.

The Mars Climate Orbiter case wasn't as simple or "stupid" as you make it out to be. It wasn't that Lockheed-Martin stubbornly clung to Imperial units. They knew better. By the time of the Mars Climate Orbiter project, they along with most other aerospace firms had long been using the metric standard. The problem was that their code incorporated some older code modules from much earlier space missions, back from the days before metric had become the norm. As you surely know, it's usually better to re-use proven code than to write complex functions from scratch each time and hope you get all of it right again. Lockheed-Martin was well aware that the old code used formulas based on Imperial units, and painstakingly updated them all to metric calculations. Unfortunately they simply missed one. Having to update the units in the old code was a known risk, of course, but so was trying to write entirely new code to handle complex real-time navigational controllers. As for Americans being "stupid" for using Imperial units, that's not so simple either. It's not like chose to adopt the Imperial system of units when offered a choice between the Imperial system and the metric system with no prior history. The problem is that America (like much of the world) had long used Imperial units, *and* by the time the metric system came along America had a vast amount of technology, tools, and machinery already committed to specifications in Imperial units. Even the international aerospace industries around the world were locked into Imperial units for a long time after their respective countries "went metric" due to the inertia of (at the time) America's outsized contributions to the aerospace industry. It takes a long time to phase out the old and come up to speed on the new.

The effects of the Y2K bug were first seen in 1965 on 35 year mortgages

Very nice talk and examples. About 'arrogance' at the end , I would like to know if anyone here shares this view of mine: "If you think you can write 5 lines of code without bug : you are definitely arrogant". Usually test code should be as long as code.

The Telmex system in Mexico some time ago evidently had something like "IF account_balance NOT EQUAL 0 THEN disable_service". So if you overpaid your bill, they cut you off. As someone who learned programming in the 70s and worked in it in the 80s, I'd comment that too many programmers are in "cruise mode", not thinking about what they are doing and whether the instructions they are given are just plain dumb, instead smugly thinking about how cool they are, while obliviously translating those obviously defective instructions into code.

Love the graph at 16:12 - note how Leadership has absolutely no connection to the actual software development!

I would say that not considering horizontal loads was an engineering error rather than a programming error.

I like this guy's humour, but he got some stuff a bit wrong, so here, for posterity: Heartbleed wasn't a bedroom coder's unseen mistake, and it wasn't OpenSSL developers' mistake. It was introduced by a Debian maintainer to Debian's build of OpenSSL, because they wanted Valgrind (a tool for checking memory safety) to shut up about a particular line of code. They removed that line, and OpenSSL appeared to still work, so they shipped it, but it turns out it was working with orders of magnitude lower entropy in its encryption key generation mechanism (= orders of magnitude more hackable), and it took 2 years to discover. And the xkcd comic wasn't about OpenSSL, it was about libcurl :)

Error! The 80486DX did have a floating-point unit (FPU) built in. It was the 80486SX, introduced after the 80486DX, that had a disabled (defective) FPU, and a 80487SX FPU co-processor was then offered for extra money. Apparently, the early batches of 80486DX's had enough chips with defective FPU that this made economic sense.

Wouldn't an implementation that uses loops actually also look similar as the goto version? It's all just jumps at the assembly level after all...

Love this presentation. 🤗🤭As an old programmer, this is gold.

This is a great talk, thank you very much!

About the tail call thing: By that metric loops are also just gotos. However, it should be noted that recursion is definitely more goto-alike, though not in the way it was explained here - you can jump to OTHER functions with that optimisation; at least in most compiled languages [provided there's no destructors running *after* the call or anything of the sort; and that the optimiser recognises it, LLVM & GCC based ones definitely do], dunno if that applies to .NET as well. That said, it's much safer than just a single goto and much easier to reason about, *as long as* you have functions that are small enough. Because then, using tail calls, it's essentially saying "I can reduce the problem I'm trying to solve into *this* simpler problem"; which is quite nice not only for proving things mathematically but also for reasoning about it; especially where the equivalent loop has to deal with mutable state & such where the tail call version might not, because you don't have many small state transitions every time you change something in any variable, but one *BIG* state transition once you hit the tail call, instead, that lets you reason about the state as a whole much more easily in my experience. It's the same thing that can be generally said about side effects, just in a slightly different context, imho.

This talk is interesting and educational. Thank you.

Boy, you are amazing - albeit I did not comprehend more than a few words from bginning to end, since 'programming' and me are in far-far-way galaxies! But all the same, thank you! It's been a very interesting and entertaining 55 minutes of knowledge (and also very funny, I must say, at some points)!

Brilliant Job Mark! thank you mate!

I love that after watching this talk the next recomended video is another talk titled "Failure is always an option"

Matt Parker (the guy behind stand up maths) wrote an entire book called Humble Pi about similar things like the dog38 issue, a comedy of maths and computer number errors and cock ups and it's fantastic!

You can write a sort routine without recursion, but for many algorithms you'll need to implement your own stack which will no doubt be slower than the system stack.

The 486 (the DX version) had a floating point unit integrated. There was another version (486SX) without the FP unit, for those who did not nead the FP boost. The last processor commenly sold alongside a dedicated floating point coprocessor was the 386.

Almost every fact in the Petrov story is wrong. But yeah, missiles and computers were involved.

Your nervous breakdown changed my life forever. I ended up going to the US in 96 and I haven't got back to Hastings yet.

Recursion is good as a way to reason about program flow, although if it *looks* like something that could be converted to iteration, it *should* be IMO; also, ordinary loops are implemented using the goto-like instructions (a.k.a. jumps), the same way tail-call elimination for recursion is. The true reason that []==![] is true in JS is, in essence, that the abstract equality comparison tries to convert operands of different types to numeric values (after a special case in which null and the undefined value are abstractly equal to themselves and each other and no other values, except that the DOM, because of an old IE compatibility hack, also makes document.all abstractly equal to them): First, to evaluate ![], the empty array, which is an object, is coerced to boolean, which is true because the empty array is not one of the seven values that evaluate to false in a boolean context (false, null, undefined, '', NaN, 0, and -0), and then the logical not converts true to false; next, the ToPrimitive operation converts the empty array to 0 and also converts false to 0, and those two values are equal, so [] and false are abstractly equal. More generally, it was a huge mistake that JS operations result in unexpected type-coercions rather than errors; the language didn't even have exceptions until ES3; other smaller issues like the bug in the original typeof operator that made it output 'object' instead of 'null' for null could not be fixed, for the reason you stated.

Informative, entertaining and I didn't have to get up from my chair.

Sorry mate, but it was the 486 that has the math co-processor included. They also had a version called 486SX that didn't include it (actually disabled), which required you to buy the 487SX

Loved this talk. My only query would be how to traverse graph nodes without recursion. 🤔

Exceptionally entertaining! Great humor too, glad I took the time to watch :)

On Oct 5, 1960, BMEWS (Ballistic Missile Early Warning System) (big honkin' radar) in Thule, Greenland "detected" a massive launch that turned out to be the rising Moon.

I've laughed out loudly more often than on most comedy stand up specials. True gold, I salute you sir.

I can remember back in the 1980s when the East Midlands Electricity board centre in Nottingham had to replace their systems. At that time the UPS used lead acid batteries which worked fine, however, they were situated on the roof directly above the computer room and yes you've guessed it, they leaked!

Years ago in the early 1970s on the IBM 360, there were a couple of interpretive assemblers called "ASSIST" and "SPASM". I don't remember which it was, but one had a very strange bug when doing a double register shift on a specific pair of registers. No matter what you wanted to shift, it would always shift something like 8 bits more than what you asked. The twit at the computer center did not believe it was possible for such a bug to exist. I argued with them about it for quite a while, complete with listings that showed the contents of the two registers before and after a shift and how the results did not match the shift in the program, but they steadfastly refused to believe in bugs.

Can relate to the first story. Back in the days when software was still shipped on floppy disk in a letter, some boss though it would save us work if customers had access to the (dangerous!) patch/fix software. In fact, it was so dangerous that it was password protected so you couldn't use it accidentally, or without prior lecturing by someone who knew the password. Since it was internal use only, and only for very tech-savvy persons, the password was strongly protected against accidental leakage. It was a word, or rather a phrase, which no one would write on a whiteboard, or use in communication with a customer or superior. So one day I got a call from the front desk. A customer had a question about the patch/fix software. I was, like, wtf, the customer is not even supposed to know of this software, let alone get his hands on it! And, besides, it's password protected, so they won't be able to use it anyway. The secretary told me that the password had been included in the envelope, which I clearly didn't believe. She showed me the letter. Right in the middle of the letter, in *large* friendly letters, was the, uh, decidedly unfriendly password. Apparently, the boss had demanded the password from someone, who had written it down on a slip of paper (because you don't say such a thing to your boss) and the boss had given the password the the typist. That was in Germany, and the German typist apparently lacked enough knowledge about the English language to figure out what the combination of letters meant. So I had to call the customer, who asked what the password was. "Yes, we've received a letter....but instead of the password, was just an expletive...". I was able to convince the customer that the phrase (which was similar to "help yourself", but with an "f"-word instead of an "h"-word) was indeed the super-secure password and that they should not, under no circumstances, use that software, and "And as I know that you won't listen, make a backup of your data first! Otherwise, you might experience a situation which is...sort of similar to what the password means". Situation was contained, I wasn't fired and the boss got a bit smarter. Okay. I lied about the boss getting smarter. We just got secretive about our internal tools.

The 486DX had an FPU. It was the cheaper 486SX that didn't have a usable one. (It was on the die, just disabled.) It was only the SX that required the 487 coprocessor if you wanted efficient floating point computations. Which makes the Pentium bug a little more puzzling, because Intel did know how to do this right.

How awesome is it for someone to ADMIT to a full-on meltdown. Brains are complicated - and a very delicate balance and it's no wonder that very clever people often go over the fence.

The Pentium FPU error was surprisingly easy to spot in Excel. I had spreadsheets that checked the sum of rows minus the sum of columns equaled zero. The Pentium computers never returned zero!

Wrong: The Dutch United East-Indian Company did not steal the merchandize, all goods were bought far away for local prices, then transported to Europe and sold for a huge amount of money. On it's top the VOC employed a few hundred thousand workers. Making a 1000% interest on some products was not enough, the company collapsed in a few decades, the shipping business is extremely expensive. It can be compared with Apple nowadays, they also make a 1000% profit between the cost of the materials in the prison camp in China and the end consumers price in Western countries. You can't call this stealing, it is business.

The y2k bug was funny... in Berlin the firefighters callcenter stopped working... because of the bug... so no one could phone the firefighters when there was a fire and this was at sylvester 1999/2000...millions of people were lighting up fireworks and getting drunk and christmas light installations were all still up.... So the Firefighters were called into work by their colleages and had to patrol the city with firefighting vehicles to spot fires.

7:56 let's not kid ourselves, they still call it "core dump" because it sounds way cooler than "memory dump".

You would be shocked how much of Healthcare runs on Javascript as a backend. Most integration engines use an ECMA script library backend for their programming language.

The recursion bit just screams "I don't like recursion, so here is a cherry-picked example of when recursion is stupid!!!"

"Hartford Center" is actually the Hartford Civic Center, in Hartford, CT (USA)

SAFE: There is a daily status meeting, there is a three week time increment called a "sprint" but planning is done in "program increments" (name varies over time) of ten weeks which is the real planning horizon. And on top of this there is a project with a fixed end date and fixed content that runs for years...

Regarding the recursion and goto. All loops are goto(jump) after compilation.

The Deloitte one looks like a Major Metro's Subway Map