It’s gotten a lot better in recent years tbf in terms of those kinds of resources. Beginner recommended languages like Python are still a pain because it’s super easy for a beginner to bork how they set it up, but on the whole there’s plenty of online code sandboxes and other ways to get started.

Your point is definitely valid though. Why on earth would we want someone who’s just showing an interest in programming to write their own compiler??? Wtf? If someone wants to get into baking you don’t send them out into the fields for 6 months to grow some wheat.

When I was a kid I mucked around with html and css to make some GeoCities sites. I decided I wanted to learn how to code so I got a book from the library called “how to code games for beginners” or something. The thing never told you how to set up an IDE or compile the game. So I was just frustratingly typing out the code examples into notepad without a clue as to what to do. I think this was during the dialup era so it wasn’t like there was a wealth of info online.

I ended up abandoning programming for quite a few years. It just seemed like nonsense because writing graphics libs for C in notepad does feel like nonsense to a child. I wonder what life would be like if I had some better resources at that moment in time and decided you continue pursuing it.

Spain would probably be around that much if my calculations are correct.

The jury system is bullshit and needs to go.

It’s doable once you know what you’re doing. I can do it all via the cli, but I personally use gitkraken most of the time and it’s just so much easier and more ergonomic.

I also see a lot of the Devs who insist they know what they’re doing create horrible messes of their branches super easily via the commit tree. People should just use whatever works best for them to get the job done.

Yeah “why” comments are absolutely fine, “what” comments are useless at best and can be harmful at worst.

I feel like this constant flood of “write comments” posts are from CS students who are told to comment everything by their lecturers. Descriptive variable and function names help explain the “what” of code pretty well most of the time.

Sure with some old languages like C89 where you are limited in your variable name length you probably do need comments to explain wtf is going on, but most code bases aren’t as constrained.

We test the shit out of our Apis. We do more API level/integration testing though.

I.e. a test will be something like “if the db is in this state, and we hit this endpoint with these params, does it return what we expect and update the db correctly”.

Our app is primarily about users maintaining stuff on big datasets with complicated aggregation and approval logic. So setting up a scenario and checking the app does what the business logic says it will do is what we want to know.

It makes refactoring wayyyyy less painful to just know that the app will always behave itself. Rather than testing whether a function can add 1 + 2 correctly, we can test each endpoint does what it’s supposed to do.

It gives us loads of confidence that the backend is doing what it’s supposed to. If you do a huge refactor you don’t need to worry about whether you broke the test or if the test is failing correctly. If the tests all pass everything is working as it should.

Downside is longer test execution times (because a temporary db needs set up) when running the full suite. Worth the trade off for us though.