I am still barely getting started with my career, but I've worked alongside enough engineers to start recognising patterns. Everyone has a modus operandi: habits you start to recognize in their code. Some of those habits are what distinguish a programmer from a software engineer, at least to me. Some of these M.O.s are, in fact, crimes
The Rules§
These are the rules I keep coming back to.
Code that is not checked into version control does not exist.
I have personally watched someone spend three days tracking down a bug, fix it, and then lose the fix because it was never committed. When something goes wrong at 2am and you need to roll back, "I had it working locally" is not something you can deploy.
Legacy code is code without tests.
By that definition, you may be writing legacy code right now. Tests let you check whether a change breaks behavior you already depend on. Without them, you have to check it manually or hope you didn't miss anything. (Further reading)
Automate what's possible.
It's often faster to do something manually the first time. If I keep doing the same task, though, I start looking for a way to automate it.
Code is never correct the first time.
Assume the first version has bugs. Check your assumptions, test it, and expect to revise it. You'll find the bugs during development or in production. Preferably development
Readability is not optional.
You will spend far more time reading code than writing it. Code that is hard to follow is technical debt from the moment it is committed. Saving three lines isn't worth it if the next person needs twenty minutes to understand what you did. That person might be you in six months.
If it isn't in a ticket, it doesn't need to be done.
Write down what needs doing and why. Otherwise it's too easy to disagree later about what was requested, or to spend a week on work nobody knew you were doing.