Software engineering is about state management and team dynamics. I'm fairly poor at the second so all I'll say is that being good at the politics/communicatio

Software engineering is about state management and team dynamics. I'm fairly poor at the second so all I'll say is that being good at the politics/communication becomes more important as you become more senior and is ultimately more important for your career than being good technically. Technically, the most important thing I learned after I graduated is that state is the most important thing in production systems. Programming paradigms, system architectures, and design patterns are all rooted in managing state. Almost always by constraining it. For me the critical talk on this was Rich Hickey's "Are We There Yet" but I'd been writing functional code for a couple years when I saw it. When I've directed people to it they find it weird/confusing and have more success with "Simple Made Easy" which I find similar but less insightful. A focus on state first has been the cornerstone of my development philosophy since 2009. It's not universal (e.g. data oriented design) but it's my one weird trick. I'm a visual thinker and visualize a piece of state as a gas that leaks through calls and variable scope. If it's in the database it leaks through queries accessing the table and the services that expose it. The fewer things state touches, the better because people fundamentally are terrible at understanding interactions over time (e.g. three body, double pendulum). Seeing the state flow through the system tells you how well it's designed/built and where the problem points are.