1. NEVER practice Coincidence driven development. If you get lost, and no longer know why something is not working, do not just keep fiddling and changing thin

1. NEVER practice Coincidence driven development. If you get lost, and no longer know why something is not working, do not just keep fiddling and changing things. Simplify the problem. Disable all confounding variables and observe your changes. Open up a repl and try to reproduce the issue in your repl. Read the source code of your dependencies. I have seen this a lot: People fiddle with dependencies trying to get them to work. Crack the code open and read it. 2. Choose your battles. Not every hill can be the one you die on. You cannot control every part of a code-base when you are working on a team. People are going to move your cheese and you need to learn to not let that affect you. 3. Learn to lose. Similar to the last one. Treat technical discussions as discussions, not a competition. Use neutral language that frames your ideas as NOT your ideas, but just other options. Keep an open mind and let the best idea win. 4. Write tests. There are outliers here, but the majority of talented engineers I have worked with are all on the same page: If you don't have tests, you cannot safely refactor your code[0]. If you cannot safely refactor your code, you cannot improve your codebase. If you cannot improve your codebase, it turns to mush. 5. Simplicity is golden. Keep your projects simple, doing the bare minimum of what you need, and do not refer to your crystal ball for what you might need later. Single responsibility principle. Keep your Modules and your functions simple and small, and combine them to create more complicated behaviour. 6. Quit shitty jobs. If you are not learning at a job, or they are abusing you, you need to get the hell out of there. Burn-out is real. Burn out on something cool that helps YOU, not pointless toil for some corporate overlord. 0: Martin Fowler's Refactoring 2nd edition