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

"I think you can tell a competent software developer from an incompetent one with a single interview question: 'What's the worst code you've seen recently?' If their answer isn't immediately and without any hesitation [the] two words 'My own.' then you should end the interview immediately."

Note I am not promoting spaghetti code. If it's not blatantly incomprehensible (i.e. you abide to some common sense) and works, you are set.

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. YMMV.

http://codereview.stackexchange.com/

It seems possible you are being exposed to mentors that are being too harsh on you. Certainly you're being too harsh on yourself. Go forth boldly and code.

Take some time to read about _why's philosophy on coding and making mistakes. I think it would do you a world of good.

A few years ago I started working on a game, the best ever I thought. I was so clever with everything I thought and oh I wouldn't need to refactor because I would do it right from the start!

Of course I moved on and started to work on other things for a while and when I came back I thought it was horrible, almost unusable!

This happens all the time, though at a lesser extent, for me. When I notice something new, fresh, nice or beautiful way of doing things the old way is simple not good enough. Why did you ever do it that way?

Don't bother too much - it's normal and it shows that you're always evolving and getting better. And after all, you learn by doing mistakes not by doing everything beautiful and perfect from the start.

The best thing I can suggest is expanding your horizon as far as possible. Your profile says you're a RoR/JS programmer. Go learn some Haskell (or any other functional language; I started with Racket) and you'll find a truly different way of looking at programming, one which will change your style forever.

You have healthy appreciation and respect for work better than your own, always a good sign, and it means you should expect to keep improving simply by keeping at it. Same is true in any field.

1. Debug and refactor. Early on, I'd stumble through creating a script. It was usually write three lines, see if that worked, repeat. I didn't plan ahead enough, and by the end, my code was just layers of ideas tightly held together by a file name. This aggravated me, so after I'd get my scripts working, I'd completely rewrite them from scratch, making improvements where I saw them, simplifying code wherever I could.

I've learned more debugging (generally my own) code than I have from any book or teacher.

This was a lot of time spent, but eventually I could start seeing ahead and could make those changes in real-time as I was writing them. I'm not saying that I don't go back and refactor my code now, but when I do it's usually to fix things for speed or bugs, not for code cleanliness.

2. Plan ahead. I know some people that write out the entire shell of their program -- all of the functions and names and comments of what each function will do -- before ever writing the actual logic. I never had the patience for that, but you can still plan ahead.

Take a look at what you're trying to accomplish, and find the areas where you know you don't know what you're doing. Do a bit of research on those points. See what others have done, there's a really good chance you're not the first person to do those things. If you're still not sure, ask for help. The community is almost always willing to help.

3. Clarity over cleverness, always. I always take the road that will be more easily maintainable in the long run rather than the code that will work the fastest. (But, you know, if you can hit both at once, awesome.) I like breaking things down into simple bits. All of my functions are either only accomplishing one task, or are strings to those one-task functions put together to do something complex (but is still considered one task).

4. Learn, practice, learn, practice, repeat. Don't just stick with one language, branch out and see how other languages tackle similar problems. Take a look at code that you thin is better than yours and figure out why you think that. Take a look at code that's worse than yours and figure out why you think that. Write those things down and keep a list next to your monitor. Review them each time you sit down. Put them into practice. A lot.

5. Perspective. Take a look at your own work from 2-3 years ago and look at how far you've come. You've probably covered more distance than you think. Even if you're not 100% happy with where you're at, the progress will be reassuring.

6. Finally, stop worrying about it. Think of some people that are really good at what they do: professional athletes, professional plumbers, professional anything. When they're in the clutch moments, they're not stressing about how what they're doing looks, they're in "the zone," their mind lets go and instincts take over. Programmers develop those instincts too.

You're probably much better than you think, and you're only going to get better every time you program. :)

Rewrite.

Write some code, make sure it works, and then look at places where it's ugly and figure out how to rewrite it so that it's better.

You won't write good code the first time, unless you're writing something that's trivial for you (too easy).

While the examples are too Java specific, the book Refactoring by Martin Fowler is a terrific introduction to the skill of improving code.

Just in time, not just in case.

The things you will read about in it can open your eyes for better recognizing where you can improve your code, how ti apply _this_, how to solve _that_, and can give you ideas and new ways to look at structuring your code for better reuse.

