
Ask HN: I think My code isn't Good enough - mabid
I have been programming for the last 4-5 years but whenever I look at some good code written by some one else I always have this feeling that my code isnt good enough. By "good enough" I mean that my code isn't as beautiful(readable) and reusable. I always try to change the way i do things the next time but i keep getting this feeling. Do you guys ever fell like this and what you think I should do  to improve on that ?
======
nuclearsandwich
It's constant, almost everyone experiences it. Best thing to do is look at
some really old code you wrote and realize how far you've come. After that,
write more code, read more code, write more code. Programmers all want to be
better, this drive helps us become so, but it also drastically diminishes our
ability to be content with our current situation. If you really want to see
how far you've come. Find someone who reminds you of yourself and mentor them.
It's much easier to perceive change in others than change in ourselves.
Watching mentees progress reminds you of when you underwent the very same
realization and helps you become more aware of liminal points in your
programming journey.

~~~
geoka9
> Best thing to do is look at some really old code you wrote and realize how
> far you've come.

When I do that, I tend to get surprised how good it looks contrary to my
expectations of coming far since then.

And sometimes when I look at the code of some famous project I like, I may get
surprised how bad it looks.

Maybe this is the difference between "rock star" programmers and your average
perfectionists out there - the former just get the job done, while the latter
spend too much time making their code look beautiful.

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

~~~
erikb
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.

~~~
steve8918
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.

------
icey
Ask people to look at it and give you feedback. There's a new Stack Exchange
just for code reviews that you might want to check out:

<http://codereview.stackexchange.com/>

------
kgtm
You say you have been programming, but not if you are solely a programmer or
building a product as well. Perhaps it would be easier to think of code as a
medium to achieve a higher goal, which is functional software. I'm inclined to
believe that this is more important than "code beauty" which is something
highly subjective and tends to be constantly evolving with _your_ experience.

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.

~~~
aangjie
//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).

------
unoti
You do want to improve, but just relax and do your best work. Continue to
learn and read other people's code that you respect. But don't let your desire
to improve and impress others stress you out. Also, consider the rule of
threes on reusability: <http://www.rimmkaufman.com/rkgblog/2007/10/16/rule-of-
three/>

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.

~~~
s-phi-nl
Do you have a link to _why's philosophy on coding and making mistakes? A quick
Google search did not yield anything. Thanks.

~~~
losvedir
This letter from him[1] came up on HN a week or two ago.

[1] <http://aberant.tumblr.com/post/167375099/a-letter-from-why>

------
shawnz
Here's Jeff Atwood's take on it:
[http://www.codinghorror.com/blog/2009/07/nobody-hates-
softwa...](http://www.codinghorror.com/blog/2009/07/nobody-hates-software-
more-than-software-developers.html)

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

