Other people
- Working with people considerably better than you, named first in the most-voted answer.
- Listening regardless of seniority, on the explicit grounds that job titles predict very little.
- One contributor described a new colleague, younger and plainly better, who made it obvious they had not improved in years — and that this was what started them improving.
Reading rather than writing
One answer put two activities above everything else: read code written by other people, and write documentation for code written by other people. Its observation is that producing code is the easy part and nearly everyone can do it, while reading someone else's and working out what it does is a separate skill that has to be learned deliberately. Documenting somebody else's work forces that reading to be complete, because you cannot describe what you have not understood.
Breadth as insurance
Another answer described specialising deeply in one database and language early, then finding their options narrowed sharply when that technology lost ground. The conclusion drawn was a deliberate policy of never being boxed in again — studying widely across systems and languages, not because breadth is inherently better but because depth in one thing is a bet on that thing continuing to matter.
The pattern underneath
- Learning other languages and frameworks in order to compare approaches, rather than to add them to a list.
- Revisiting your own older code once you know more, and changing it.
- Every one of these requires exposure to work that is not your own — which is the common thread across an otherwise varied set of answers.