DanielHB

I dunno, I found that kind of environment a lot easier to work with. The really hard environments are when the tech teams are large, to get something done you need to talk to 3 different teams and get them all to agree to do something and _when_ they are going to do it.

And that is just when you can talk to the engineers directly, it gets worse when you need to escalate on the management chain.

Startups are easier because most of the time you usually only need one rubberstamp (and sometimes none!) to do something.

It gets much worse though once the startup scales up and becomes massive. Then it tends to be worse than big corps because there at least they have processes.

Similar for me except that my tenures are usually 4-6 years, except this one job that I lasted 1 month because I fundamentally didn't want to do the work I was assigned to do (and would keep doing for at least a few months, probably longer).

The work was essentially web scraping complex systems, which is not a case of "you don't need someone with my experience to do this" and more like I just didn't want to do it because it did not improve my current skills at all.

It is not like in the interview they told me: you will be doing web scraping for months on end. Or that I even thought to ask.

Yeah the keyboard controls were awful, apparently it was because they wanted the game to have a console port using a gamepad.

Thing is I bet the people who played it are right too, I just never managed to bring myself to play more than a few hours of the game before getting frustrated. Bad controls + 90s point-and-click-puzzle-design + early 3d graphics is not a good recipe.

Full Throttle was criticized for its dumbed-down point-and-click (basic only 3 actions + using items, instead of the usual verbs), but that was the sweetspot for my early-teens mind. Can never get enough funny responses of using the lick action.

I remember playing it back in the day and I was severely unimpressed. Compared to Full Throttle it just felt clunky and the 3d art wasn't nearly as good as the amazing pixel art. I ended up never finishing it.

> People share skills and superpowers and plugins and mcps and very, very few of them have and kind of proof they do much at all.

At least 3 times last month I was asked to review a change in a .md file used by agents. And I am like: "yeah I guess it makes sense?"

It feels we need to write unit tests for this stuff, but even how to do so in reasonable time and complexity seems difficult.

Technically you can borrow money against your share, if you think your share gains will be higher than the interest rate you essentially have free money (although, obviously, not risk free). So that is a use for never selling shares.

Also some shares pay dividends.

The key problem is that IP is either proprietary to the creator or it is a commons type of situation.

Even if you agree with the former exploiting the commons for personal profit is... not good.

One could make the argument that if these LLMs were all open weight it would be okay, but to keep the result of the training private and proprietary is not fair.

I am seriously considering going into more lead/management role because of this, it is so demoralizing to feel I am doing work in a way I don't agree with.

Never thought I would say the day, when I joined this career all I wanted was to work on interesting problems and not work more than 40 hours per week. These days the interesting problems are always solved in the worse ways possible and I am often swamped with work that I don't even have the time to do any improvements out of my personally-assigned backlog.

I mentioned this in the last paragraph of my previous message...

This is what Android does with Dalvik/Android Runtime. Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.

With the compilation making use of the native instruction set supported for your device, so it can make use of newer arm instructions on newer devices while still supporting older devices.

This is the major reason app installation is so slow in Android compared to iOS (which pre-compiles everything). But it also greatly improves app compatibility with older versions.

There is no way Valve would be able to convince all the myriad of game engine developers to support a proprietary (or even open source) bytecode format even in the future. Best they could do is make it an opt-in.

Android only pulled it off because Google provides the "engine" (Android SDK) for all apps made for the platform and it did from the start.

And even so, most Androids games actually bypass this system entirely and just hand-compile to native binaries anyway. Because, again, the game engines don't want to support this bytecode format and google doesn't offer a C++ toolchain themselves that the engine developers could integrate with.

> It's a static site, slap in a Cloudflare for crying out loud.

I was about to say that, don't forget your cache-control headers kids.

I have been trying to find one of these "lower pay better conditions" places, but it is _such_ a gamble. It is so hard to tell how the work is going to be before you join. If I am almost certain to at least have a mild dislike for the work I might as well go for the place that pays better.

Also in my experience lower pay places tend to eventually suck because they tend to get into financial difficulties much more easily.

In Sweden large cities even in the suburbs parking can be quite expensive. But I guess it is because "the big city suburbs" in Sweden are still mostly 4-6 story tall apartments.

At my current place (apartment in a suburb about 10km from the city center) our parking would cost ~180 USD per month. From a tech worker perspective it is not like unaffordable, but definetily a luxury for most of the population. The median after-tax income in Sweden is like 3k USD.

That tax I mentioned before also makes very old beat-up cars not worth keeping (which is the intent of the tax to be fair).

One of the main upsides of living in a detached house in Sweden is not having to pay for parking. But even so the increase heating bills in winter can easily cost more than a car installment depending on your HVAC and insulation.

