That someone would need to restore some backups, and in the meantime, use mirrors.

Seriously, not that big of a deal. I don't know how many copies of Wikipedia are lying around but considering that archives are free to download, I guess a lot. And if you count text-only versions of the English Wikipedia without history and talk pages, it is literally everywhere as it is a common dataset for natural language processing tasks. It is likely to be the most resilient piece of data of that scale in existence today.

The only difficulty in the worst case scenario would be rebuilding a new central location and restarting the machinery with trusted admins, editors, etc... Any of the tech giants could probably make a Wikipedia replacement in days, with all data restored, but it won't be Wikipedia.

I don't know what you can take of this, maybe you can see it as advance pedaling, or to get a feel for energy conversion losses. Anyways, it is the kind of harmlessly stupid idea that I would want to try just because I could.

There are a lot of good reasons for not using Google Sheets. Maybe the spreadsheet is using features that Google Sheet doesn't support, maybe one of the parties is in China, where Google services are blocked, maybe it is against company policy to use Google Docs, maybe they have limited connectivity.

It is good to acknowledge the obvious, off the shelf solutions, but if you are given a job, that's either because the customer did their homework and found out that no, it is indeed not appropriate, or, for some reason, they have money burning their pockets and they want a custom solution, just because. In both cases that's how you are getting paid. So, I don't consider "use Google Sheets, you idiot" to be an appropriate answer. Understand the customer specific needs, that's your job, even more so in the age of AI.

And maybe the interviewer will be honest and say "just assume you can't, this is just an exercise in software architecture".

Writing the tests first and then writing code to pass the tests is no better than writing the code first then writing tests that pass. What matter is that both the code and the tests are written independently, from specs, not from one another.

I think that it is better not to have access to tests when first writing code, as to make sure to code the specs and not code the tests that test the specs as something may be lost in translation. It means that I have a preference for code first, but the ideal case would be for different people to do it in parallel.

Anyway, about AI, in an AI writes both the tests and the code, it will make sure they match no matter what comes first, it may even go back and forth between the tests and code, but it doesn't mean it is correct.

Although TDD says that you should only write one test before implementing it, encouraging spec writing to be an iterative process.

Writing the spec after implementation means that you are likely to have forgotten the nuance that went into what you created. That is why specs are written first. Then the nuance is captured up front as it comes to mind.

I would say that which come first between specs and code depend on the context. If you are implementing a standard, the specs of the standard obviously come first, but if you are iterating, maybe for a user interface, it can make sense to start with the code so that you can have working prototypes. You can then write formal documents and tests later, when you are done prototyping, for regression control.

But I think that leaning on tests is not always a good idea. For example, let's continue with the HTTP server. You write a test suite, but there is a bug in your tests, I don't know, you confuse error 404 and 403. The you write your code, correctly, run the tests, see that one of your tests fail and tell you have returned 404 and not 403. You don't think much, after all "the tests are the specs", and change the code. Congratulations, you are now making sure your code is wrong.

Of course, the opposite can and do happen, writing the code wrong and making passing test without thinking about what you actually testing, and I believe that's why people came up with the idea of TDD, but for me, test-first flip the problem but doesn't solve it. I'd say the only advantage, if it is one, is that it prevents taking a shortcut and releasing untested code by moving tests out of the critical path.

But outside of that, I'd rather focus on the code, so if something are to be "the spec", that's it. It is the most important, because it is the actual product, everything else is secondary. I don't mean unimportant, I mean that from the point of view of users, it is better for the test suite to be broken than for the code to be broken.

It is more like a meta spec. You still have to write a final spec that applies to your particular technical constraints, business needs, etc. RFC 7231 specifies the minimum amount necessary to interface with the world, but an actual program to be deployed into the wild requires much, much more consideration.

And for that, since you have the full picture not available to a meta spec, logically you will write it in a language that both humans and computers can understand. For the best results, that means something like Lean, Rocq, etc. However, in the real world you likely have to deal with middling developers straight out of learn to code bootcamps, so tests are the practical middle ground.

> I don't know, you confuse error 404 and 403.

Just like you would when writing RFC 7231? But that's what the RFC process is for. You don't have to skip the RFC process just because the spec also happens to be machine readable. If you are trying to shortcut the process, then you're going to have this problem no matter what.

But, even when shortcutting the process, it is still worthwhile to have written your spec in a machine-readable format as that means any changes to the spec automatically identify all the places you need to change in implementation.

> writing the code wrong and making passing test without thinking about what you actually testing

