As someone with decades in the industry, the amount of awful code out there is staggering. The code that I write is also often awful - at least the first time I’m exploring a new complex problem. Once you’ve done something once though, your second or third time writing it is typically a lot better.
Typically my first pass ends up being a “get it done” pass. Explore the space with as best effort as you can to get something that works. Then identify what issues or problems you had with the process.
Refactor your code, back up frequently! Prefer to keep things to generally one abstraction per function. This allows you to quickly look at a something and identify what it’s doing, and to (with experience) sus out any potential bug areas. Make your code consistent in naming & code flow if you can. Test your code frequently.
It’s like playing a factory-genre game; your first pass is likely going to be some spaghetti monstrosity that quickly runs into scalability problems because you didn’t know what you’d need ahead of time. With the knowledge of what pain points you had, you make a new base, maybe incorporate a bus setup and your scalability now goes much higher before it reaches problems. On your nth pass, your base is now a train based system that runs like clockwork and can do things you never thought possible before.
Tl;dr: Everyone’s first approach often sucks and eventually runs into problems. Understand what didn’t work and learn from your mistakes. Do it again with these lessons in mind when you feel inclined (if you’re experiencing scalability problems). Look at other code & learn from others. Keep writing as much as you can - programming is difficult and hard learned experience is often the best teacher.
As someone with decades in the industry, the amount of awful code out there is staggering. The code that I write is also often awful - at least the first time I’m exploring a new complex problem. Once you’ve done something once though, your second or third time writing it is typically a lot better.
Typically my first pass ends up being a “get it done” pass. Explore the space with as best effort as you can to get something that works. Then identify what issues or problems you had with the process.
Refactor your code, back up frequently! Prefer to keep things to generally one abstraction per function. This allows you to quickly look at a something and identify what it’s doing, and to (with experience) sus out any potential bug areas. Make your code consistent in naming & code flow if you can. Test your code frequently.
It’s like playing a factory-genre game; your first pass is likely going to be some spaghetti monstrosity that quickly runs into scalability problems because you didn’t know what you’d need ahead of time. With the knowledge of what pain points you had, you make a new base, maybe incorporate a bus setup and your scalability now goes much higher before it reaches problems. On your nth pass, your base is now a train based system that runs like clockwork and can do things you never thought possible before.
Tl;dr: Everyone’s first approach often sucks and eventually runs into problems. Understand what didn’t work and learn from your mistakes. Do it again with these lessons in mind when you feel inclined (if you’re experiencing scalability problems). Look at other code & learn from others. Keep writing as much as you can - programming is difficult and hard learned experience is often the best teacher.