Haven’t seen the movie yet, but the book is definitely one of my all time favourites, so I would recommend reading it regardless of the movie.
The way the book is structured there is only one big reveal that would be spoiled by the movie, but I don’t think that was the most interesting thing in the book anyways, it was all about engineering, the scientific method and all that, and I think that will still hold before or after watching.
The one big exception I’ve found to “read the book first” advice to me has been “the expanse” there the books and the series were so great that they sort of complemented each other, and the advice there is “definitely do both”. I was reading the books and watching the series in parallel - side by side.
If they strike desalination plants, Israel/us can do the same … really mass casualty event could follow.
And they might, at some point the Iranian gov might feel desperate enough to be like “fuck it, we have nothing to lose” … Dubai could end up with a lot more graves.
Almost all of their water comes from these plants, and humans can’t survive without water for more than 3 days …
There are reserves/stores sure, but how long will they last, and which part of the population do they cover? In a week you could have thousands of civilians dead on both sides.
So MAD keeps things in check.
I think this is whaly Iran has invested so much into rockets - they are very ineffective at providing decisive military victory by themselves, but without them, Iran will be at Israel’s mercy, and they have proven to not possess that in great amounts lately
If the goal is to write emails purely using AI, then it is trivial to attach the MJML documentation as context to your LLM using context7 MCP or something of the sort. It's not a very complex language and its documentation is not large at all.
That's assuming the crawlers haven't ingested it all already...
Isn’t a “local emulator of cloud services” kind of the perfect project to be vibe coded? Extremely well documented surface to implement, very easy to test automatically and prove it matches the spec, and if you make some things sub optimal performance wise, that is totally fine because by project will not be used in a tight loop anyway - e.g. it will just need to be faster than over the network hop plus the time it takes for the cloud to actually persist things. This can just need to do this in ram and doesn’t need to scale.
So I’m shocked cloud providers haven’t just done this themselves, given how feasible it is with the right harness
AWS _does_ officially provide local-first dev containers for services like DynamoDB but sadly not every AWS service comes with those. Why? I have no idea, like you said it's clearly feasible and they already do it for some services today...
I think what they meant is you “can save 10 hours of planning with one hour of doing”
And I think this has become even more so with the age of ai, because there is even more unknown unknowns, which is harder to discover while planning, but easy wile “doing” and that “doing” itself is so much more streamlined.
In my experience no amount of planning will de-risk software engineering effort, what works is making sure coming back and refactoring, switching tech is less expensive, which allows you to rapidly change the approach when you inevitably discover some roadblock.
You can read all the docs during planning phases, but you will stumble with some undocumented behaviour / bug / limitation every single time and then you are back to the drawing board. The faster you can turn that around the faster you can adjust and go forward.
I really like the famous quote from Churchill- “Plans are useless, planning is essential”
> I think what they meant is you “can save 10 hours of planning with one hour of doing”
I know what they meant, and I also meant the thing I said instead. I have seen many, many people forge ahead on work that could have been saved by a bit more planning. Not overplanning, but doing a reasonable amount of planning.
Figuring out where the line is between planning and "just start trying some experiments" is a matter of experience.
I'm pretty sure I've literally never seen planning deliver value. But interestingly even the environments where planning was most obviously useless rarely diminished people's willingness to defend it.
I remember reading the letters of Cicero about Gaias Julius (Later known as Cesar) how he complains how the he and his gang is acting all amoral and wearing ridiculous scandalous clothes, waring the togas in provocative feminine fashion.
There are accounts from all over history of how "the times were more thoughtful and moral in the good old days" But here we are, thousands of years later, still complaining about the younger members of our species and how they will bring ruin to us all. Perhaps they will, but it all seems so human to complain about that.
I remember the art of the 90s - when my part of the world got access to marvelous pieces like Thunder in Paradise, Barbed Wire, American Ninja, Bay Watch ... at the time it was considered the pinnacle of art by teenagers like me, and despised by my parents. But at the same time we had things like The Matrix, The Shawshank Redemption, Leon ... We remember the good stuff and the forget the fluff.
There are some real gems being created all the time, maybe not always from Hollywood but human creativity soldiers on.
The Good Place, The Expanse, 3 Body Problem, Horizon Zero Dawn, Expedition 33, Project Hail Marry. There is a constant stream of incredible thoughtful stuff being produced - books, games, movies, essays, videos, podcasts - the medium might change but humans always try to find ways to discover, understand and express the world around us in novel ways, one just needs to listen/watch.
Not like there was a general lack of tragedy, pain, suffering, war, chaos in the intervening thousands of years.
Seems so superficial to ignore everything and just say if we're here, we exist, then the claim that things will go bad is proven false. The only thing proven false is if anyone ever claimed humanity will be extinct. But think of all the suffering in all the wars between the roman empire and now. Is that nothing? Does that not qualify as very bad stuff? Did humanity advance continuosly, or was it a chaotic path, with ups and downs? Don't the downs qualify as what the complainers predicted?
To me it seems history teaches us we will survive as a species. But there is definitely a lot of room for very bad stuff to happen. It has happened before.
I got myself a plastic welder - the thing that melts little pieces of metal to strengthen plastic joints - now I can keep old plastic things in shape almost indefinitely. Cost like 10 usd or so and has prolonged the life of all manner of things.
If you still want to make the old headphones work these welders are a godsend, and with some small amount of diy work of cleaning, sanding and buffing you can easily hide these welds.
I personally like to leave them though since they accent that something that was once broken is whole again, and that it has a long history!
When I’m interviewing I never ask a question about something I know super well. I circle around what the candidate signals he has great passion and understanding at, and start deep diving into that.
If I know about it as well, then we can have a really deep discussion, if I don’t- then I can learn something new.
The aim when interviewing is to check how well / deeply the interviewee can think through a problem.
If we pick a topic that they don’t have deep knowledge - they can either stumble and freeze emotionally, or hallucinate something just to appear smart. At this point it is an examination not an interview. And sure some people are capable enough to get to an answer, but that’s more of a lottery than a real analysis.
It usually boils down to how often have they interviewed before and been in a similar situation. And “people who have interviewed a lot” is hardly a metric I want to optimise for.
Now picking something they know or have expressed interest or passion in, this means we are sure to have more signal than noise. If the interviewee’s description is more of a canned response - then I delve deeper or broader.
“I’ve managed to solve this issue by introducing caching” - “Great, are there other solutions? How do you handle cache invalidation, what are the limits? What will you do if the load increases 10 fold, would you need to rethink the solution?”
Live coding during an interview is one of the most oppressive things I’ve witnessed in the industry in general.
There is usually a huge disconnect between someone who knows that “this task should take 20mins” and doing it cold in a super high-pressure environment.
People sweat, panic, brain freeze, and are just plain out stressed.
I’ll only OK something like this if we give out a similar but not the same task before the interview so a person can train a bit beforehand.
I’ve heard it all justified as “we want to see how you perform under pressure” but to me that has always sounded super flimsy - like if this is representative of how work is done at this organisation, then do I want to work there in the first place? And if it isn’t, why the hell are you putting people through this ringer in the first place, just sounds inhumane.
Yea, there's really no way to do an "interview assignment" well.
If you give unlimited amount of time, you're giving an advantage to people with no life who can just focus on your assignment and polish it as if it were a full time job.
If you give a limited amount of time, then you're making the interview a pressure cooker with a countdown clock, giving a disadvantage to people who are just not great at working under minute-to-minute time pressure.
Depends on the purpose. If you treat it as a minimum bar to pass and are up front about and actually adhere to that then anyone spending more than the limit on it is presumably just wasting his own time (and to an extent the company's because the application process continues). It only becomes a problem if instead of an objective pass/fail metric you start gauging other details that would benefit from additional time spent.
Thanks for clarifying - I kinda get the idea but would love to see an example for this.
I’ve mostly given up on all of the standard techniques for interviewing sadly, just because “using ai” makes a lot of them trivial, and have resorted to the good old fashioned interview, where I screen for drive, values and root cause seeking, and let people learn tech/frameworks/etc themselves.
But I was wondering, isn’t a take home question still good, if you give a more open ended and ambitious task, and let people vibe code the solution, review the result but ask for the prompt/session as well?
People will be doing that during normal work anyway, so why not test that directly?
One such question (obviously tailored to the role I'm hiring for) is asking whether SoA or AoS inputs will yield a faster dot-product implementation and whether the answer changes for small vs large inputs, also asking why that would be the case.
I typically offer a test with a small number of such questions since each one individually is noisy, but overall the take-home has good signal.
> why not test that directly?
The big thing is that you don't have enough time to probe everything about a candidate, especially if you're being respectful of their time and not burning too much of yours. Your goal is to maximize information gain with respect to the things you care about while minimizing any negative feelings the candidate has about your company.
I could be wrong, but vibe coding feels like another skill which is more efficient to probe indirectly. In your example, I would care about the prompt/session, mostly wouldn't care about the resulting code, and still don't think I would have enough information to judge whether they were any good. There are things I would want to test beyond the vibe coding itself.
In particular, one thing I think is important is being able to reason about code and deeply understand the tradeoffs being made. Even if vibe coding is your job and you're usually able to go straight from Claude to prod, it's detrimental (for the roles I'm looking at) to not be able to easily spot memory leaks, counter-productive OO abstractions, a lack of productive OO abstractions, a host of concurrency issues LLMs are kind of just bad at right now, and so on. My opinion is that the understanding needed to use LLMs effectively (for the code I work on) is much more expensive to develop than any prompt engineering, so I'd rather test those other things directly.
The way the book is structured there is only one big reveal that would be spoiled by the movie, but I don’t think that was the most interesting thing in the book anyways, it was all about engineering, the scientific method and all that, and I think that will still hold before or after watching.
The one big exception I’ve found to “read the book first” advice to me has been “the expanse” there the books and the series were so great that they sort of complemented each other, and the advice there is “definitely do both”. I was reading the books and watching the series in parallel - side by side.
I do hope Hail Marry is like that…
reply