~~~
pyre
That's a poor way to judge. I'm always looking at my code and thinking that
it's not good enough, but there are _definitely_ pieces of code that are worse
that I deal with daily (I work on a code base that's > 20 years old).

~~~
shawnz
It's a poor way to judge code, yeah, but the more important thing it speaks
to, IMO, is the respect the developer has for the fact that other people will
actually be _executing_ the code they write.

~~~
pyre
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.

------
joshcrews
The two things that help me the most in this department are:

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

------
josephg
I've been programming for about 17 years and here's what I tell my students:

Every program has 2 goals: To explain to the computer what you want it to do,
and to explain to people what you want the computer to do. Good code is
readable and correct.

The first time you encounter a problem, your first idea of how to solve it
will be awful. This is true no matter how long you spend thinking about it, no
matter how much experience you have. The best workflow involves thinking, then
coding, then thinking, then throwing away most of your code and doing it
better. You can't find the flaws in an implementation while its in your head -
you need to see it on the screen before you can fix it. Your second
implementation will generally be better. The best code I've written I've
iterated on 3-4 times until it looks simple and obvious.

Unit tests will help you iterate - write them before / just after your first
attempt at the code. Then when you rewrite the code you'll have confidence
that you haven't broken it.

You're not writing poetry. Sometimes your code is hard to read because you're
doing a simple thing in a complex way. Other times your code is hard to read
because its algorithmically complicated. In the second case, spreading the
algorithm out over lots of places will make it almost impossible to
understand. So, don't stress out when you can't make your code into a haiku.
Sometimes you can't - but you should try anyway.

The best way to learn what good and bad code looks like is to read code. At
first, reading code will be harder than writing it. You should do it anyway.
Your own code is ok, but other people's code is better. Pick an opensource
library you use and try and figure out how you would write it. Then read the
code and see how they did it. Their method might be worse than yours. - But
remember, their project is successful anyway.

------
awwx
_what you think I should do to improve on that_

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.

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

------
stonemetal
I have never believed in beautiful code. That is like saying there is a
beautiful spanner or crescent wrench. Save the beauty talk for the Rembrandt
and Monet. I pursue two things in my code Clarity, relentless reliability and
simplicity. Clarity because I am like the girl from 50 first dates I not going
to remember it tomorrow so it better be clear enough that someone(me) will be
able to figure it out without to much trouble.

Relentless simplicity, if making your software a little simpler to use means
that its 1 million users have to remember 1 less thing because you have
remembered 1 more thing then you have just saved 999,999 brain cells.

Relentless reliability is rather similar to relentless simplicity it should
work the same way every time all the time. Any time you break the guaranty of
getting it done right you just cost a lot of thought and effort for a large
number of people.

------
lawn
I wouldn't really think too much into it. I've had the "not good enough"
feeling for years, in fact, ever since I started programming!

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.

------
mnemonicsloth
If it solves the business problem your clients are paying you to help them
with, your code is definitely good enough.

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.

~~~
pyre
"Do whatever it takes to solve the business problem now and we'll worry about
the other stuff later" is what produces horribly complex code bases because
"later" never comes and management will never justify the time to fix things.

This presents you with a number of problems:

* It makes it harder to pivot in the future. You may end up having to rewrite a lot in order to extend the original model.

* In most cases, this means no tests.

* Maintenance costs significantly more.

* When you hire new people to work on the code base, it will take a significant amount of time for them to come up to speed and be productive in the code base.

~~~
mnemonicsloth
I assumed OP was competent but not stellar, so my answer was about the
difference between average and good.

You're talking about _bad_. I agree that no competent programmer would do the
things you're describing if they could possibly help it. So we probably would
have given OP the same advice if we had started with the same assumptions.

------
watmough
Yeah, I feel like that almost all the time.

You have to write a LOT of code before it flows perfectly from the fingertips.
That's the key, write lots of code and be aware how you can improve.

Here's a few points that have been useful to me:

1\. Write code to be used. If it's not useful, why are you bothering? If it's
useful, other people will use it and demand changes and complain about bugs.

2\. Great programmers code fast. Write code quickly and refactor whenever
necessary. Get miles under your wheels. Great racing drivers drive. Practice,
practice, practice. ABC - Always Be Coding.

3\. Practice refactoring. If you see a better way to do something, implement
it. Don't cry that you're scared to change it because it's 'working'. ALL your
code should work.

4\. Set small targets that you can accomplish in an hour of so of designing or
coding. Always have a pile of these ready to work on. Work on them when you
have an hour free. Code fast, test and commit.

5\. Use git. Commit at a fine granularity so you can see your enjoy your
progress.

6\. Always ask yourself "Is this code clear? Do I trust it?" when reading a
source file.

7\. Don't fight your tools. If you constantly edit auto-completed text, STOP
DOING that and fix it or disable it, or learn to write idiomatic code.

Thanks for the question, and I hope these are useful. It's fun for me to
crystallize some of this stuff!

------
geraldalewis
_> good code written by some one else_

Exactly -- _someone else_. I don't have a formal Computer Science education.
I'm juggling reading the K+R C book, Knuth's _Literate Programming_ ,
Odersky's _Programming Scala_ and the Ruby "pickaxe" book. All of them have
been great. But their impact on my code and career all pale in comparison to
the strides I've made by paying attention to the _social_ side of programming.

You should now:

* Talk to other programmers. I found a couple groups on Meetup.com that I like attending. Sometimes they're not specifically about programming (like my UX meetup). That's good. I am cross-training. I have asked some programmers whose work I admire for beer/coffee, on me, and I've had some great experiences. You will hear new ideas, and will have to defend your opinions.

* Find an open source project you like on Github.com and start contributing. Start with easy #bugs in "Issues". If you don't know which ones are easy, ask. You will get invaluable peer review, sometimes from the best minds in our field. You will read great code, and you will modify it, and so you will understand it deeply. You will have the satisfaction of knowing your code is used by hundreds or thousands of people.

* Find beauty in other things.

------
igorgue
Disclaimer: I have like 6 years of experience, I'm not a famous programmer,
but I do get people telling me (more than 20 programmers) that I'm a good
programmer and I write good code.

Read code, watch people coding, care about your tools, and finally, your code
will never be "good enough" you'll always improve.

Read code: Read open source software, from the libraries and frameworks you
use for example; That way you'll learn new techniques and ways to organize
your code so it's more readable. Also it helps reading books like Code
Complete and Beautiful Code. I recommend "Framework Design Guidelines:
Conventions, Idioms, and Patterns for Reusable .NET Libraries" even though I'm
not a .NET programmer I really like that book.

Watch other people coding: Get together with friends to pair program, or
online, most people like to pair program. Or watch some of the new Peepcode
videos on experts programming (<https://peepcode.com/screencasts>).

Care about your tools: Now that a lot of people are using dynamic languages I
see it over and over again, people just use whatever editor, debugger, etc
etc, care about those things, you'd rarely see myself making a "unused
variable" mistake, because I have all the linting tools, and I follow them,
same goes to code formatters, etc etc, I recommend VIM to edit code, Git as a
communication tool (which is version control), Chrome as debugger. Also try
the best way you can to reuse things, framework like Backbone, Batman,
Knockout helps a lot with your JavaScript, never use just raw jQuery, it's not
needed anymore.

You're never gonna be good enough, there's always gonna be a DHH, Jacob Kaplan
Moss, Jeremy Ashkenas (just to name a few) to look up to.

------
billrobertson42
Just tonight I had to work on a code base that I initially wrote about five
years ago. This is a working product that's been rock-solid for the client.
Still though, at one point, I really hated the code.

Nevertheless, I've been able to extend bits and bobs of it over the years
without major headache or breakage. And tonight I had to write a simple
related utility program. I was able to grab various classes out of the code
and just use them, or re-purpose them with little effort.

Are there issues with the code? Hell yes. I'm always learning as a programmer
and I'm much better now than I was then. Does that mean the code was crap? It
feels kind of hard to say this, but no it wasn't crap. It did the job and it
hasn't been a maintenance nightmare.

So when you look at code you wrote 6 years/months/weeks/days/hours/minutes ago
and think, that's total crap! Don't beat yourself up over it. It just means
that #1 you care and #2 you have learned something between then and now.

Oh, and after looking at the first line of nirvana's post, I thought about it
and realized I wrote my first bits of code about 30 years ago too.

------
yn
If you are programming in imperative languages, I think you can learn from
Dijkstra and Gries.

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

------
RyanMcGreal
After a little over ten years of daily full-time coding, I'm finally at the
point where I can go back to code I wrote three or six months ago and not
think, _WTF?_ I'm by no means a great programmer, certainly not compared to
some of the brilliant coders on HN, with whose work I'm constantly inspired
and humbled; but as Dirty Harry famously said, "A man's got to know his
limitations," and I think I'm pretty realistic in that regard.

To get better: keep noticing your mistakes and taking them into account on
subsequent activities; keep modifying your workflow to incorporate and
automate good practices and to remove the potential for preventable mistakes;
keep taking opportunities to clean and refactor old code when you have to face
it; keep reading other people's code (especially those brilliant coders
kicking around HN) and learning from it; and keep pushing yourself to get
better. Rinse and repeat for as long as you spend programming.

------
mst
I gave a lightning talk some time back on this topic called "You aren't good
enough" - video is here:

[http://www.shadowcat.co.uk/archive/conference-video/yapc-
eu-...](http://www.shadowcat.co.uk/archive/conference-video/yapc-eu-2008/you-
arent-good-enough)

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

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

------
cpeterso
I recommend settling down in your armchair by the fire with a good brandy ;)
and reading code written by the masters. The Plan 9 code has some very clean
code I'd love to hear others' recommended "classic" works..?

