If they don't work the way you want, you just keep refining it. This is easy if you actually test your regex in real data.

Fail catastrophically.. I had that happen once on an unexpectedly large input. That was a fun lesson. Ironically, the solution was to (*FAIL)

In any case, I learned a lot and delegating that to an LLM and learning nothing would not have put me in a better position.

> If they don't work the way you want, you just keep refining it. This is easy if you actually test your regex in real data.

There can be edge cases in both your data and in the regular expression itself. It's not as easy as "write your code correctly and test it". Although that's true of programming in general, regular expressions tend to add an extra "layer" to it.

I don't know if you meant it to be that way, but your comment sounds a lot like "it's easy to program without bugs if you test your code". It's pretty much a given that that's not the case.

I didn’t get the “it’s easy to program without bugs” vibe at all, and OP even mentioned an edge case that took their parser down (BUG!)

Neither the human nor the AI will catch every edge case, especially if the data can be irregular. I think the point they were making is more along the lines of “when you do it yourself, you can understand and refine and fix it more easily.”

If an LLM had done my regular expressions early in my career, I’d have only !maybe! have learned just what I saw and needed to know. I’m almost certain the first time I saw (?:…) I’d have given up and leaned into the AI heavily.

Doesn't sound like it. Entire article was specifically about the enshittification of Amazon

I'm not sure how. Their warehouses and deliveries are very efficient. I'm sure it cost a fortune to build out. Hard to compete with without a ton of capital.

This is a quirky response. Kotlin might be able to compile to JS the same way C++ can compile to WASM but I don't think that's it's primary purpose. Either put them in their idiomatic category or don't bother categorizing at all.

I'm pretty sure OPs reply is direct from an LLM

most of replies from OP sure sound like it.

I am not good at English. but I am sure my claim is correct and it my idea not LLM's

added note on the readme

I do consider excessive speeding as reprehensible. A little over, fine, whatever, but there's a threshold where it becomes dangerously reckless. But otherwise I agree. Someone might not consider just how dangerous a laser pointer is. I do hope they know how dangerous their car is though.

> I do hope they know how dangerous their car is though.

It’s just a guess but the death toll from driving too fast is likely much higher than that from laser pointers.

Though people may know the risk and speed anyway.

Maybe its because comparatively a lot less people use dangerous lasers than drive a car?

Hey now, don't blame us PC users. It's almost impossible to buy decent hardware that isn't RGB`d up the wazoo. Do I want all that crap lighting? No. Do I have a choice? No.

I'm not sure describing it in words is very helpful, and there's probably a good amount of such data available already.

I would think the way to do it is build the touch sensors first (and it seems they're getting pretty close) then just tele-operate some robots and collect a ton of data. Either that, or put gloves on humans that can record. Pay people to live their normal lives but with the gloves on.

You shouldn't even have to glance. Just feel around.

If the incentives are wrong, ya. At the lower levels of big tech, I don't think this is an issue. Or maybe I've been fortunate but all my managers and skip managers seem aligned on helping progress my career. Maybe because we're not competing for the same position and there's room for growth. If slots are limited and you're competing.. I can see this though.

Everything seems to be easier inside big tech.

In most tech companies, it's dog-eat-dog, people are even using the code they produce as a tool for lock-in, negotiation and manipulation... It's like they believe they will never get another similar opportunity in their lives and are trying to hang on to power like a dictator or sometimes a mafia boss. It's not even about money or growth. I've seen this same dog-eat-dog behavior in a crypto company which grew from $0 to $4 billion in a couple of years. It was like everyone was trying to backstab each other and the machinations behind the scenes were incomprehensible.

In big tech, it sounds like people are holding the door for each other like "you go first, no, you go first."

Good writing is helpful for your peers, and I wish people would document more, but I'm not convinced it's useful for getting ahead or demonstrating impact -- only insofar as you're producing artifacts which can be used as evidence.

Communication in general is helpful. Many incredibly skilled technicians are severely held back by the fact that nobody understands what they are doing and how impressive it is.

On the other end of the spectrum, most truly famous people are not just good at what they do, but also good at creating a sort of myth about themselves, or else has had a friend who loved talking them up. Learning to take what you've done or learned and spin a compelling story around it is an amazing life skill that absolutely will get you ahead.

You can absolutely take this too far and become a narcissistic charlatan -- all talk and self esteem -- but this is extremely far away from the personality of many engineers so I don't think that's an immediate concern.

I'd say being a good communicator, an "effective communicator" has the most impact. Not only writing well, but being able to enter and participate in C-Suite strategy conversations as a peer. Not dominating, not "telling them the truth", but being a peer-wise political player in the political theater that actually runs the company. That is what comes after staff engineer, it's VP of technology, CTO and so forth. That game is all communications, but as a former developer your role is getting them to understand the realities of the tech teams' efforts and successes, and the required maintenance to see it continue.