There are so many. Sometimes they're big picture stuff, sometimes they're more detailed.
One of the lessons I learned in my junior years is that I used to write CSS with a lot of nesting and relatively short class names (I used SCSS which made nesting easier) - The CTO kept telling me that I should avoid using more than 2 levels of nesting and to use long descriptive class names. I felt that was against the whole point of "cascading" in CSS. I soon discovered (during the first redesign) that when you have a lot of nesting in the CSS, it becomes extremely difficult to refactor the layout of the application; moving containers around breaks the layout every time. Whereas if you have a relatively flat CSS, you can move around components easily without breaking anything. It seems so obvious in retrospect.
I also learned the importance of having one source of truth and the importance of making sure that each kind of data flows through the system in a single, clear direction (or else you can get glitchy behaviour with certain kinds of realtime data). A common one is to make sure data flows from the source of truth. For example, when you click a component, it should update the URL hashbang, then other components should react to the change in the URL... Don't make the components react to the click directly and only update the URL hashbang as a side effect (because the click event could conflict with the URL change event in some edge cases; e.g. cause the UI to be rendered twice is a common issue). The URL has to be the source of truth.
Another critical lesson was about separation of concerns and the importance of being able to justify all technical decisions using simple non-technical language.
But there are so many lessons. I was fullstack so I learned a lot of backend tricks as well. A different one seems to come up every day when I work with other developers on a complex project. I try to explain the reason as much as possible because sometimes they sound counterintuitive (or I should say counter-narrative) and they're not usually silver bullets so it's important to convey the nuance as well.
The main point is that a software developer's job is to fix stuff so you end up introducing complexity, but you will have a much easier life if you realise when you're about to introduce more complexity, and try to minimise it by thinking about your implementation choices. KISS, I guess.
Nice, this is a broader way to explain the effectiveness of my CSS approach and many other approaches. IMO, Modern developers should read fewer books about tools and more books about software philosophy. It's far more important.
It's weird to think that philosophy can actually yield productivity gains... Many people think of philosophy as being the anti-thesis of productivity.
