Do we need to wait for a tragedy before we do something? Good on the airlines and regulators for recognizing a burgeoning problem and taking action before (hopefully) it leads to unnecessary deaths.
> Do we need to wait for a tragedy before we do something?
Yes, absolutely. It isn't pleasant to think about, but laws and regulations are meaningless if they aren't based on actual numbers. If I wanted to propose some new feature at work, people would understandably want to see some numbers and not just “feels nice” lol
> In reality, it's more like the Fellowship of the Rings trying to make it to Mt Doom, but that realization happens slowly.
And boy to the people making the decisions NOT want to hear that. You'll be dismissed as a naysayer being overly conservative. If you're in a position where your words have credibility in the org, then you'll constantly be asked "what can we do to make this NOT a quest to the top of Mt Doom?" when the answer is almost always "very little".
Impossible projects with impossible deadlines seems to be the norm and even when people pull them off miraculously the lesson learned is not "ok worked this time for some reason but we should not do this again", then the next people get in and go "it was done in the past why can't we do this?"
Wow, sounds so familiar! I've once had to argue precisely against this very conclusion - "you saved us once in emergency, now you're bound to do it again".
Wrote to my management: "It is, by all means, great when a navigator is able to take over an incapacitated pilot and make an emergency landing, thus averting the fatality. But the conclusion shouldn't be that navigators expected to perform more landings or continue to be backup pilots. Neither it should be that we completely retrain navigators as pilots and vice versa. But if navigators are assigned some extra responsibility, it should be formally acknowledged by giving them appropriate training, tools and recognition. Otherwise many written-off airplanes and hospitalized personnel would ensue."
For all I know the only thing this writing might have contributed to was increased resentment by management.
> And boy to the people making the decisions NOT want to hear that.
You are 100% correct. The way I've tried to manage that is to provide info while not appearing to be the naysayer by giving some options. It makes it seem like I'm on board with crazy-ass plan and just trying to find a way to make it successful, like this:
"Ok, there are a few ways we could handle this:
Option 1 is to do ABC first which will take X amount of time and you get some value soon, then come back and do DEF later
Option 2 is to do ABC+DEF at the same time but it's much tougher and slower"
My favorite fact is that every single time an organization manages to make a functional development team that can repeatedly successfully navigate all the problems and deliver working software that adds real value, the high up decision makers always decide to scale the team next.
Working teams are good for a project only, then they are destroyed.
Jesus I just had flashbacks from my last jobs. Non-technical founder always telling me I was being pessimistic (there were no technical founders). It's just not that simple Karen!
I'm not an expert on the legal mechanisms but I believe it's a combination of all of those things through a hodgepodge of various local zoning regulations which the article references: limits on the number of unrelated people living in the same home where the limit varies by locality (i've always heard of these as anti-brothel regulations). Limits on number of leases in a single space or requirements for each leasable unit to have its own bathroom and/or kitchen. Requirements that each tenant have their own parking space. Lots of creative ways cooked up by local regulators across the vast USA to discourage anything but single-family homes occupied by single families.
Even what you described (single lease, 4 roommates) is very common and usually allowed but the single lease part is what self-limits the impact of boarding-house type places. You need to find 3 other people to go in on this place with. You need to trust those other people and coordinate lease payments and utility payments and deal with it when some of them to decide to move on. That's a headache!
I think it's well and good to try to address that problem too, but it does seem like a different, although not entirely unrelated issue. What you're describing is already happening now, it's just happening in public spaces (transit stations, parks, etc) where it affects everyone.
That's a fair question; we here being under a submission aout local-first apps, and al.
Of course, you know the answer: if you're offline, you're not online. Bob gets to type whatever Bob wants, and until you go online, you don't get to overtype anything.
if you can see the edits being made in real time, keystroke by keystroke, that pretty much solves that problem.
As for offline editing, either don't support it (then you're not local-anything obviously) or you can have some lame workflow like "the document was changed by another user ..."
I take your point, but I think your hypothetical is a wonderful example of Hyrum's Law. And for that reason, if I was going to go to the trouble of mapping my internal v7 uuids into something more random for public consumption, then I'd be sure generate something that doesn't look like a uuid at all so nobody gets any funny ideas about what they can do with it.
I'm also a native speaker from the US. Non-native speakers often have extra insight into the nuances of language, and I think skrebbel's headcanon here is really interesting.
I almost see "try and" as a form of "manifesting", of optimism, of believing that you will succeed. This would sort of comport with what he's saying.
But any difference is subtle, and most native speakers won't notice it, beyond maybe the more formal register of "try to".
Usually these extra insights are interesting but incorrect. Like here I think. I don't think there's any different expectations between someone saying "try and" and "try to" except it's maybe a very loosely correlated signal of social class
Another example is I've seen people several times online trying to argue y'all can be singular and all y'all is a way to make it clearly plural. Ok it's interesting that y'all is used as singular and all y'all isn't just about inclusion, but its not true.
As a native speaker my feeling is that if we're talking about "I'll try and X" vs "I'll try to X," they're mm@$be asking you neutrally to attempt something for the first time, but "try and get home without taking any detours" sounds as, if we've been through this issue on several occasions, and now I'm annoyed.
1) Completely separate in your mind the auto-completion features from the agentic coding features. The auto-completion features are a neat trick but I personally find those to be a bit annoying overall, even if they sometimes hit it completely right. If I'm writing the code, I mostly don't want the LLM autocompletion.
2) Pay the $20 to get a month of Claude Pro access and then install Claude Code. Then, either wait until you have a small task in mind or your stuck on some stupid issue that you've been banging your head on and then open your terminal and fire up Claude Code. Explain to it in plain English what you want it to do. Pretend it's a colleague that you're giving a task to over Slack. And then watch it go. It works directly on your source code. There is no copying and pasting code.
3) Bookmark the Claude website. The next time you'd Google something technical, ask it Claude instead. General questions like "how does one typically implement a flizzle using the floppity-do framework"? "I'm trying to accomplish X, what are my options when using this stack?". General questions like that.
From there you'll start to get it and you'll get better at leverage the tool to do what you want. Then you can branch out the rest of the tool ecosystem.
Interesting about the auto-completion. That was really the only Copilot feature I found to be useful. The idea of writing out an English prompt and telling Copilot what to write sounded (and still sounds) so slow and clunky. By the time I've articulated what I want it to do, I might as well have written the code myself. The auto-completion was at least a major time-saver.
"The card game state is a structure that contains a Deck of cards, represented by a list of type Card, and a list of Players, each containing a Hand which is also a list of type Card, dealt randomly, round-robin from the Deck object." I could have input the data structure and logic myself in the amount of time it took to describe that.
I think you should embrace a bit of ambiguity. Don't treat this like a stupid computer where you have to specify everything in minute detail. Certainly the more detail you give, the better to an extent. But really: Treat it like you're talking to a colleague and give it a shot. You don't have to get it right on the first prompt. You see what it did and you give it further instructions. Autocomplete is the least compelling feature of all of this.
Also, I don't remember what model Copilot uses by default, especially the free version, but the model absolutely makes a difference. That's why I say to spend the $20. That gives you access to Sonnet 4 which is where, imo, these models took a giant leap forward in terms of quality of output.
One analogy I have been thinking about lately is GPUs. You might say "The amount of time it takes me to fill memory with the data I want, copy from RAM to the GPU, let the GPU do it's thing, then copy it back to RAM, I might as well have just done the task on the CPU!"
I hope when I state it that way you start to realize the error in your thinking process. You don't send trivial tasks to the GPU because the overhead is too high.
You have to experiment and gain experience with agent coding. Just imagine that there are tasks where the overhead of explaining what to do and reviewing the output are dwarfed by the actual implementation. You have to calibrate yourself so you can recognize those tasks and offload them to the agent.
There's a sweet spot in terms of generalization. Yes, painstakingly writing out an object definition in English just so that the LLM can write it out in Java is a poor use of time. You want to give it more general tasks.
But not too general, because then it can get lost in the sauce and do something profoundly wrong.
IMO it's worth the effort to know these tools, because once you have a more intuitive sense for the right level of abstraction it really does help.
So not "make this very basic data structure for me based on my specs", and more like "rewrite this sequential logic into parallel batches", which might take some actual effort but also doesn't require the model to make too many decisions by itself.
It's also pretty good at tests, which tends to be very boilerplate-y, and by default that means you skip some cases, do a lot of brain-melting typing, or copy-and-paste liberally (and suffer the consequences when you missed that one search and replace). The model doesn't tire, and it's a simple enough task that the reliability is high. "Generate test cases for this object, making sure to cover edges cases A, B, and C" is a pretty good ROI in terms of your-time-spent vs. results.
Is there any more agent-oriented approach where it just push/pulls a git repo like a normal person would, instead of running it on my machine? I'd like to keep it a bit more isolated and having it push/pull its own branches seems tidier.
But I find THAT attitude to be quite rude. You are prioritizing your preferences when it's me that you're reaching out to for help. Nobody's saying you have to write a complete and detailed problem description in your first message, but give me something to know what i'm getting into.
BAD: Hey, you there?
GOOD: Hey, you there? I'm trying to do X but I'm running into some issues and I wanted to get your advice.
Once I've responded and you know you have my attention, then you commit to filling me in on the gory details.
That "GOOD" is only marginally better than just "hi". It still doesn't include the actual point, so after me replying "yes I'm here" you are not much wiser and I'm not still on the hook of having to wait for you to type the actual thing.
