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?
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 :)
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.
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.
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.