kamstrup

Don't hesitate or overthink it. Just dive headfirst into it. The day you start is the best moment. The thing you chose to do, is the best.

Learn by playing around. Play to your strengths. Dabble with coding, sound, graphics, mechanics, and figure out what gets the fire going. Feed that fire.

When you've had a bit of taste, try to complete a small simple project. This is surprisingly difficult! Learn to remove features and complexity, simplifying until you can actually finish the game.

On your computer. I think this engine is aimed at embedded, if I understand the article correctly

I am perplexed that they refuse to acknowledge some pretty deep issues I see every major Go project run into:

• There are corner cases where it is literally impossible to check of the value of a type-param interface is nil.
• Type-params on methods
• Type-safe enums

As I explained elsewhere there is no official app to change this setting. Users can hack their gsettings.

Support for middle-paste will slowly but surely bitrot and eventually be removed.

No default gnome app will be able to toggle that default. You can hack it in gsettings.

And worse, the fact there is a setting means that only the default will be tested. The feature will slowly but surely bitrot. In a few years we'll see a proposal to remove it entirely. This is how software development works.

Many moons ago I did a project at uni where we implemented elliptic curve cryptography in Java and released it as open source. Unsurprisingly, we had no idea what we were doing. Some years later I get a random mail from someone using it on some embedded system...

I don't want to know, and I fear that ist is paramount that I maintain plausible deniability 😂♥️🙏

Do it. DO IT

That depends on what you count as a "test". In some langs/frameworks it is a lot, indeed.

Bash

Yeah. Totally agree on this. I spend maybe 3-4h a day reviewing code, and these are my thoughts....

The LLM generated tests I see are generally of very low quality. Perfectly fitting the bill of looking like a test, but not actually being a good test.

They often don't test the precise expected value. As an overly simplistic example: They rarely check 2+2==4. But just assert 2+2>0, or often just that 2+2 doesn't cause an error.

The tests often contain mountains of redundancy. Again, an oversimplified example: They have a test for 2+2, and another for 2+3.

There is never any attempt to make the tests nice to read for humans. It is always just heaps of boilerplate code. No helpers introduced, or affordances to simplify test setup.

Coupling the proclivity for boilerplate together with subtly redundant tests makes for some very poor programming. Worse than I'd expect from a junior, tbh.

And 1500 tests... That is not necessarily a lot! If that is the output of 1 month of pumping out code, I would say bare minimum

This is just incorrect, sorry to break the news. Most modern electric cars are hardwired to phone home. In most models the surveillance is fused directly into critical components like the fuel pump or the braking system. You cannot just pull out some wires in the dashboard. If you disconnected these things the car is unlikely to work. These details have been covered by people who have worked in the industry

Most devs I know like recursion. Trouble is that many popular languages don't support tail recursion, but throw a stackoverflow error after a few thousand levels. So you have to keep track of max recursion depth manually, and it starts to look like a complicated solution