Buying a car is scary enough for most people, figuring out how to trust some unaffiliated rando to do work on the most expensive or second most expensive thing they own is truly intimidating.
That matches my impressions. Narratives on crime seem to lag reality pretty severely. I first visited SF back in the 1990s, when I don't think its reputation was much different from other big cities, and saw neighborhoods that looked really grim. The Tenderloin then lived up to its reputation now. Even I, as a naive adventurous guy in my twenties, had the sense to be scared in some places. I went back twenty-five years later expecting it to be much worse, having heard so many things about it going to shit, and instead found it much better.
As for basic toiletries being locked up, I've encountered that in other big cities, too. I had to find a Target employee to liberate dandruff shampoo for me in Brooklyn, and while I was wandering the aisles looking for someone, it did occur to me that Amazon could deliver to my hotel.
> bus drivers are great. They have higher licensing standards, their income is tied to maintaining a license, they're well trained and professional
Also speaking as a cyclist: do you even expect them to be responsive to your presence? I've learned to think of them like they're trains. Their path and timing isn't influenced by my presence in the slightest.
If a car driver changes lanes right at me, I think, that careless asshole! But if a bus comes over into a lane I'm riding in, or if it pulls away from a stop and forces me to hit my brakes or enter another lane, I don't even register it as a mistake anymore. It's just the way buses work and something I have to be ready to react to. Thankfully their lateral movements are slow and smooth.
Some muni busses definitely dngaf, I've gotten cut off by them, the bus driver just deciding it was going to switch lanes into me before making its stop. I had to slam the brakes and ended up pressing my hands behind the bus because I couldn't slow down in time.
My grocery store now uses slightly thicker plastic bags, and I've found that you con reuse them dozens of times; I've had the same bags in my car for over a year.
Unfortunately, when they deliver, they use brand-new bags, and they don't accept them back for reuse, so a lot of them get thrown away after a single use.
> If your company is highly product driven, you’ll often find that the juniors end up lea[d]ing projects more often than not because they will tell the PM exactly what they want to hear
I worked in a company where this happened, and it wasn't pretty. Product managers used their experience and seniority to intimidate junior engineers and exert control over project management of engineering projects, which they predictably used to move as much work as possible to post-launch, including testing and security. They also gaslit junior engineers into agreeing that issues with contradictory or impossible product asks could be figured out later, leading to software getting released to customers that fundamentally could not be made reliable, performant, or even secure.
Even after the entire company went on site visits where customers told us they weren't using any of the features released in the last year because they were all buggy, and the only information they wanted about upcoming releases was assurance that their use cases wouldn't be impacted, product still kept claiming that the time it took to release new features was the biggest problem facing the company and kept fighting back against engineers who said we were in a quality crisis and desperately needed to make time for better testing and design.
The only thing that can shield you is good engineering management. Weak management will end up getting rolled by product and start promoting the bad behavior that product insists on. At that company I had a boss whose attitude towards us was "engineers in a startup should make decisions independently and stand by their work" but made sure engineers felt unsafe making engineering decisions that product wasn't happy with, likely because they felt unsafe themselves.
Cases like this raise a question. As an engineer, the errors that coding AIs make are an annoyance, and reassuring in terms of my job prospect.
As a consumer, the errors that AIs make are more than an annoyance. I have yet to meet an AI phone assistant that can do anything more than an explicitly programmed phone tree, and several, including the one for the pharmacy I use, that do far less. They are undoubtedly much more expensive to create and test.
Clearly there's a bubble going on, and unprincipled people chasing funding and promotions as usual, but why are companies like CVS paying more to get less?
I think it is literally to waste our time. It's one more layer of defense to stop you from talking to a person.
There are two big wins in health care. One is to increase the scope of health care that gets paid for. More and more expensive treatments, to bring the money in. The second big win is to stop people from getting treatment. Deny coverage, confuse them and wear them out with bureaucracy, and in this case stop them from talking to an expensively educated human pharmacist. That's what an AI does better than a phone tree, because it more effectively creates a sense of helplessness and valuelessness in the customer.
Expanding the scope of care you're entitled to and then fighting against your ability to get it isn't a contradiction any more than it's a contradiction when a person breathes in and breathes out. It's two synergistic parts of a system whose goal ultimately has nothing to do with health care.
All of these conversational AIs should either confidently detect a users intent or apologize and offer to forward call to a real person.
LLMs perform pretty poorly when you start try to restrict them too much (e.g. detect intents and control responses based on intent detection), the replies gets disjointed and weird feeling. An open ended prompt and chat completion gives a much better feeling most of the time but can go off the rails.
If you don't let LLMs handle the conversation entirely you get into insanely complex traditional engineering problem: (if user is complaining do x, if user asks a relevant question do y, if user asks an irrelevant question do z), which is an endless can of worms.
That's been my experience with AI "support" chatbots as well, in every single case it's been an optimistic attempt to get the bot to fix the problem I'm calling with followed almost immediately by an even longer attempt to get it to connect me to a human that can actually fix the problem. If the problem was simple enough that a fixed-program clanker can fix it then I wouldn't be having to call support in the first place.
The other win from obstructing people's access to healthcare is extending ill health and hence demand for the product. The trick is to not hasten end of the demand through death, but I'm sure that's within the ability of a simple "AI".
Getting the run a round from the Duke Medical School phone system was the last straw for my late wife. She killed herself because she could not reach a Human that could help her.
So yes, death does happen by phone systems.
This was in 2013 pre AI.
See our documentary Pain Warriors about that whole saga.
Free to watch on TubiTV and Amazon Prime.
I get no renumerations of any kind.
The opposite actually, has cost me greatly.
Pain Warriors has won several awards.
> But web applications are not just pipelines of isolated tools. They are full of shared assumptions: request shapes, validation boundaries, session handling, rendering, routing, serialization, deployment targets.
Some of those things are specific to web applications. Others are not. It's fine for web-specific logic to be tied to all of the shared assumptions of a web framework, but application logic should not be. As the architecture evolves, the application logic may need to be run in other architectural contexts: as a message consumer, inside an orchestration framework, etc.
That's one of the most painful things about PHP. Entire businesses get built around business logic in PHP backends, and then when you need to execute that logic in a different architectural context, every line of it has to be rewritten, because it's too much work to extricate it from the context of serving web requests.
If you are designing your framework to contain application logic, then it should look ahead to the possibility of that logic being used in a different architectural context. It should facilitate and encourage writing application logic that is agnostic of the web context. Otherwise you're encouraging people to repeat the mistake of PHP all over again.
If you work in a legacy PHP codebase, it's inevitable that you'll see $_GET in the middle of what you thought could be isolated business logic. The coupling that was done in my experience old PHP codebases is awful.
I guess I can't blame PHP because it comes down to the devs to enforce decent boundaries, but I think PHP makes it easier than others to do so.
PHP is so much better now, but if you're writing PHP, there's a very good chance you're not working with that new, clean PHP.
The "When touching it is the right call" is the tricky part, because it contains this very subjective exception: "Every new feature costs three times what it should because of the design, and you can show the trend."
I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)
Everything about all this has always been subjective, which is what separates good engineers from bad ones. Bad ones do refactorings that add very little value, good ones do it the right way, at the right time.
It’s also why, as you become older, the more senior you are the more you start to appreciate “boring” solutions and avoid fancy abstractions. It almost always serves the business much better.
> I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.
To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (inability to change is also another red flag).
There is a small chance that there's strong logical reasons for a desire to fundamentally change an underlying technology, but the comment above says they "simply refused to become competent in ....... that the system is built on" and as a ex-google senior engineer of 20 years, I can 100% confidently say that the first step to large scale refactor is to understand and be competent in the existing system!
> this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring
Agree that it's almost certainly a mistake in hiring but strongly disagree that it's a negative signal in the employees mindset
Being specialized in one area is actually a good thing for many people and many roles. It's actually kind of bullshit that software companies expect everyone to be a generalist nowadays
Having strong preferences about the tech you like to use and the way you like to build is fine. Find the employers with projects and teams that match your preferences rather than trying to crowbar yourself into everyone else's preferences
Strong (but polite) disagree. Domain knowledge is now commoditised more than ever, the only valuable employees are intellectually flexible ones with a can-do mindset, ideally more senior ones who will also take responsibility for the final output. Thats all we hire right now.
With the exception of companies so huge that economies of scale make hyperspecialisation the sensible choice, however I ignored these because this is a startup and small-medium business community
Respectfully I remain unconvinced. Especially now with people thinking that AI basically does a baseline "good enough" on many things, specializing more deeply than the AI does is probably a really important thing for people
We already have a massive oversupply of generalists and AI makes that easier than ever, so idk. I think specialists are more valuable
To expand on this, I've found that often, the best way to make a change is in two steps: First, make the change easy (the re-architecture). Second, make the change that is now easy.
My best software development experiences have been in cultures where this way of working was common.
It is a shame that these cultures are not more widely spread; and I mostly blame GitHub: the lack of good support for stacked PRs or patch series or whatever you want to call it makes it harder than it should be to work in this way.
I find this far too black and white. There's a lot to gain from conversations where you can't change the other person's mind. If you see making them agree with you as the only positive outcome, I can see why you'd give up arguing with people, but you're losing out on a lot of potential benefit.
I also think it's too adversarial. The author's claim, "If you genuinely believe something others don’t, that’s not a debate to win. That’s an edge," is not very persuasive, because you communicate far more with teammates, bosses, and subordinates than with enemies and competitors. Most of the people you communicate with on a day-to-day basis are people who can be dealt with more profitably through cooperation.
"You Can Only Change Yourself" is another far too absolute conclusion. You change and are changed by everybody you come in contact with. Every conversation is a chance to influence someone. If you can't make them see your point right away, you can sow the seeds for a future insight. Or you can clarify why you disagree. You can change their mind from "this person doesn't understand the problem" to "this person cares about an aspect of the problem that I don't think is primary."
I think the author should broaden their idea of what can be achieved in talking with someone they disagree with. It won't help them win arguments, but it will help them reap more benefit over time.
Wait until 10,000 manosphere influencers start selling personalize aura coaching to incels who share their glasses recordings. We'll start seeing those glasses on every lame-ass wannabro.
reply