Conversely, ask other people to review your code. It's an opportunity to get
feedback on your code, discover bugs, and earn brownie points flattering your
reviewer. ;) You can read "The Humble Programmer" to prepare your ego for
constructive criticism.

Also, dabbling in other programming languages can give you new perspective
into your other work. Scheme and Haskell are good languages for waking up
dormant brain cells. (I'm working through the "Learn You A Haskell" tutorial
Noah

~~~
psykotic
> The Plan 9 code has some very clean code I'd love to hear others'
> recommended "classic" works..?

The lcc compiler. It's written as a literate program. Read A Retargetable C
Compiler by Hanson and Fraser.

~~~
watmough
The SQLite code has a stellar reputation.

<http://www.sqlite.org/download.html>

------
thedjpetersen
Programming is a skill that one constantly improves at. The first step seems
just to implement good practice into your code. Then it is learning a common
way to problem solve.

The most important thing, something that I learned from a comment on this
site(I can't find it at the moment), is to "just keep coding". Jump on an open
source project. Take something small, find another programmer which you
admire, and try to learn from their style.

Work with others. Pair programming is a great way to learn from someone else,
it lets two people pick each others brains.

Remember becoming a good programmer is a journey. It is not something that
achieved instantly.

------
usedtolurk
You're definitely not alone in feeling like this. "Good enough" always depends
on the circumstances, so the best way to know if your feelings are warranted
is to get honest code reviews from the people who will be working with your
code. Balance that with external reviews from programmers you look up to
(expecting some contradictions) - then take your own path.

Don't despair if you get a lot of negative feedback - it's easy to improve by
reading some of the books listed in this thread and repeat.

Enjoy the journey - I've yet to meet I've yet to meet someone who's reached
the destination (although plenty have stopped along the way).

------
DiabloD3
I'm probably going to get down-voted for this, but it doesn't really matter if
YOU think its good enough: it is a combination of "your competitor's code (ie,
everybody on the Internet, not just in the realm of your business model) ISN'T
good enough" and "does anyone else think its good enough".

Being highly self-critical of code is good, but don't let it stop you from
writing absolute crap. Several people (of which includes Bill Gates) have
sold/shipped absolute crap code and are now amazingly rich.

Whoever codes it wins, it usually doesn't end up who codes it better unless
the original has serious flaws that were not corrected.

------
lobo_tuerto
I recommend then you start taking tiny bits of software architecture to
improve your code and your understanding of code structure. It can help with
reuse, better practices, etc. For example get a copy of Ruby Design Patterns.

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.

------
impendia
Congratulations!

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.

------
noelwelsh
Thinking you aren't good enough is the first step to getting better. At the
risk of sounding cliched, it's the journey not the destination that's
important. You never arrive at perfection anyway, so I wouldn't worry!

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.

------
DanielRibeiro
Reusable code/efficient code is usually more complex and less readable. I find
this is usually not a big issue, as I can always refactor change to the design
I need later.

Just in time, not just in case.

~~~
hermannj314
I agree that efficient code is usually more complex and for some god forsaken
reason it tends to be the least commented.

If you think to yourself, "wow! I'm really proud of that, very clever" please
for the love of God leave a comment.

I find myself writing chicken scratch on a piece of paper or in a scrap file
when writing a function, many of those chicken scratch comments are exactly
the sort of things future developers would love to see in comments.

So...big takeaway from me (15+ years developing) is learning when to comment
your code!

------
fredleblanc
I felt like this with my code for the first 5 years that I was coding as well.
My code now isn't pristine or perfect, but I'm consistently satisfied with the
quality of my final products. Here's what I did to get to the point where I'm
happy with my code:

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. :)