The much more likely scenario is that the code is right, but a mistake in the test leads it to not test anything. Then, years down the road after everyone has forgotten or moved on, when someone needs to do some refactoring there is no specification to define what the original code was actually supposed to do. Writing the test first means that you have proven that it can fail. That's not the only reason TDD suggests writing a test first, but it is certainly one of them.

> It is the most important, because it is the actual product

Nah. The specification is the actual product; it is what lives for the lifetime of the product. It defines the contract with the user. Implementation is throwaway. You can change the implementation code all day long and as long as the user contract remains satisfied the visible product will remain exactly the same.

What I usually do to prevent this situation is to write a passing test, then modify the code to make it fail, then revert the change. It also gives an occasion to read the code again, kind of like a review.

I have never seen this practice formalized though, good for me, this is the kind of things I do because I care, turning it into a process with Jira and such is a good way to make me stop caring.

Isn't that what is oft known as mutation testing? It is formalized to the point that we have automation to do the mutation for you automatically.

About fuzzing, I have about 20 years of experience in development and I have never seen fuzzing being done as part of a documented process in a project I worked in, not even once. Many people working in validation don't even know that it exists! The only field where fuzzing seems to be mainstream is cybersecurity, and most fuzzing tools are "security oriented", which is nice but it doesn't mean that security is the only field where it is useful.

Anyways, what I do is a bit different in that it is not random like fuzzing, it is more like reverse-TDD. TDD starts with a failing test, then, you write code to pass the test, and once done, you consider the code to be correct. Here you start with a passing test, then, you write code to fail the test, and once done, you consider the test to be correct.

Fuzzing, while useful in the right places, is a bit niche. Its close cousin, property-based testing, is something that is ideally seen often in the spec.

However, it starts treading into the direction of the same kind of mindset required to write Lean, Rocq, etc. I am not sure the bootcamp grad can handle writing those kinds of tests. At least not once you move beyond the simple identity(x) == x case.

Driving slower can make things more predictable and reduce wear, making breakdowns less likely. Trains being on time is all about consistency.

They're abandoning the consumer versions of these, not the enterprise versions. The consumer versions are the competitive market, where they're competing against iPads and such. They're not abandoning Windows for businesses, Office for businesses, where there is still no established business end-user OS/office suite alternative.

Everyone finds arguments that suits them. Some will quote "sleep experts", others will mention economic reasons, others will talk about road safety, each one with studies proving their point, peer-reviewed for the most sophisticated.

My take is that we are all different, and whatever you choose, some people will be better off, others will be worse off. There is a high chance that that variety is an evolutionary advantage, at least it was for our ancestors, as a group where everyone is sleeping at the same time is more vulnerable. Not great for office hours though.

Another example is a raytracer. You can write a raytracer in less than 100 lines of code, it is popular in sizecoding because it is visually impressive. So why are commercial 3D engines so complex?

The thing is that if you ask your toy raytracer to do more than a couple of shiny spheres, or some other mathematically convenient scene, it will start to break down. Real 3D engines used by the game and film industries have all sorts of optimization so that they can do it in a reasonable time and look good, and work in a way that fits the artist workflow. This is where the million of lines come from.

It turns out that in many of these cases, code is an effective way of doing it, but there may be other options. For a storefront, there are website builders that let you do it very effectively if your needs match one of their templates, there are game engines that require no code, and a lot of accounting can be done in Excel.

What I wanted to say is that maybe you could have done without code, but thanks to LLMs making code a viable option even for beginners, that's what you went for. In fact, vibe coding is barely even coding in the strictest sense of writing something in a programming language, since you are using natural language and code is just an intermediate step that you can see.

The reason programmers use programming languages is not gatekeeping, unlike what many people who want to "eliminate programmers" think. It is that programming languages are very good at what they do, they are precise, unambiguous, concise and expressive. Alternatives like natural languages or graphical tools lack some of these attributes and therefore may not work as well. Like with many advanced tools, there is a learning curve, but once you reach a certain point, like when you intend to make it your job, it is worth it.

If you walk to the kitchen and fry up an egg are you now a master chef? What's the difference between a surgeon and a butcher ...they both cut things?

Most shops never really needed development expertise in-house as there's no shortage of many decent tools equally suitable as code for getting machines to do most business things.

In some ways this is worse because while it's functionally the same black box intermediary as the alternative-to-code tools there's an illusion of control and more sunk cost. Do you want your sales team selling or learning JavaScript churning out goofy knock-offs for a well-solved problem?