Being someone who was glued to this stuff at that time, I thought Doom 3 had that energy, but they were also clearly taking their time to get it right. And that time spent ended up giving Valve the chance to slip in with Half-Life 2 and steal some of their thunder. Otherwise I felt like they were setting out to do some amazing new things with the tech and game design and they (mostly) accomplished that.
I'm sorry but the assumption that robotaxis will make parking spots obsolete in 5 years is the sort of thinking that probably keeps Elon Musk a rich little boy. About 10 years ago we had conversations about autonomous driving coming by 2020 and how it would likely make auto insurance irrelevant. That hasn't materialized yet, and granted we are much further along now, but it seems like we're still a long way away from it being the norm to the point where it disrupts city building codes.
I'm just saying that people should have the choice to build a building without parking if they think that it makes more sense to use the ground floor for other things. Currently, they do not - they are required to build 9 foot wide parking stalls and 16 foot wide parking aisles.
And you do not need to have an entire building of self driving cars to make a large dent in the building footprint that is currently dedicated to parking.
Builders will love to do it, which is where the code comes from. Long before robotaxi's were even an idea we would see buildings tout "car-lite" lifestyle buildings, aiming for residents using bicycles and public transport. Residents will (correctly IMO) point out that people grab these apartments and bring their cars anyway.
The code is a legal requirement. If the code did not set mandatory minimum widths for parking stalls, builders could still set them at 9 feet wide.
The point is that if you are builder who wants to build a 7 foot wide parking stall (or avoid parking stalls altogether and just have the cars park themselves as efficiently as possible) you are not legally allowed to do this.
If you can save millions in costs every quarter for the degraded experience, I can see why leaders want to take the risk. Really depends on who is making the calls I guess, for the services that depend on customer experience I would think an AI service agent would probably be out of the question.
I think I'm seeing the advantages of using this, but I can't help feel like momentum is going to be strongly against adoption. Already feeling like if I suggested this it would meet a ton of eye-rolls, there'd be all this new plumbing needed just to support something we can already do in similar ways.
You need to retrain managers from seeing a prototype and thinking "yep, ship it" and over to "okay, how do we build this properly?" And I don't think that's gonna happen.
It is pretty funny how this whole industry in a very short amount of time, with tons of experience and knowledge to lean on, reverted back to dubious measurements of productivity. If you track LoC and tokens used as productivity measurements, developers are going to max their LoC and token usage! Its so predictable that we have a Law named after this phenomenon! The fallout was so predictable I feel like I should have been positioning myself for all of the potential consulting work that's about to be needed.
I'm thinking of a technical screen I did recently where I didn't move forward. The time to do the screen was 30 minutes, and it was where they had a full frontend/backend and I needed to navigate around to fix a pretty arbitrary issue. I'd say this is preferable to a leetcode problem for sure, but also, I do tend to take my time to understand the system a bit before committing to changes, I mean this is sight unseen. I'm wondering if this felt too slow to the interviewer.
They sent me a summary document before the meeting, but I couldn't see the code until the interview. I felt like I identified the issue and where to make changes rather quickly, like 10 minutes of looking around and talking through how all the components and APIs fit together.
Then the interviewer asked me to implement a datetime solution, which in this time-boxed window my mind raced around to multiple solutions that I talked through out loud: I could write it myself which would definitely take some time for me to remember all of the syntax involved and reason through the problem, I could download an existing library which would also take some time to read documentation, I could google around for existing solutions in somewhere like Stack Overflow which is pretty hit and miss, or I could prompt an AI agent to write a solution for me. I talked through all of these, they wanted to know how I'd do it by hand at first, which I talked through for a bit but admitted I wasn't sure if it was a good way to go about it. Then I said given the time constraints the AI prompt route would probably make the most sense. By the time we arrived at that and tried it for a bit our time was basically up. And I got the impression suggesting AI to help code didn't impress the interviewer at all.
If others are able to stand out in this scenario then I guess I'll just admit I'm not the top candidate. My brain just doesn't work that quickly. I like to spend time gathering context and tinkering before really getting into the solution, and that probably doesn't come across well in these situations.
It often selects for a confident first shot, which is why we see these orgs drift towards lots of engineers who can blast out code but cannot maintain or evolve any existing systems proficiently. On rare occasion that is even the hiring goal!
This is the exact problem. Some people can flip between one shotting for interviews and going deep for real work, but they are extremely rare.
As a senior, I would much prefer a candidate who can discuss options more than write code - the writing itself is secondary, especially with AI. I want to see someone grapple with tradeoffs, clarify what they know and what breadcrumbs they want to follow before committing to a solution.
I'm hand waving the exact times, it was probably talking through how to filter by datetime a specific way for maybe 5 minutes followed by some discussion around these other ways to go about finding a solution. It was filtering by date starting from the beginning of the week. I searched around for a little bit since I didn't really know how to do this off the top of my head. Found a function that did what I wanted, then ran into type issues, more flailing around trying to get this working. I'll fully admit I didn't ace this.
I always thought of 9/11 as the major event for older millennials. I used to think it was all millennials, but many weren't even in kindergarten when it happened.
I figure from the context of the post they are asking sincere questions to their co-workers where they think their experience and knowledge is appropriate, but otherwise I agree that people should do a little legwork on their own before asking out loud.
The bigger issue I feel is knowing the medium for the question/help you need. If you need their experience and knowledge then talk to them. Email as a medium is already a wrong choice most of the time in these situations. Expecting them to give you the context that helps you grow from their experience in an email is placing a huge burden on them.
I can probably fix package manager issues by hand, and quickly with a little rubber ducking with the LLM itself. I'm not sure that's a huge problem in the grand scheme.
There's a lot of stuff in Python's favor in regard to coding with LLMs: its wildly popular so there's a lot of references for the right and wrong ways to use it, it can be typed using included libraries - its as simple as telling the LLM "use typing for this", and there are several great lint and unit testing tools to cover the hallucinations and poor decisions. The flexibility seems like an advantage to me personally, but I've always been a Python stan.
Why choose a significantly worse language when you are writing it in the same English either way.
It’s increasingly obvious that whole swaths of developers will just continue using the language they did before LLMs “just cause”
It’s more identity based at this point. My LLMs write Rust for me and I couldn’t tell you the difference outside of it being way faster and more reliable
For immediate term you should stick with what you know. I think that makes for much better prompting where you are coming in with experience with the language and the general style you'd like to see.
Rust is a language I would like to adopt longterm, but its not one I can easily grok and so my output would be worse for it.
I think that's fair, but I honestly can't tell you if I'm writing python or rust anymore. When I review I just ask Claude to add comments to all the code to make things clear as I review
reply