~~~
matthavener
I really like your "clarity over cleverness" rule. It seems to incorporate so
many good practices: premature optimization, over-design/second system
syndrome, and doing the most obvious thing.

~~~
antfarm
cf. "2. Rule of Clarity" - Basics of the Unix Philosophy
<http://www.faqs.org/docs/artu/ch01s06.html>

1\. Rule of Modularity: Write simple parts connected by clean interfaces. 2\.
Rule of Clarity: Clarity is better than cleverness. 3\. Rule of Composition:
Design programs to be connected to other programs. 4\. Rule of Separation:
Separate policy from mechanism; separate interfaces from engines. 5\. Rule of
Simplicity: Design for simplicity; add complexity only where you must. 6\.
Rule of Parsimony: Write a big program only when it is clear by demonstration
that nothing else will do. 7\. Rule of Transparency: Design for visibility to
make inspection and debugging easier. 8\. Rule of Robustness: Robustness is
the child of transparency and simplicity. 9\. Rule of Representation: Fold
knowledge into data so program logic can be stupid and robust. 10\. Rule of
Least Surprise: In interface design, always do the least surprising thing.
11\. Rule of Silence: When a program has nothing surprising to say, it should
say nothing. 12\. Rule of Repair: When you must fail, fail noisily and as soon
as possible. 13\. Rule of Economy: Programmer time is expensive; conserve it
in preference to machine time. 14\. Rule of Generation: Avoid hand-hacking;
write programs to write programs when you can. 15\. Rule of Optimization:
Prototype before polishing. Get it working before you optimize it. 16\. Rule
of Diversity: Distrust all claims for “one true way”. 17\. Rule of
Extensibility: Design for the future, because it will be here sooner than you
think.

