Hacker News new | ask | show | jobs
by steve8918 5398 days ago
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.

2 comments

Sorry, but actually it sounds like quoted from a (programming) fantasy novel. Look at the other comments, who argue that the nice and clean code is not always the best, not always the goal and sometimes not even a goal that can be achieved. This(!) is what you learn from experience.
I've heard the same thing for 15+ years now. "There's not enough time, I have to check it in." "I'll clean it up before we ship."

The time difference between writing clean code and crappy code is negligible. The main difference I saw was always in the attitude of the programmer. This is what you really learn from experience. There are lots of programmers out there with diva complexes who think it's beneath them to write easy-to-understand code, or love using 1-character variable names, etc.

Sure, maybe there might be situations where you don't have a lot of time, for example, if you are programming algos for HFTs and the traders are standing over you yelling that they need a particular parameter changed and they are losing a thousands of dollars per minute.

But in most other situations, it doesn't take much time to type "ptrCache" vs "ptr1", or add comments so that the next person who reads your code won't be scratching their head wondering wtf you were thinking.

Extremely well put. Took me alot of humility to get to get to this conclusion.