FizzyOrange

Honestly I think the complaints about the job market are overblown. If you are good then there will always be a job for you somewhere.

If you've already tried programming and you enjoy it then it is a really great career. Crazy money (especially in the US) for low effort and low responsibility.

Just be aware that CS is usually a lot more theoretical than most programming. You'll be learning about things like Hoare logic and category theory. Tons of stuff you only really need in the real world if you're doing formal verification or compiler design.

Still, I kind of wish I did have that theoretical background now I am doing formal verification and compiler design! (I did a mechanical engineering degree.)

Also you don't need a CS degree to get a programming job. I did a survey of colleagues once to see what degree they had and while CS was the most common, fewer than half had one. Most had some kind of technical degree (maths, physics, etc.), but some had done humanities and one guy (who was very good!) didn't have a degree at all.

I wouldn't worry about the market. Maybe take a look at the syllabus for places you might apply to, e.g. here's the one for Cambridge. Also I guess an important question is what's the alternative? What would you do otherwise?

I mean it's not a totally unreasonable list but what's with "working alone with headphones on"? And what are "annotations"?

Also Typescript backend can be pretty great actually - especially because it lets you use JSX/TSX. Nothing else is as good.

mainly because of rails magic though whenever I look at it. Convention over configuration hurts my brain some days.

I agree. Ruby has waaaay too much magic which makes it impossible to follow (dynamic typing makes it even worse).

And convention over configuration definitely has huge advantages in terms of consistency and terseness, but it is also way less discoverable because instead of a config file say "the stuff is in foo" you have to already know that everything in foo is automatically treated as stuff.

I often wonder if it would be crazy to have both: you have a configuration file that says where things go, but the values must be set to constant well-known values. Sounds kind of crazy so I've never done it but you would get consistency and discoverability. I expect people would complain about the redundancy though.

None of this is nonsensical though.

• Adafruit - brand name; meaningless in any industry.
• ESP32-S3 - product code; random numbers in any industry.
• Reverse - screen is on the back.
• TFT - Abbreviation for the display technology.
• u.FL - Abbreviation for the antenna type.

You could easily have something like that about e.g. mountain biking:

NEW PRODUCT - Sram Xg-1299 Eagle 10-52 Cassette

I've definitely seen "this is more correct, but all the other code does it like this so can you change it?"

I can't say I entirely disagree with it either - usually the "more correct" is not "the existing code doesn't work at all", and keeping it consistent makes it easier to fix all of the code later, because you're only fixing one style instead of two (or more).

Ha you only think this is unique to tech because you don't have experience of it in other fields.

I'd settle for detailed short term local rain forecast. It's such a huge application and as far as I can tell (please correct me if I'm wrong!) nobody does it at all well.

• Often ensembles are only run every 3 or 6 hours, so the predictions are needlessly out of date.
• The ensembles have a very small number of runs (like less than 10) so you can't get a good estimate of probabilities.
• Usually you can't get access to the raw data anyway and user facing sites dumb things down to a single number, so e.g. "it's going to drizzle all day" and "it's going to tip it down for half an hour at some point" are presented exactly the same. As are "it's either going to rain loads or not at all" and "it's definitely going to rain a bit".

No, they're inherently optional in Git. There's no way to "check in" a git hook. You have to put in your README

Clone the repo and then please run pre-commit install! Oh and whatever you do don't git commit --no-verify!

You definitely need to actually check the lints in CI. It's very easy though, just add pre-commit run -a to your CI script.

So... to store encrypted data that only the user can decrypt you don't need any fancy zero knowledge algorithms. Just have the user keep the encryption key.

For authentication you could use one of these algorithms. OPAQUE seems to be popular. I'm not an expert but it seems like it has several neat zero-knowledge style properties.

But probably forget about implementing it without a strong background in cryptography.

To check that people ran the pre-commit linters.

Committing itself won’t be possible

That's not how pre-commit hooks work. They're entirely optional and opt-in. You need CI to also run them to ensure people don't forget.

Yeah this is weird. I thought they'd switched to ARM.

You need them in CI anyway to check people have actually done that, but yeah you definitely don't need to have CI automatically fix formatting and commit the fixes. That's crazy.