Ask HN: I think My code isn't Good enough

Someone downvoted this? This seems like good advice to me...

//Of course this is my view after having spent non-trivial amounts of time making code beautiful, modular and reusable instead of trying to solve the problem at hand.

I can identify with that feeling. working at a startup made me realize that i have spent more time reading code than writing code. While that's not a bad thing on it's own, i had lost sight of the joy from building/improving things/product. I have been programming for 4-5 years now and pissed that i don't have a product of my own(crappy/otherwise).

First and foremost, write your code so that it can be understood easily by someone that knows nothing about it. As you get older, you'll realize that this person is you! Anything written over 2 weeks ago is often like looking at new code, so make sure you have good comments and non-obscure variable names so that you can understand it easily. This also makes it easier on your coworkers.

Second, write for readability and maintainability. Save optimizations for the last step. If your code is properly modularized (but not OVERLY-modularized) then you'll be able to selectively optimize and get good performance. As you grow as a programmer, you'll realize that having maintainable code (ie. code you can change easily with new features, or changing requirements, etc) with really good performance is far more valuable than terrible code with the fastest solution. Well-written code that is flexible and that you can shape like putty and add features to do what you want is exactly the point of programming.

The one thing you don't want to do is design code and products that become unmaintainable to the point where the costs of adding features becomes a nightmare. This is what I call coding yourself into a corner. I worked on a project where adding a single feature had a 3 page matrix of things that might break, and would need a lot of QA effort to validate. This is not maintainable code, and an example of where every new feature gets exponentially harder to add, which pretty much kills the product.

Third, I think it's great that you don't think your code is good. This means that you care! I would say only 40% of the coders I've come across actually cared about making their code better, or about mastering the art of programming. Just keep on programming, have a thick-skin to code reviews (I gave a code review to a new programmer who burst into tears because she had never been code-reviewed before), and be willing to learn. I have 15+ years of experience, and although I'm comfortable with my own style, I'm very open to criticism and always willing to learn.

Let's take programming out of the equation with a quote.

"Laws, like sausages, cease to inspire respect in proportion as we know how they are made." - John Godfrey Saxe.

The problem with looking at any recent code that you write is that you know how it was made (i.e.: you are in the kitchen making the sausages). But it's different if you are the customer eating the sausage. Even if the cook told you how the sausages were made, you still don't have first-hand knowledge, so you elide over the means (good or bad) to get to the ends. It's only when you really dig in and start to understand the process you start to see that the people making the same things you make are in the same boat as you.

So if I've recently seen code that is subjectively worse than the worse code I've ever written and I answer that question honestly, the interview will immediately end? That seems like a poor way to judge a developer.