Like other design disciplines with multi-faceted outcomes and a plethora of metrics, it's probably not useful to think of programming as a linear progression of

Like other design disciplines with multi-faceted outcomes and a plethora of metrics, it's probably not useful to think of programming as a linear progression of wisdom or capability. That said, IMHO one of the more important epiphanies comes with maintenance of a complex system against evolving requirements over time. Until you've done that, your designs will never be maintainable and your documentation will never be adequate, and a design-for-others / design-for-future-selves mentality is arguably the best definition of 'good enough'. Put everything in version control, and document your requirements, reasoning and failures. If you are designing anything that is intended to last longer than 6 months, documentation is a critical part of the system. Meetings are great for communicating with people here and now, but only writing can communicate with people from the future. When you meet with your current colleagues, spare a thought for your future colleagues who haven't yet joined, and do them a favor by writing things down. Ability to use written communication is a major differentiator between junior and senior engineers. - @jl6 Another good epiphany is small is beautiful. Do one thing and do it right. Use collections of scripts instead of integrated monoliths. Don't be afraid to throw them away and rewrite them. Interfaces are far more important than code. The cheapest, fastest and most reliable components of a system are those that aren't there. - Gordon Bell Decrease fear of failure. Experiment constantly, fail early and often, remember and document those failures, and learn as much as possible in the process. You can read more wisdom at https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup