daemin

I don't think you understand the situation so I'll try explaining it one last time.

The developer stored floating point values in a text file written out by whatever means, in the developer's locale (say en-US). These files were shipped with the application and the values were read in using locale sensitive functions on a user's machine (the developer was unaware of the locale sensitive nature of these functions), and the user's locale was something different like de-DE for example. This resulted in a different value being read in compared to the value expected by the developer, therefore causing issues in the rest of the program.

For example the file stored "1.05" which in the developer's en-US locale is "one and five hundredths", but reading it on a different user's locale (de-DE) could result in the value being "105" (one hundred and five), or even "1" (one).

These files are generally not considered to be edited by users (unless they are modding the game, and then they do so without warranty etc).

Europeans* - you mean the rest of the world that isn't default English (Traditional or Simplified) speaking.

The floating point values were valid, they were stored in the text files (unknowingly) in a locale dependent way, either by having a program use a locale sensitive functions to write the values, or because the values were written by hand using the developer's native way of number formatting. The values were then read using the locale dependent functions (like strtod) and if run on a machine with a locale that formatted numbers differently (i.e. using comma for decimal separator) they would return incorrect values.

This caused issues in the game as the values would be significantly different than originally designed, and it would be hard to test for since the people testing the game would usually be using a similar locale to the developer writing the game, and therefore they would only become apparent upon release or wider testing. Now the fix was to explicitly specify the locale before reading the data files, but it still took time to find and implement the fix.

I would say it more depends how the environment is designed and what transport options you have at your disposal.

In suburbia where the grocer is surrounded by a parking lot and there's busy roads to navigate nearby then of course people would drive rather than walk, and thus also end up getting a week's worth of groceries at a time.

In a dense mixed use environment where it is easy enough to navigate on foot then the urge to drive lessens and all grocery shopping can be done more frequently and on foot or by public transport.

I've experienced this personally in Australia, where living in suburbia I went grocery shopping once a week with a car and brought back many bags worth at a time, and also in a more dense neighbourhood where I could get groceries on the walk back from work more frequently and barely used my car even once a month. In Europe I only ever walk or get public transport for groceries as I live in a dense area and don't need to own a car.

There is some evidence of that, where the closer the crowd is to the field the more likely the referees are to call in the home team's favour. There was a study on this, probably close to a decade ago now.

>> Also changes based on locale,

> That's a feature: Where did the string come from if not the user?

Many games and applications store floating point values in text file formats. This has caused bugs in those programs many times over because they didn't realise it was locale dependent and the data parsing broke in another locale.

This topic brings up an interesting situation for wage taxation in Poland, where there's tax benefit that artists get for assigning copyright to the company. Now programming is included in this, but there's two points of interest that come up.

One is if your work is not creative any more as many people here suggest, does programming qualify as an artistic activity and would you say it qualifies for the tax break?

Two is if an LLM, AI, agent or other machine thing wrote the code for you, since it cannot produce copyrighted work, can you claim that tax break?

You're right. I was thinking of middle managers as the layer of management in between the executives and the workers.

So it looks like you're doing all the management work required by your reports, and if your reports were more capable you'd need to do more of the other things mentioned as well.

My original comment was to signal that if all you do now is write descriptions to feed to agents then you're not a programmer any more but you've become a manager as what you're doing is a management role and not an artistic or engineering one. You've changed jobs and you should be fine with that, just acknowledge it and move on, but stop fooling yourself that you're still a programmer or engineer. You're not, you're a manager now, even if you're not doing most of the things required of a people manager, as in your comment.

Aren't you managing AI/LLM Agents in this case, that write the actual code?

If all you do is write requests and then have the LLMs spit out the code then you're not a programmer, you're a middle manager. So maybe you never actually wanted to be a programmer but instead you liked having things built?

If 5 hours of thinking time to solve a problem is unthinkable to some people does that mean they have some form of Attention Deficit Disorder, be it a natural thing or introduced by an over-dependence on LLMs? Like stopping for an hour to think through a problem is unfathomable and instead they would rather hit small dopamine spikes every few minutes from talking to a chatbot?

You give a button pushing machine buttons to push and are surprised when it actually pushes them.