------
mtkd
If you're using it for a start-up - it's much more important to deliver usable
software than quality code - you can always go back and clean up the code -
but if you don't get traction it's all over.

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

~~~
fatalerrorx3
I'm currently working on a startup and like the OP I was questioning how good
of a programmer I am. I'm self taught and have been programming since I was in
middle school computer club more than 8 years ago.

Working on this startup project has taught me that in the beginning it's all
about delivering a product that works that users want. When requirements are
constantly in flux and you're working hard and fast to develop a fully
functional prototype there's little time for code refactoring to make it
"perfect" because the longer it takes to launch the larger the possibility
that someone beats you to it. As long as the code does what it's supposed to
do and is not loaded with bugs and isn't terribly slow I say to just go with
it.

Requirements are always changing in startup land and a good programmer adapts
to make those changes and is focused on producing a workable prototype before
their competition does

------
jaekwon
there's an art to writing readable and reusable code, but you have to start by
understanding the problem.

when you really understand the problem, the problem and surrounding use-cases
become obvious. when this happens, writing readable code becomes trivial, as
long as you understand what tools you need to use to solve it.

sometimes the right tool is a library, sometimes it's adapting existing code,
and sometimes it's a special language construct like Python metaclasses.

whatever your problem, try to describe it and the solution in english at a
high level. then, how can you best fit your solution into the mental framework
that you just created?

as for reusable code, just be aware of leaky abstractions and complexity.
often times i see libraries that introduce more complexity into a program than
needed, sometimes because the solution doesn't really fit into a module. often
times the solution is another language, like jQuery or Haml.

anyways.

------
otaku_coder
I think that nearly all good developers feel their code isn't "good enough",
so its nothing to worry about! This search for perfection will drive you to
constantly improve and practice, which can only be a good thing!

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

------
yason
If your code begins to look good and other people's code begins to look bad,
you know you're not in the right company.

------
TomGullen
If someone is paying you to do it then by definition it is good enough in my
opinion. The idea of perfect code is very abstract and impossible to ever
reach. Coding is a journey and about incremental improvements I think, always
try and learn something every time you sit down or you will fall behind the
pack!