It is not even the cost of the car, but the upkeep. In large European cities parking alone can be prohibitive. In Sweden cars older than 2006 pay extra tax because they don't have emissions testing data.

It is very interesting that in most big cities around the world, but especially Europe having a car is a big luxury while in the US homeless people have cars.

How is this different from the EEA (Norway/Switzerland/Iceland)?

Java and C# seem to be the best ways of making code-first OpenAPI based servers.

C# LINQ also seem to be the best compromise between ORM and raw SQL queries, although I never used it myself.

I have been severely disappointed in all similar solutions for Go at least and I imagine Rust does not have something better given it has a smaller community-base.

Python and NodeJS have some very neat solutions for this stuff too, but both are "slow" dynamic languages. I personally dislike python with a passion and NodeJS stuff is extremely community-driven and therefor often unreliable. Prisma (NodeJS ORM) for example just did a major overhaul and is now pushing a completely different API.

If you are making boring REST API to SQL Database it seems like Java and C# are the best options.

> "cashing out" on good brands a universally bad decision.

For the company yes, not for the executive bonuses.

It is quite notable how the long-lasting companies that are household names somehow managed to resist this urge. Most of them are private.

People need to compartmentalize things in order to make sense of the universe, but doing so for companies (and governments) is just counterproductive.

Whenever you think about a company to draw any good conclusions you always need to think about all the people who work there, from the factory worker to the executive.

I got so annoyed with this and the fact that I do development in both mac and linux that switched to do all my development inside a container.

I just made a bash script that shells into the container (or starts it if it is not already running) and in there everything is set up.

I live in Sweden, but my company is not unionized (somewhat unusual). Non-unionized companies at least in tech tend to be _overtly_ better places to work than unionized ones simply because people have the _option_ to go to a unionized company. So the non-unionized companies have to make up for it with better work conditions, benefits and pay.

Even if you are not unionized you benefit from other people being unionized in your profession/area.

I was top 1000 for a while in the base-invasion mode of MGSV in the EU. That mode was basically a low-budget little tacked-on multiplayer that kept the core-gameplay and I spent hundreds of hours on it.

MGSV Metal Gear Online (the _other_ tacked-on multiplayer) was also great, but very unreliable netcode made it frustrating.

I wish someone would just take that game engine and make another good game on it. I _almost_ bought metal gear survive on the engine alone, that is how good it is.

The developers of the Zelda series always tried to make new games fit the previous one's lore.

The devs themselves put a ton of effort on making these games kinda fit with each other at the time they were making each new installment, it wasn't a retroactive thing. They just weren't super pedantic about it until the official timeline came out.

Anyone knows the details why Heart left Sweden? I applied for a job with them a few years ago but never heard back so I am quite curious.

They seemed to have a lot of former Embraer engineers from Brazil, I wonder if they brought them over to the US.

Yes, but I also think it will be trivially by-passable if you pass your output through another LLM. At least for text.

It might help catch students cheating, but not real spam-bot usage. As soon as platforms start checking for watermarks spambots will add anti-watermark passes.

Graphite kinda does that automatically with its "gt modify" command. However it keeps the history internally in your PR, but that history doesn't end up in your main branch. Once you merge the PR it looks like a single commit in the main branch history (or a single commit per PR in the stack).

It is a bit unfortunate but when using Graphite it is usually better to completely avoid any raw git commands that modify history at all.

Ah okay, I thought you meant to fully close the session before you make any manual changes.

In my company we use graphite and stacked PRs so it is highly encouraged to keep one commit per PR, so I am constantly ammending my commits.

I don't let claude make commits for me, every commit is my own. I check the diffs before commiting.

> never mix your changes with the agent's changes

yeah, but if you don't want to lose your existing context sometimes you have to. When I do, I tell claude to check the diff on the files I changed, which is quite annoying to be honest. But still easier than telling claude to do _very specific line-change_ on file X.

When I was doing a really large refactor across the codebase I told Claude Code to explain how certain things worked currently and how I wanted things to look like after the migration and a plan on how to get there. Then I did several further clean sessions where I always started along the lines: "Using this plan {link} do X."

Works pretty well for "non-permanent" instructions (you don't want to put this info into your committed markdowns).

My main motivation was simply to save tokens, but it actually worked really well and improved speed as well.

My lockfile was not gitignored, I had made significant changes to package.json so I was expecting diffs in the lockfile.

I just don't usually read lockfile diffs and claude inadvertently updated a few dozen packages to new minor versions without me noticing. In fact I only realized the problem after I looked at the lockfile diff.

I made changes to my dependency lists in the same code where Claude ran npm update. The lockfile diff was a few hundred lines after I undid what Claude did.

And yes, eventually I did check the lockfile changes and spotted the problem. I just usually don't check the lockfile that throughly.