9 ms·

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

140 points by mabid 15y ago

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 15y ago
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 15y ago
  > 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.
shawnz 15y ago
Here's Jeff Atwood's take on it: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html http://www.codinghorror.com/blog/2009/07/nobody-hates-softwa... "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 15y ago
  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 15y ago
    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 15y ago
      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.
kgtm 15y ago
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 15y ago
  //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).
icey 15y ago
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/ http://codereview.stackexchange.com/
unoti 15y ago
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/ 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 15y ago
  Do you have a link to _why's philosophy on coding and making mistakes? A quick Google search did not yield anything. Thanks.
  - losvedir 15y ago
    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 http://aberant.tumblr.com/post/167375099/a-letter-from-why
hsmyers 15y ago
Refactoring your code or yourself is not a terminal process.
lawn 15y ago
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.
noelwelsh 15y ago
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.
michaelbuckbee 15y ago
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.
impendia 15y ago
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.
fredleblanc 15y ago
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. :)
awwx 15y ago
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 15y ago
  Someone downvoted this? This seems like good advice to me...
BasDirks 15y ago
I hope for you that you'll never think your code is good enough. Keep growing.
DanielRibeiro 15y ago
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 15y ago
  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!
lobo_tuerto 15y ago
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.
mnemonicsloth 15y ago
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 15y ago
  "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 15y ago
    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.
joshcrews 15y ago
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
TomGullen 15y ago
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!
mtkd 15y ago
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 15y ago
  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
- saiko-chriskun 15y ago
  +1 on the mentorship note. _Incredibly_ useful. Not only for yourself but can also be a great exercise for the teacher. http://pith.org/notes/2011/08/29/programmers-feeling-uninspired-try-teaching http://pith.org/notes/2011/08/29/programmers-feeling-uninspi...
nirvana 15y ago
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.
mst 15y ago
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-2008/you-arent-good-enough 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.
otaku_coder 15y ago
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.
bluedanieru 15y ago
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 :-)
georgieporgie 15y 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.
- aangjie 15y ago
  +1 for the having to maintain your own code. I remember looking back at my own code and swearing "what the *$$# was i thinking.."
  - prodigal_erik 15y ago
    This is what my boss looks for on résumés. Not loyalty so much as whether you've worked anywhere long enough to have to clean up and rearchitect after your own mistakes, rather than leave an ever-growing trail of (presumably) smoking craters.
  - crdoconnor 15y ago
    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."
    - 15y ago
yn 15y ago
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.
steve8918 15y 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.
- binarycheese 15y ago
  Extremely well put. Took me alot of humility to get to get to this conclusion.
- erikb 15y ago
  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.
typicalrunt 15y ago
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.
danbmil99 15y ago
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).
cpeterso 15y ago
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 15y ago
  > 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 15y ago
    The SQLite code has a stellar reputation. http://www.sqlite.org/download.html http://www.sqlite.org/download.html
leif 15y ago
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.
watmough 15y ago
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!
indi 15y ago
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.
deleted 15y ago
[deleted]
benologist 15y ago
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.
thedjpetersen 15y ago
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.
yason 15y ago
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.
javadyan 15y ago
I have this little rule: if you look at some nontrivial piece of code you wrote months ago and feel like it's good, then something is wrong. It means that you learned nothing in these months and can't see how your previous approach could be improved.
DiabloD3 15y ago
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.
RyanMcGreal 15y ago
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.
igorgue 15y ago
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 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.
jaekwon 15y ago
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.
sleight42 15y ago
- 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.
- deleted 15y ago
  [deleted]
stonemetal 15y ago
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.
erikb 15y ago
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.
bajsejohannes 15y ago
Ira Glass talks about this: http://www.youtube.com/watch?v=BI23U7U2aUY http://www.youtube.com/watch?v=BI23U7U2aUY His recommendation boils down to keeping doing it until you code matches your expectations.
geraldalewis 15y ago
> 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.
eneveu 15y ago
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 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.
chrismealy 15y ago
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.
alcuadrado 15y ago
Start by reading Code Complete! a cleancode frantic
polemic 15y ago
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.
manishtomar 15y ago
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.
usedtolurk 15y ago
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).
billrobertson42 15y ago
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.
wccrawford 15y ago
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.
losethos 15y ago
gay
josephg 15y ago
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.