------
eneveu
I am passionate about writing good code, and I'll try to offer some practical
advice. As others said, the first step is understanding the importance of
writing clean code and taking pride in your craft. By doing this, you are
already ahead of most other programmers who don't really care. Now, how do you
improve?

1) Read books.

With 4-5 years of experience, you already have a good intuition for "good" and
"bad" code. Still, it doesn't hurt to learn more about it. There are a lot of
good books on this subject.

The first is "Clean Code", by Robert C. Martin. It's the first book I read on
this subject, and I learned a lot. Note that the book uses Java in the
examples, but I think the ideas would apply to most other languages.

Its author, Uncle Bob ( <http://en.wikipedia.org/wiki/Robert_Cecil_Martin> )
has long been a proponent of writing clean, beautiful code. He recently did an
interview for Xebia: [http://blog.xebia.fr/2011/05/25/interview-avec-robert-
martin...](http://blog.xebia.fr/2011/05/25/interview-avec-robert-martin/)
(French blog, but the interview is in English). In it, he advises:

 _"Well there are a number of books that talk about writing code well. Kent
Beck wrote a book called “Implementation Patterns” very recently. It’s an
excellent book all about software craftsmanship. The pragmatic programmers
wrote a wonderful book in 2000 called “The pragmatic programmer”, again a
wonderful book. Chad Fowler wrote a book call the “Passionate Programmer”.
Again the book is about doing everything well. I wrote a book recently called
“Clean Code” which is very specific about particular things you can do with
your code to do it well. So there is a tremendous number of resources that are
available for people who are interested in doing software craftsmanship
well."_

Out of those, disregard "The passionate Programmer". It's an okay book, but
its focus is on building a good programmer career, not on code.

"Implementation Patterns" by Kent Beck is a great book with a lot of best
practices when writing * Java * code. Less useful if you use another language.

"The pragmatic programmer" is a good book on software craftsmanship. I'm
personally half-way through. There is a lot of good advice in it, but I often
find myself thinking it's "common-sense". Maybe because I've already been
exposed to most of the ideas by reading blogs? Still, it's a great book, with
a lot of best practices. It's main focus is not code, though, so you might
want to start with other books if your focus is on writing good code.

To these books, I'd add "Code Complete (2nd Edition)" (language-agnostic) and
"Effective Java 2nd Edition" if you use Java.

Summary:

If you use Java, read:

    
    
      - Clean Code - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
      - Effective Java 2nd Edition - http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683
      - Implementation Patterns - http://www.amazon.com/Implementation-Patterns-Kent-Beck/dp/0321413091
      - Code Complete / Pragmatic Programmer
    

If you use another language, read:

    
    
      - Clean Code - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
      - Code Complete - http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
      - Pragmatic Programmer - http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X
    

Other people might chime in with suggestions for other languages?

2) Practice.

Implement what you learned in the books. Keep improving.

3) Read other people's code.

Read _good_ open source code. Not all code is good code. Ask around for OSS
projects with good code in your language.

If you use Java, start with:

    
    
      - Google Guava - http://code.google.com/p/guava-libraries/
      - Google Guice - http://code.google.com/p/google-guice/
      - Spring Framework - http://www.springsource.org/
    

4) Practice.

5) Practice.

~~~
mabid
Thank you so much for the comprehensive reply. You are right when you say that
with 4-5 years of experience I know to some extent what good and bad code is.
but sometimes I think a lot and write the best code that i can, and later
after some time i realize; by looking at some one else's code or by myself
knowing a new feature of the language i am using, that i could have done it in
a much better way .. that is much more beautiful. My problem is that if my
code doesnt look like poetry to me, clean readable understandable i feel the
need to improve it.

------
benologist
My code's crap and I feel sorry for the people I'm going to hire to take over
it - and a little bit embarrassed - they will probably be better programmers
than me and I will probably learn how to write less crap code from them.

But oh well. Shit happens, and my code got me this far.

------
erikb
Is a good programmer one who creates good code or one who is always looking to
improve his code, experiment and get his programs to work?

Look with pride at the mistakes of your past and be ready to do more mistakes
to improve in every line you write. That's my philosophy for now.

