Advice that I give to interns/grads:

In uni/college, you're taught *how* to code something to achieve a goal, and 99% of the time the code will work and do the job in a lab.

But when building things for a real production environment, you learn the 100 ways how *not* to code, from seeing things break left right and centre - basically everything and anything can break your code, whether it is users, the OS, other people's code, legacy code, lag, concurrency, the alignment of the moon to your server...

++ for alignment of Moon to server😂

If I knew about this moon stuff I would still have a job

@TktStatusPICNIC in hindsight it does, a bit anyway. I consider myself lucky to have had one good lecturer, who instead of teaching us C or Java like the other courses, taught us shell scripting, perl and unix commands. The point was that there are many ways to solve a problem and it's up to you to decide what the best tool for the job is, and not just going to a default (e.g. two piped unix commands vs 100 lines of code).

But what they didn't teach at the time is the importance of source control/versioning and actually putting it into day to day use, or automated tools for builds, testing, code coverage/quality. Basically they should make uni students deliver assignments via Continuous Integration/Delivery rather than 6 week waterfall cycles :)

As a programmer that is taking a dregree at computer science and works in the field this is a very good asvice ti everyone. So many times I have to solve problems not related to the code I have produced so we can acomplish some ramdom project. And so many times things broke that didn't had to do with programming....
Ahhhh... feels better now

@Shadow117 over time you start to build up an idea of what silly things can break your code.. so the challenge comes from making your code more robust to handle those situations.

An example is a user can double click on a link (like a submit button) which in turn fires off two http calls, making the app run the same bit of code twice for the same data, leading to two concurrent t database calls where the first call blocks the second one and then the app implodes... But the first call had secretly updated the database already....