Design patterns aren't an end on itself, but means write more modular, readable, understandable code.

The people with opinions about your code are probably not paying you. So coding well is more like being polite to them. Really good code makes their lives slightly easier than average code (which is way better than no code).

But politeness goes both ways. If they see you trying to improve, they'll probably try to help you.

PS - When people want to get better at somthing, the biggest mistake they make is assuming they can get better inside their current comfort zone. So if you want to improve, get lost for a while. Try writing an OS. Or a physics engine. Or learn a Lisp. You'll be surprised how fast Experience - From - Elsewhere translates into more skill in your day job.

1) write tests first because then you can write something ugly that works and then refactor underneath passing test coverage

2) expose yourself to other peoples code. My tendency is to stare at my own stuff all day (or other people's unattractive code). A natural place to look at good code is to be quick to open up libraries you are using in a project and rummage through them as the need naturally comes up in your work

Also - consider buying code reviews from developers you respect - even a couple of hours a week can make significant difference to your quality.

I might be making some wrong assumptions, but I think the people whose code is really bad are the ones who think their code is good enough, or the ones who just code quickly without thinking. (I tend to think quite a bit and then code. In fact for the particular project I'm on right now, I'm doing a lot of thinking because I know the current architecture is not good enough. IT would be pointless to start writing code and then try to bash into shape- like building a stone bridge and then realizing you need a 57 chevy. No matter how much you take a hammer to that bridge it is never going to look like a 57 chevy.)

When I go back and look at code I did in the past, without having looked at it awhile, I see that it is really quite brilliant. I bet you'll see this in your code to. The thing is, the other person-- other's code, or your past code- is written when they have the full context of whats' being written in mind at the time they're writing it, and in the process of understanding their code you're going to see how their solution is more elegant than the naive solution you might have tried if you tried to write it just now.

Code takes thinking and refinement... and doing either will make code look better, and may be the source of your insecurity.

But, if your code really isn't "good enough", then maybe the issue is that your idea of "good enough" is too good. If its never going to be re-used, does it need to be reusable? If its not going to need constant maintenance, does it need to be beautiful? I have some code that I look at very, very rarely. Its in production, being used by customers every day, lots of customers. I know it is junk because at the time I wrote it, I was attempting to pull off a massive effort to get a product done. But the code isn't' throwing exceptions, it doesn't have bugs, and the customers are asking for new features, not fixes. So, I know its is ugly, I remember how ugly it was at the time, and every time I do have to go in I clean up bits and pieces of it. But it is working great... it is doing everything it should be.

And so, that code really shouldn't be good enough... because the time making it "good enough" is wasted time. If I wasn't the solo programmer on that project, then other programmers would likely work with me to clean it up... that's natural... but in startup land, sometimes ugly code that is solid is going to remain ugly code, because the point here is building a company.

Do you want a cathedral of very pretty code? Or do you want to build a startup?

I don't mean to denigrate your feelings... I think that your desire to improve is a good thing. I think the best thing you could do is to learn another language. (I'm just guessing that at 4-5 years you've probably really used one language a lot and 1-2 others a little bit.) Learning something radically different can improve you a lot. I'd recommend erlang (but I always recommend erlang.. it is the manly language that will make you a man (or woman))... or maybe you could use some scripting chops or whatever. Pick something out of your comfort zone, even if your'e going to be writing in your main language for a long time coming.

Knowing that other language will help you write better in your current language, and I think it will make you appreciate what you're writing in your current language better as well. I could be completely wrong here, but the best bang for the buck for me has been when I went outside my comfort zone and learned a very different language.

Finally, humans are bred, via natural selection, to have a certain amount of insecurity. We're supposed to fear that we're inadequate as it produces a wariness that helped keep us from being eaten by predators in the past.

Use it to keep you motivated to do better, but always make sure you're focusing on the right "Better". EG: IF you're in a startup, better is faster growth for the...

http://www.shadowcat.co.uk/archive/conference-video/yapc-eu-...

Any time somebody says they feel like you do, I throw them a link; it seems to help.

Keep coding, and as always ask the developer community for help and advice, stackoverflow has certainly helped me a lot.

I have the opposite problem where I'm generally happy with what I write, it works and is usually well-factored, but it seems to take me fucking forever to get it to that point. So count your blessings :-)

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.

In my own experience, mathematics is the only way to gain assurance.