------
chrismealy
4-5 years isn't that long really. I've been at it 20 years or so and there's
never been a time when I wasn't slightly embarrassed by what I was doing just
the year before. Programming is fun that way, you're always getting better.

------
leif
never be afraid of refactoring, but only do it when you're changing a piece of
code anyway (otherwise you'll drive yourself nuts)

get others to review your code whenever possible. for that matter, do code
reviews yourself whenever possible, it'll make you better at writing code too

always write it the simplest way you can, especially the first time. code
that's clever for the sake of cleverness is bad code. learn about compiler
optimizations, there are plenty of things compilers will do to make it so you
can write clear code that is still fast, and there are plenty of clever things
you can do that won't make an iota of difference in the end.

------
manishtomar
This proves that you are learning and there is still much to learn. I've been
programming for 6 years and I feel it all the time. I think the only way to
feel better is to keep writing better code by keep reading better code.

------
bajsejohannes
Ira Glass talks about this: <http://www.youtube.com/watch?v=BI23U7U2aUY>

His recommendation boils down to keeping doing it until you code matches your
expectations.

------
danbmil99
It's pretty natural to be disgusted by one's own code, except in very rare
circumstances. Typically you like it when you've just written it (but before
it's been transformed into garbage by real-world needs).

------
polemic
The only code that I've ever been happy with was module code I open sourced.
It took a lot of time, use and feedback to get there. Hard to argue that it
was really worth the time, except for my own pride.

------
michaelbuckbee
I think this more a life issue than a code one. In some ways if you're not
looking at what you did a couple years ago and thinking "Wow, I would do that
so much better now" then you aren't progressing.

------
sleight42
\- Read open source code of people whose code you respect \- Pair with those
people.

Remote pairing is pretty easy these days with SSH, tmux, and VOIP.

------
wccrawford
If you think that, you're probably right. Figure out why, copy it. Over and
over and over.

That's how you improve at every craft.

------
BasDirks
I hope for you that you'll never think your code is good enough. Keep growing.

------
alcuadrado
Start by reading Code Complete!

    
    
                a cleancode frantic

------
hsmyers
Refactoring your code or yourself is not a terminal process.

------
indi
my code is not good enough, when i need to make change, and i find it
difficult. and this is when i need to refactor.

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

~~~
aangjie
+1 for the having to maintain your own code. I remember looking back at my own
code and swearing "what the *$$# was i thinking.."

~~~
crdoconnor
I know what I was thinking most of the time: I want to get this thing working
and out there as quickly as possible.

Deadlines are probably the root cause of most of the world's most horrific
hacks.

Also, I've never once had a boss turn to me and say "you know what, forget
about writing any new features for now - just refactor the code that is
working just fine but looks horrible."

~~~
cookiecaper
>Deadlines are probably the root cause of most of the world's most horrific
hacks.

I definitely agree with this. I've written some absolutely terrible code in
marathon sessions with an impending deadline -- in the worst case, I copy-
pasted code in six or seven locations for something that could have and
definitely should have been factored out into a function. I just didn't have
any time to spare, I had to finish it for a demo in X hours. That whole
project was a mess.

------
nirvana
I know my code isn't good enough, and I've been programming for about 30
years! Not only that, my code isn't good enough, but I'm a great programmer.

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 startup, not pretty code, though the latter can help the
former.

Worse is when you worry too much about not being good enough and really end up
not being good enough.

~~~
keithpeter
"The unskilled therefore suffer from illusory superiority, rating their
ability as above average, much higher than it actually is, while the highly
skilled underrate their own abilities, suffering from illusory inferiority."

Dunning-Kruger effect, and it is the same in most professions where
'performance' can be a subjective judgement. Teaching, definitely!

<http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect>

~~~
sp332
And Impostor Syndrome <http://en.wikipedia.org/wiki/Impostor_syndrome>

------
bluedanieru
I think if you're shipping and it works, and you find you can revisit it in a
few months without being completely lost, you're in pretty good shape.

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 :-)

