The difference between the fire fighter and the fire safety inspector. The former puts out fires and saves lives and is of course a hero. The latter complains about things that never happen, wastes everybody's time and money and is generally annoying.
It seems like the safety inspector might be closer to a SOX compliance auditor or something... in this metaphor, the engineer who doesn't build something that "catches fire" is just the one who uses sensible materials, includes smoke alarms in the design, and chooses to use passive insulation in the walls instead of electric space heaters on a high-pile rug.
In my engineering job of over 30 years, I've noticed that the heroes that get rewarded for fixing the problems are usually the same ones who created the problems in the first place.
I've only been a paid-on-call firefighter for 10 years, but I have yet to work with any who are also arsonists. ;)
No mass domestic surveillance of citizens is an old trick also. Country A doesn't surveil their citizens and Country B doesn't do theirs. But then they set up the infrastructure and both surveil each other's citizens and then exchange information. Then when they have all the infrastructure, it would be almost a crime to not use it to catch criminals. I mean, think of the children...
I think this would be good for everybody, not just kids. It doesn't even have to be complicated: Just that after a certain amount of time scrolling/watching, put in a message asking if it's maybe time to stop with some information about how these algorithms try to keep you for as long as possible. Maybe a link to a government page with more information.
It doesn't have to be perfect and there will of course be easy workarounds to hid the warnings for people that want. The goal is to improve the situation though, not solve it perfectly. Like putting information about the dangers of smoking on packages of smokes; it doesn't stop people from smoking but it does make the danger very easy to learn.
Just like we want to know where the food we eat comes from, we want to know where the information comes from. Of course there's the limit of journalists having to keep their sources secret in many cases. But original publisher I think should be possible.
The students had memorized everything, but understood nothing. Add in access to generative AI, and you have the situation that you had with your interview.
It's a good reminder that what we really do, as programmers or software engineers or what you wanna call it, is understanding how computers and computations work.
The proper way to work with git: Commit like a madman on your private branch. Short messages, written in seconds, just to be able to remember what you were doing if you are interrupted and have to get back into your work later. If you have a CI pipeline, often you have to make small changes until it works, so no reason to bother with smart commit messages.
At some point, you will have something working that makes sense that clean up. Then use interactive rebase to create one or a few commits that "makes sense". What makes sense is one of these topics that could create a whole bike garage, but you and your team will have some agreement on it. One thing that I like is to keep pure refactorings by themselves. No one cares to review that you've changed typos in old variables names and things like that. If it's a separate commit, you can just skip over it.
Depending on if you are completely done or not, the resulting branch can be sent as a PR/MR. Make sure that all commits have a reason why the change was made. No reason to repeat what the code says or generate some AI slop message. Your knowledge of why a change was done in a certain way is the most valuable part.
Of course, this way of working fits my work, that is not cloud based in any way and with lots of legacy code. It creates git history that I would like to have if I have to take over old projects or if I have to run git bisect on an unfamiliar code base and figure out some obscure bug. You might have a completely different technology stack and business, where it makes sense to work in some other way with git.
There is no "proper" way to use git, there is only a proper way to interact with your fellow developers.
You can do whatever you like locally. That's the luxury of git: it's distributed so you always get your own playground. You can make commits with short names if you find that useful. Personally I prefer to track my progress using a todo system, so I don't need commits to tell me where I am. I use `stash` instead of committing broken stuff if I need to switch branches.
I've found the idea of "rebase later" always easier said than done. In my experience if you work like that you'll more often than not end up just squashing everything into one commit. I prefer to rebase as I go. I'll rebase multiple times a day. Rearranging commits, amending the most recent commit etc. Keeping on top of it is the best way to achieve success at the end. It's like spending that bit of extra time putting your tools away or sweeping the floor. It pays off in the long run.
Like that one time the Spotify algorithm found a cool band. Only problem was that they were Chinese. If the name of a band uses some language that's based on some form of the latin alphabet, I can always type something similar to the name and a search engine will find it for me. With Chinese, no chance at all.
You're doing it wrong: You should just feed other peoples AI-generated responses into your own AI tools and let the tool answer for you! The loop is then closed, no human time wasted, and the only effect is wasted energy to run the AI tools. It's the perfect business model to turn energy into money.
You joke, but some companies are pushing this idea unironically by putting "use AI to expand a short message into a bloated mess" and "use AI to turn a bloated mess into a brief summary" into both sides of the same product. Good job everyone, we've invented the opposite of data compression.
Sadly, it might not be ironic. I've encountered many people (particularly software engineers and other tech bros) who assume most written language is mostly BS/padding, and assume the only real information there is what you get get from a concise summary or list of bullet points.
It's the kind of incuriosity that comes from the arrogance from believing you're very smart but actually being quite ignorant.
So it wounds like one of those guys took their misunderstanding and built and sell tools founded on it.
Two economists are walking in a forest when they come across a pile of shit.
The first economist says to the other “I’ll pay you $100 to eat that pile of shit.” The second economist takes the $100 and eats the pile of shit.
They continue walking until they come across a second pile of shit. The second economist turns to the first and says “I’ll pay you $100 to eat that pile of shit.” The first economist takes the $100 and eats a pile of shit.
Walking a little more, the first economist looks at the second and says, "You know, I gave you $100 to eat shit, then you gave me back the same $100 to eat shit. I can't help but feel like we both just ate shit for nothing."
"That's not true", responded the second economist. "We increased the GDP by $200!"
I like how you boiled that down to the core. It can't create information out of thin air; I'll remember that phrasing next time someone sends me a PR with LLM-generated novelizations -- I mean, commit messages -- or tries to get me to read their GenAI book.
I read it 14 years ago or so, after the Fukushima accident. I don't think the science has changed since then, or since the 90s when this project was shut down. There continue to be so much money in coal, gas, and oil and it's from there I think most of the opposition to nuclear stems from.
reply