etamponi

I see! Thanks!

Very interesting! One thing I don't understand is: doesn't this assume that they could do the calculations to get the coefficients... Using decimal notation? How could they for example know that 18/20 = 9/10? This is straightforward in decimal, but in their notation... Not really? So I am not super convinced this is the actual algorithm they used. Or am I missing something?

It's the classical trolley problem.

https://en.wikipedia.org/wiki/Trolley_problem

Good point. To clarify my stance: what I meant is that the narrative of the article is the following: AI made us change the playbook and so now, because of AI, the playbook is this one. Which is like saying that Sun Tzu wrote the cited line of the Art of War in a second edition, whereas his first version was "completely different".

It blows my mind how these posts seem like everyone is victim of a collective amnesia.

Literally every single point in the article was good engineering practice way before AI. So it's either amnesia or simple ignorance.

In particular, "No coding before 10am" is worded a bit awkward, as it simply means "think before you write code", which... Does it need an article for saying it?

The unfortunate reality is that (1) and (2) is what many, many engineers would like to do, but management is going EXACTLY in the opposite direction: go faster! Go faster! Why are you spending time on these things

So as a senior, you could abstain. But then your junior colleagues will eventually code circles around you, because they’re wearing bazooka-powered jetpacks and you’re still riding around on a fixie bike. Eventually your boss will start asking why you’re getting paid twice your zoomer colleagues’ salary to produce a tenth of the code.

I might be mistaken, but I bet they said the same when Visual Basic came out.

The point of the article is that the jump start that AI gives you is not the same as the one that well thought frameworks give you. What AI writes falls apart and leaves you with the ruins.

It that's the essence, then of course 9/10 is accident. I think that's not software engineering though.

The essence: I need to make this software meet all the current requirements while making it easy to modify in the future.

The accident: ?

Said another way: everyone agrees that LLMs make it very easy to build throw away code and prototypes. I could build these kind of things when I was 15, when I still was on a 56k internet connection and I only knew a bit of C and html. But that's not what software engineers (even junior software engineers) need to do.

This. Thanks. It's a relief to see I am not the only one completely disappointed. I still believe that these posts are just an ad stunt to publicize their soon-to-be released AI tool. If they really believe what they're writing, it's really sad.

I think this post unveils a great truth that I never grasped: estimates are a political tool to decide what gets done and what doesn't get done. Thanks for putting it so nicely!

One thing that I'd like to understand then is _why_... Why doesn't management use a more direct way of saying it? Instead of asking for estimates, why don't they say: we have until date X, what can we do? Is it just some American way of being polite? I am sincerely curious :)

But plenty can be estimated more accurately.

As a person that has never encountered a complex software project that can be accurately estimated, I am being a bit skeptical.

The author did make examples of when estimation is possible: easy projects with a very short time horizons (less than an a couple of days, I'd say).

I'd love to hear some examples of more complex software projects that can be estimated within a reasonable variance.

However, I think it should also be acknowledged that the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate, because asking for an estimate is just a somewhat strange way for the management chain to approach you and then tell you how much time you have to deliver.

I hope the budget has been written by AI, so that we can take a shortcut and immediately answer the question "Can AI grow corn?" with a "No".

I am extremely worried by the amount of hype I see around. I hope I am being in a bubble.

Hours instead of weeks.

And then goes on describing two things for which I bet almost anyone with enough knowledge of C and Redis could implement a POC in... Guess what? Hours.

At this point I am literally speechless, if even Antirez falls for this "you get so quick!!!" hype.

You get _some_ speed up _for things you could anyway implement_. You get past the "blank screen block" which prevents you from starting some project.

These are great useful things that AI does for you!

Shaving off _weeks_ of work? Let's come back in a couple of month when he'll have to rewrite everything that AI has written so well. Or, that code would just die away (which is another great use case for AI: throw away code).

People still don't understand that writing code is a way to understand something? Clearly you don't need to write code for a domain you already understand, or that you literally created.

What leaves me sad is that this time it is _Antirez_ that writes such things.

I have to be honest: it makes me doubt of my position, and I'll constantly reevaluate it. But man. I hope it's just a hype post for an AI product he'll release tomorrow.

The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected.

The engineer who starts with a solution tends to build complexity in search of a justification.

I do agree this is a good point, I just find it funny that it comes from "staying 14 years at Google".

This is literally the reason why I left Google first, and Meta second. Finding simple solutions will get you absolutely nowhere in a place like those. You have to find complex solutions with a lot of stakeholders, alignment, discussions, escalations... Why ship one button if you can ship 100 and get you, your team and your manager promoted in the process?

Would you still defend your position if the “grumpy” guy answered in Linus’ style?

If they answered correctly, yes.

My point is that providing _actual knowledge_ is by itself so much more valuable compared to _simulated knowledge_, in particular when that simulated knowledge is hyper realistic and wrong.

I spent the last 14 days chasing an issue with a Spark transform. Gemini and Claude were exceptionally good at giving me answers that looked perfectly reasonable: none of them worked, they were almost always completely off-road.

Eventually I tried with something else, and found a question on stackoverflow, luckily with an answer. That was the game changer and eventually I was able to find the right doc in the Spark (actually Iceberg) website that gave me the final fix.

This is to say that LLMs might be more friendly. But losing SO means that we're getting an idiot friendly guy with a lot of credible but wrong answers in place of a grumpy and possibly toxic guy which, however, actually answered our questions.

Not sure why someone is thinking this is a good thing.

Logs were designed for a different era. An era of monoliths, single servers, and problems you could reproduce locally. Today, a single user request might touch 15 services, 3 databases, 2 caches, and a message queue. Your logs are still acting like it's 2005.

Perhaps it's time to take back the good things from 2005.

Am I the only one that is surprised that the app still works?!

Aren't we just reinventing programming languages from the ground up?

This is the loop (and honestly, I predicted it way before it started):

1) LLMs can generate code from "natural language" prompts!

