California’s labor board could state that anyone impacted by algorithmic decisions has the right to review the algorithm used, and that all algorithms used must be deterministic and diagrammable. If clearly stated, “flip a coin” or “choose one at random” is fine, but “trained AI network” is not.

This would shine light on algorithms used at Uber, DoorDash, Amazon, Microsoft, Workday (based in Oakland). Anyone with a worker in California whose work is subject to algorithmic intervention would have the right to request the source code to all algorithms impacting their gig, temporary, or permanent employment.

I cannot imagine a more frightening regulatory path for California tech. They would spend a billion dollars trying to stop it.

I disagree, but mainly because we're here on HN. We're in a location where many engineers and engineering managers of these things exist. Many of these problems can be solved WITHOUT legal. In fact, arguably this MUCH cheaper.

For developers:

This means to stop rushing, to do things the "right" way. To not just write code to pass the unit tests, but to write code that is more robust than that. To write code that is modifiable and modular (that whole monad thing that the PL people keep yelling at us about). To not just be someone who glues code together (be that from stack overflow or GPT), but _writes_ code. To actually know the entire codebase and beyond just what you're in charge of. To push back against your managers and write better code. To fix problems without being asked. To fix issues __before__ they're asked. Sure, writing fast and dirty code will get you done quicker but it is just putting off more work later. Because why do today what will be twice as much work tomorrow?

For managers:

Recognize that good and efficient code are important and make your business better and more profitable. To stop this "don't let perfection get in the way of good" nonsense, because perfect code doesn't exist. If an developer is writing "perfect code" then either there's a miscommunication between dev and manager about what is "good enough" or the dev is dumb (junior) and thinks perfect code exists. Give time for devs to go back and clean up the messes. Realize it is _cheaper_ and easier to clean a mess today than it is tomorrow since messes compound. Don't wait for something to break to fix it, fix it before it breaks. Maintenance is FAR cheaper than replacement. To be careful how you evaluate your devs because things like lines of code written, number of commits, or tickets resolved are all extremely noisy measurements[2]. All can actually be indicative of a bad developer as much as it can be of a good developer. Because when you have a true 10x developer 10x fewer tickets will be created in the first place. It's very hard to evaluate a future that didn't happen. Look for your developers who are foreseeing problems. Hire a few "grumpy devs", people who are pointing out problems AND trying to solve them. A good developer is good at recognizing and finding problems (see example below: stop testing if your devs can fizzbuzz or leetcode and instead see if they can anticipate problems and think about solving them. The more you believe LLMs will do the coding in the future the more important this skill is!).

(I've often been told that a difference between "academic code" and "business code" is that the business cares about if something "works". That what matters is the product in the customer's hands. My experience has been that business do not in fact care. This experience involves working in production and even demonstrating how to fix problems that more than double the performance of the product. Not like "made a 10ms process a 5ms process" but "customers can make 1 widget per hour, now customers can make 2 widgets per hour at half the cost")

For both:

To recognize that things compound and thus the little things add up. To stop being dismissive of small improvements, especially if they are quick to resolve. Small issues compound, but so do small improvements. Stick your neck out a little. If there's never enough time to do it right but there's always enough time to do it twice, then something is wrong (there is time to do it right).

Here's a simple example of how a small thing can compound while requiring almost no extra dev time (5 minutes? 30 max?):

  If you have a forum that people need to fill out and it has values you can know or reasonably guess (e.g. country and timezone can be reasonably guessed even if not logged in), provide those as defaults.
  Better, add a copy -- don't remove from the alphabetical list! -- of the most frequent/likely to the top. 
  (Seriously, as a US person why am I always scrolling to the bottom of a list to enter country of origin on a page that is expecting me to be a US citizen... We're writing software. Software automates. Fucking automate this shit for me).
  

I'm not just speaking out of my ass here. I write tons of small scripts and programs to take care of little things for me. They add up in surprising ways. Honestly, I'd get much more utility if other developers made this process more accessible to me. But the reason to write accessible code is not for others, but for yourself[1].

[0] Might seem like a nothing burger but this can be quite timely. My partner is Korean, so she never knows if her country is "Republic of Korea", "ROK", "Korea", "South Korea", or even some others. She has to guess and check, and it isn't like these things are near one another.

[1] I write a lot of research code. Many of my peers write just quick and dirty code. This is fine, I do this on my first pass too. But once something gets going it is incredibly important to have flexible code, even at the cost of optimization! (obviously depends on need and stage of code) because you have to constantly modify things. They may often be faster to first result but I'm faster to "completion" and often can be more thorough. If things are hardcoded then it is hard to modify and easy to make mistakes (did you check all the places?). If things are hard to change, then you're discouraged to answer questions as they arise. But I also worked as a mechanical engineer and an experimental physicist previously doing R&D. So I saw that development has various stages and it requires rebuilds along the way with the new build being aimed at the stage of development not the final goal. A beautiful thing about software is that the performance costs of "repairability" or "modifiability" are extremely low and often non-existent. So it is almost always advantageous to write that way. First dirty, then modifiable, then optimize what and only what needs to be optimized.

[2] There's an important concept here: Randomness/Noise is the measurement of uncertainty. You can't know something to infinite precision, so you have to include some uncertainty. Meaning, if you want to be more accurate, you have to account for "randomness" or "noise". If you just take numbers at face value then you are evaluating incorrectly. Numbers aren't enough, in any situation. Ignoring them will make you less precise and often bit you in the ass. It always does this at the worst possible time and worse, it is often hard to recognize where the ass biting came from.