Every good programmer was once a bad programmer. They typically evolve into good programmers by iteratively identifying what they don't like about their own code and fixing those issues. Those fixes will often need fixes down the line, but that's okay.
Your first step for that identification should be to list your priorities for the end result. Readability? Robustness? Speed? Compactness? Reusability? Extensibility? Once you know by what metrics you want your code to be "good", you can start to examine where your code falls short.
The other key thing is to be unafraid to write bad code. It's hard to know when or why something's bad until you've held it in your hands, fiddled with it, given it a good swing. From there you can refine it by whatever metrics you've prioritized (per above).
Such a profound and counterintuitive truth - shows up everywhere and it is easy to miss the second order effect by focusing on the immediate impact.
For example, science tries to be more correct by seeking out the places where it is wrong, but so many people who would be afraid to be shown to be wrong and will pretend they aren't even when they are.
Or for another example, evolution makes things robust by intentionally eating shit and dying. Yet humans use this as an insult! So you have a beautiful idea that outperforms what we think is clever when given long enough, but look how badly our culture evaluates it!
The cleverest approaches are actually intentionally stupid: game theoretic reasoning in complex situations under imperfect information calculates the counterfactual regret of the worst outcomes it could experience relative to what it actually did. Collecting the right experiences is actually what lets you get to the better experiences.
Comments
Every good programmer was once a bad programmer. They typically evolve into good programmers by iteratively identifying what they don't like about their own code and fixing those issues. Those fixes will often need fixes down the line, but that's okay.
Your first step for that identification should be to list your priorities for the end result. Readability? Robustness? Speed? Compactness? Reusability? Extensibility? Once you know by what metrics you want your code to be "good", you can start to examine where your code falls short.
The other key thing is to be unafraid to write bad code. It's hard to know when or why something's bad until you've held it in your hands, fiddled with it, given it a good swing. From there you can refine it by whatever metrics you've prioritized (per above).
Also, every good code started as bad code.
Counterintuitively, being afraid to write bad code actually leads to bad code.
Good code is not a state, it's a process.
Such a profound and counterintuitive truth - shows up everywhere and it is easy to miss the second order effect by focusing on the immediate impact.
For example, science tries to be more correct by seeking out the places where it is wrong, but so many people who would be afraid to be shown to be wrong and will pretend they aren't even when they are.
Or for another example, evolution makes things robust by intentionally eating shit and dying. Yet humans use this as an insult! So you have a beautiful idea that outperforms what we think is clever when given long enough, but look how badly our culture evaluates it!
The cleverest approaches are actually intentionally stupid: game theoretic reasoning in complex situations under imperfect information calculates the counterfactual regret of the worst outcomes it could experience relative to what it actually did. Collecting the right experiences is actually what lets you get to the better experiences.
100% agree. Took me way too long to understand this.