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.
https://www.amazon.com.au/Philosophy-Software-Design-John-Ou...
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.
It's weird to think that philosophy can actually yield productivity gains... Many people think of philosophy as being the anti-thesis of productivity.
That said there are projects for which a developer could be infinity-x compared to other regular developers. For example, a highly complex project which regular developers do not have the capacity/talent to complete, ever... Just imagine some very complex project programming a quantum computer or certain kinds of blockchain or distributed systems projects; some developers will never be capable of delivering such projects. It's beyond their innate ability and capacity for learning.
Project complexity maximizes the utility value of highly productive developers. It would be difficult to identify a 100x developer on a simple project (they might only appear as 2x) but they would stand out as a definite 100x on a complex project.
From best colleague: 10x, 100x, 1000x... developers are real. I also learned that making bold, controversial claims will yield respect dividends in the future when they turn out to be true. For one of my past startups, I was working closely with the CTO who was at least a 10x or 100x and some of the stuff he was saying seemed to defy a lot of the industry practices at the time. I didn't take what he was saying very seriously at first, but over the years, I ended up discovering that essentially everything he said was true and lead to huge productivity increases. It had a big impact on me to understand that software development is a craft which can be mastered on a whole different plane beyond what the vast majority of developers can imagine. I consider a lot of his teachings to be 'trade secrets' and I try to pass them on to other developers I care about (especially open source collaborators).