2) Oh wait, I actually need to improve my prompt to get LLMs to follow my instructions...

3) Oh wait, no matter how good my prompt is, I need an agent (aka a for loop) that goes through a list of deterministic steps so that it actually follows my instructions...

4) Oh wait, now I need to add deterministic checks (aka, the code that I was actually trying to avoid writing in step 1) so that the LLM follows my instructions...

5) <some time in the future>: I came up with this precise set of keywords that I can feed to the LLM so that it produces the code that I need. Wait a second... I just turned the LLM into a compiler.

The error is believing that "coding" is just accidental complexity. "You don't need a precise specification of the behavior of the computer", this is the assumption that would make LLM agents actually viable. And I cannot believe that there are software engineers that think that coding is accidental complexity. I understand why PMs, CEOs, and other fun people believe this.

Side note: I am not arguing that LLMs/coding agents are nice. T9 was nice, autocomplete is nice. LLMs are very nice! But I am starting to be a bit too fed up to see everyone believing that you can get rid of coding.

Technical problems are generated by lack of knowledge. One type of lack of knowledge is interaction with people. You'll never know everything that another person wants to communicate to you because of several reasons.

But even in the case of magically fixing people problems - for example, if you are working on a solo project - you will still have technical debt because you will still have lack of knowledge. An abstraction that leaks. A test that doesn't cover all the edge cases. A "simple" function that was not indeed that simple.

The mistake you want to avoid at all costs is believing you don't have a knowledge gap. You will always have a knowledge gap. So plan accordingly, make sure you're ready when you will finally discover that gap.

I don't disagree with the sentiment. But let's also be honest. There is a lot of improvement to be made in security software, in terms of ease of use and overcomplicating things.

I worked at Google and then at Meta. Man, the amount of "nonsense" of the ACL system was insane. I write nonsense in quotes because for sure from a security point of view it all made a lot of sense. But there is exactly zero chance that such a system can be used in a less technical company. It took me 4 years to understand how it worked...

So I'll take this as another data point to create a startup that simplifies security... Seems a lot more complicated than AI

I might try to explain with some examples.

1) it would really be nice to renovate that old house in the city center of an old Italian town! Oh but hold and behold: you'd have to spend hours, days, months, even years (I am not kidding) just waiting for approval and agreeing on what you can and cannot do with the house. And it would cost twice as much as building a new one. And the new one would have better insulation and a modern layout, and be exactly like you want. That's why it's not always the case to fix and improve an existing thing.

2) it would really be nice to fix that car from the '60ies. Oh but hold and behold: the design doesn't really allow you to have all the safety measures of modern cars. And the maximum speed is going go be 65mph on a good day. And it's going to cost you twice as much as a new car, OR you'd have to learn tons of mechanical stuff to be able to fix it yourself. That's why it's not always the case to fix and improve existing things.

3) it's just more fun to build new things (at least for some people). It's open source. People do this for free, to learn and enjoy their time. They can do whatever they want, and they decided to go with the shiny new thing. Is it better than fixing and improving an existing technology? I don't know. But apparently it's more fun! :)

Very simple: if booing is used to prevent another person from being heard/being able to properly articulate their ideas in public, that's a violation of _their_ freedom of speech.

Again, I might have misunderstood what booing means though (which explains the downvotes at least...)

Ex-Meta employee here. I worked at reality labs, perhaps in other orgs the situation is different.

At Meta we did "fix-it weeks", more or less every quarter. At the beginning I was thrilled: leadership that actually cares about fixing bugs!

Then reality hit: it's the worst possible decision for code and software quality. Basically this turned into: you are allowed to land all the possible crap you want. Then you have one week to "fix all the bugs". Guess what: most of the time we couldn't even fix a single bug because we were drown in tech debt.

I might be misunderstanding what booing means then. My understanding is covering another person's voice with shouts in order to sabotage his speech. It might indeed be part of what some society might define free speech, but I'd consider it more of a coward form of violence.

If with "booing" you mean "disrespect whatever good idea a person has because it also has very bad ideas", then I wonder who we will end up respecting. Even I have ideas I end up discovering bad. Should I boo myself and ignore everything else I say?

If I am missing another definition of booing then I am sorry.

I disapprove of what you say, but I will defend to the death your right to say it.

This is _actually_ what a respectable society does.

"basically" is doing a lot of work in this sentence.

For example? I don't want to be ironic, I am genuinely curious.

Meta got caught _first_.