140 points by mabid 15y ago

nuclearsandwich 15y ago

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 15y ago
> 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.

shawnz 15y ago

Here's Jeff Atwood's take on it: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html http://www.codinghorror.com/blog/2009/07/nobody-hates-softwa... "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 15y ago
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 15y ago
  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 15y ago
    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.

kgtm 15y ago

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 15y ago
//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).

icey 15y ago

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/ http://codereview.stackexchange.com/

unoti 15y ago

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/ 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 15y ago
Do you have a link to _why's philosophy on coding and making mistakes? A quick Google search did not yield anything. Thanks.
- losvedir 15y ago
  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 http://aberant.tumblr.com/post/167375099/a-letter-from-why

hsmyers 15y ago

Refactoring your code or yourself is not a terminal process.

lawn 15y ago

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.

noelwelsh 15y ago

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.

michaelbuckbee 15y ago

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.

impendia 15y ago

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.

fredleblanc 15y ago

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

awwx 15y ago

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 15y ago
Someone downvoted this? This seems like good advice to me...

BasDirks 15y ago

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

DanielRibeiro 15y ago

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 15y ago
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!

lobo_tuerto 15y ago

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.

mnemonicsloth 15y ago

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 15y ago
"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 15y ago
  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.

joshcrews 15y ago

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

TomGullen 15y ago

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!

mtkd 15y ago

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 15y ago
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
saiko-chriskun 15y ago
+1 on the mentorship note. _Incredibly_ useful. Not only for yourself but can also be a great exercise for the teacher. http://pith.org/notes/2011/08/29/programmers-feeling-uninspired-try-teaching http://pith.org/notes/2011/08/29/programmers-feeling-uninspi...

nirvana 15y ago

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.

mst 15y ago

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-2008/you-arent-good-enough 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.

otaku_coder 15y ago

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.

bluedanieru 15y ago

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

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

aangjie 15y ago
+1 for the having to maintain your own code. I remember looking back at my own code and swearing "what the *$$# was i thinking.."
- prodigal_erik 15y ago
  This is what my boss looks for on résumés. Not loyalty so much as whether you've worked anywhere long enough to have to clean up and rearchitect after your own mistakes, rather than leave an ever-growing trail of (presumably) smoking craters.
- crdoconnor 15y ago
  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."
  - 15y ago

yn 15y ago

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.

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

binarycheese 15y ago
Extremely well put. Took me alot of humility to get to get to this conclusion.
erikb 15y ago
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.

typicalrunt 15y ago

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.

danbmil99 15y ago

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

cpeterso 15y ago

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 15y ago
> 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 15y ago
  The SQLite code has a stellar reputation. http://www.sqlite.org/download.html http://www.sqlite.org/download.html

leif 15y ago

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.

watmough 15y ago

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!

indi 15y ago

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.

deleted 15y ago

[deleted]

benologist 15y ago

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.

thedjpetersen 15y ago

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.

yason 15y ago

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.

javadyan 15y ago

I have this little rule: if you look at some nontrivial piece of code you wrote months ago and feel like it's good, then something is wrong. It means that you learned nothing in these months and can't see how your previous approach could be improved.

DiabloD3 15y ago

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.

RyanMcGreal 15y ago

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.

igorgue 15y ago

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

jaekwon 15y ago

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.

sleight42 15y ago

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

deleted 15y ago
[deleted]

stonemetal 15y ago

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.

erikb 15y ago

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.

bajsejohannes 15y ago

Ira Glass talks about this: http://www.youtube.com/watch?v=BI23U7U2aUY http://www.youtube.com/watch?v=BI23U7U2aUY His recommendation boils down to keeping doing it until you code matches your expectations.

geraldalewis 15y ago

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

eneveu 15y ago

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

chrismealy 15y ago

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.

alcuadrado 15y ago

Start by reading Code Complete! a cleancode frantic

polemic 15y ago

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.

manishtomar 15y ago

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.

usedtolurk 15y ago

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

billrobertson42 15y ago

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.

wccrawford 15y ago

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.

losethos 15y ago

gay

josephg 15y ago

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.