|
|
|
|
|
by georgieporgie
5398 days ago
|
|
Assuming you mean programming professionally (i.e. most of every day), then five years is around the point where you become self-aware and realize your code isn't as awesome as you thought. Also, remember that if you see code published on the Internet, it was probably extremely polished, and likely written by someone who has had quite a lot of experience in a particular area. By having to maintain my code, I learned to write simple, concise, well-documented code. Nothing teaches you about bad programming practices better than having to maintain your own code after six months or a year away from it. I've also learned that iteration is key to quality. The first time I create something, it's basically crap. By about the third time I've tackled the same sort of problem, I have some pretty good insights, and come up with vastly improved solutions. Of course, people see the output of the 3rd iteration and think I'm a brilliant, insightful programmer, not realizing that -- like everyone -- it didn't happen on my first try. |
|
My other benchmark of bad code is that you know it's bad when you have to hack it to add a new feature, and the only way to remedy that is to re-factor most, if not all, of your codebase.
I've had to do this a lot lately because I've not had chance to iterate. I know full well the code is bad. It works but it's not easily maintainable, and since it's in the context of a REST API there's a shitload of code we now have to duplicate - with minor differences - to add functionality I didn't have the foresight to plan from the start.
That of course is also the side effect of being given an entire project to do by yourself while the rest of your team does other things. The insight and assistance from colleagues or team-mates, or even friends if it comes to it, is just as valuable for writing good code. Knowledge has to come from somewhere.