To write good code, you sometimes have to write bad code

And I’m not referring to learning.

For example, yesterday I was trying to write code for something and it ended up beng harder than I expected. It’s one of those rare cases where you can fully imagine how the solution should work, enough to tell it to another person, but you can’t put your thoughts to code and you feel you’re not smart enough.

I find that in those cases, it helps a lot to open a new editor window and try to write code that just works. Without being elegant, fast or maintainable. Just something that works properly. And after you manage to put your thoughts into (bad) code, it’s easy to refine it from there and end up with good code.

Just don’t stop at the bad code, like many beginners do. It’s like when designers sketch a rough draft for a logo, before drawing the digital version. Could you imagine how horrible it would be if they wanted to stop there and give the rough sketches to the client instead? 🙂

  • Hm, 
    writing code  may mess you up lots of time. Since you can fully imagine how the code works means that you can write this stuff.
    I prefer making a step to step plan in order to organize my thoughts 

  • I use the same approach a lot, especially when writing long and complex functions.

    Instead of trying to figure out the best way to do stuff it’s often easier just to get the thoughts into code (any kind, good or bad) and make it work. Then you can go back and go over the code a couple of times ironing out the bad and slow parts.

  • Anonymous

    It’s a combination of Occam’s razor with some smoothing on the rough edges. Occam’s razor claims that sometimes you have to start with the simplest of solutions and add complexity until you’re satisfied. Your approach is “start with something that you know it works then tweak it until you’re satisfied”.

  • That’s basically my approach to writing blog posts, magazine articles, JS scripts, even my book; first put down what I want to say, then make multiple revisions until I find the way I want to say it.

    In fact it’s the way that the scientific method works: performance, feedback, revision.

    • Well said! I also apply it in writing natural language as well! 

  • Gonçalo Morais

    That is THE principle for every work/project/goal, whether artistic or something else. It put it to work everyday, and it helped a lot in my dissertation (18 out of 20 :D). Good post.

  • Pingback: Link-urile săptămânii 15-21 August « Staicu Ionuţ-Bogdan()

  • Eric Wendelin

    The more I code, the more I realize that all my code is bad code in one way or another. The more important thing is to have tests around it so that it’s easy to fix.

  • Kar Hoo Yiu

    Totally agree with you.

    A good developer should just be able to perform “continuous code refactoring/review” …

  • Pingback: To Write Good Code Start With Bad Code | Rachel Baker()

  • I think my main problem is exactly that. As a beginner I stop where you continue.
    Maybe i should try getting the bad code before 🙂

  • Fully agree with you!  I too, often write a mambo-jumbo code that just executes and do all the refactoring (to make it a “good code”) afterwards!

  • The concept of draft is very important. It may take you more time but the end result would be better than others.

  • Jinjiang

    I agree. And even, the “bad” code could help you improve the good one “better”!

  • Daniel Rodríguez Millan

    First: do it.
    Second: do it right
    Third: do it fast

    and thats all.

    • Anonymous

      Seems like a lot of managers reverse the priority and forget about your first item. I’ve been following this post’s advice for years.

    • sdsds

      You’ve obviously looked at addy osmani’s site

  • Wojtow

    The trick is to figure out when you should and shouldn’t spend lots of time refining it.    Some would say you always should… and I’ve fallen into that trap.  You need to evaluate whether or not this is a one-off  short term utility to get something specific done, or whether the code will be around for a while.    If you spend too much time refining on the one-off utility, nobody else will appreciate that it is elegant and your boss will only be unhappy at how long it takes you to get it done.   Otherwise, you should refine it.

  • As Hemmingway famously put it, “The first draft of anything is sh&t.”

  • Muzikayise Bullet Smiley Buthe

    hmmm great post.

    my technique similar but a bit different, this is what i do:
     – visualise the functionality, 
     – then visualise the functionality flow  
     – then i pseudo code everything, i do this on some scrape paper.
     – then once I’ve got all my thoughts and visions on paper, along with the pseudo code, i write the actual code

    I need to see where I’m going and therefore by putting down the vision on paper this makes the coding side so much easier.

  • Anonymous

    To quote a phrase in Army of Darkness “Good, Bad, I am the guy with the gun”. As an old developer I have found that what happens at least with me is the client/boss wants it NOW or even Yesterday and the client/boss always has the gun. Bad code always seems to come back to bite you in the butt at some future time yet try to convince the guy with the gun you need to take 2+ weeks to develop this whatchamacallit and do it right. No, it is always just do it and do it now make it work and we can update it later, by the time later comes you are already writing the next batch of bad code. I just do my best to write it right the first time if possible, yet it is not always possible and I have found if I can’t produce it in the allotted time, somebody out there will, or say they can. (In today’s economy and more IT jobs being sub-contracted overseas I can’t chance loosing my job.)  I have found that at for me, use a lot of comments in the source to explain why or what this does, because I will not remember why I did this a year or even three months from now.

  • SeattleC++

    I used to think that. I had coders block. I wasn’t experienced enough to write good code all the time. Don’t worry, if you stay at your profession a few years longer, and keep trying to learn, you’ll get over it.

    • This article sums up perfectly what I was going to reply to you: http://davybrion.com/blog/2009/01/we-all-write-bad-code/

      In particular the quote:  

      Any developer who claims he never writes bad code is either lying, ignorant or living in a fantasy world.

      It’s good that your skills have improved, but if you think you now only write good code, then your definition of good code is probably too relaxed.

      PS: I’ve been writing code for 13 years, so I think it’s safe to assume that my opinion on this won’t change much.
      PS2: I‘m so glad I’m not coding C++ any more. Not because the language is bad (quite the contrary), but because of all these dudes that try to prove they’re better programmers than everyone else, all the time. Ugh.

  • asdf

    suele pasar seguido cuando se brinca el paso de la algoritmia (ó pseudocódigo)

  • I agree with you. I call this dirty work as prototype code. I just then add the “refined version” after I know it works correctly.  I usually do this when I am unsure (or experimenting) on the code I have in mind.

  • J Williams

    There are some important tricks to this technique:
    1) Get your company to commit to never releasing the prototype code. It’s too easy for a manager to decide that the prototype “works, so doesn’t need rewriting”, and this can be a massive problem down the road.
    2) Don’t build other code on top of your prototype. Rewrite it as good code first or you’ll be stuck with it.
    3) Be prepared to rewrite the code from scratch. The prototye is an exploration of the problem space and often will show you how to design the whole thing much better – refactoring can take much longer and result in a much lower quality result than just writing clean new code to a good design.
    4) Don’t just look for how you can “improve” your prototype. Look at what you can *remove* from it, and how you can simplify it.
    5) Prototypes don’t need to be complete implementations. All you really need to do is explore the problem, solve the major issues, and confirm that end performance will be acceptable. Then you can crack on with the final code knowing that you’ve eliminated all the risks.
    6) All your previous experience is a prototype. Don’t write bad code when you already know how to solve the problem well.

  • BillLachenal

    “It’s one of those (rare) cases where you can fully imagine how the solution should work, enough to tell it to another person, but you can’t put your thoughts to code”
    … You are now beng groomed for a senior management position 🙂 …

    “Working” is good, but then someone wants to change the spec a tad, and they add an interfacing layer for fear of compromising compatibility, or some-such. Then another quick layer to “fix” something else, and before you know it you have the classic IB Manure-heap coding structure   ;v(
    Nothing like a quick-and-dirty fix, of course. I once had a boss who would always code latent errors into production work, so he could fix it later and play the hero. I was always puzzled why saving the day that way looked so good.However, back to topic, just diving into a complex linear writing spree tends to presage disaster; I always used to dissuade people from that, but then I’m from an era of over-night processing, and the unfamiliar disciplines for efficient development which that instills must be just as relevant today. There are those who just want to turn round code just for the buzz, in the hope that it’ll all hang together somehow. It’s a bit like roulette. I reckon they’ll just get dizzy.(Back in the day…) I used to prefer the tree-growing style of things.An ounce of design, then begin with a coded sketch that says the same thing: I’ll   start_here,   then  fill_in_this_stuff_Later,   and   I’ve_started_so_I’ll_finish. Each   f_i_t_s_Later    turns out to be:     … this_easy_bit …  easy_stuff_to_do_later_somewhere_else …           … digress_and_write_this_right_now …                 … clearly_horrendous_ojective_to_fill_in_Later  …  another_easy_call …Meanwhile, any data-structure grows alongside, organically, in a similar fashion (or vice-versa, depending on orientation).The code grows, branch-by-branch until it flowers..But my fave thing was pre-emptively to conditional-code simple diagnostics as I went, to massacre the test schedule. That saves SO much wasted de-foobah time.This approach once allowed me to completely (and successfully) re-write someone’s two/three-month  spaghetti-crash-heap in a Saturday afternoon, and perform other sundry miracles like changing Everything over night.  

  • Peter

    I love you

  • Pingback: Всем сотрудникам отдела! «()

  • This is why I love writing from scratch although some claim (http://www.joelonsoftware.com/articles/fog0000000069.html ) that it is the thing you should never do.

  • Owz

    Had this this very thought last night when coding a new FB integrated site. It wasn’t pretty to start with.. but got it working, then went back and refactored..

    I think as you get better at the language in question you will have less and less of this, but like an author, its always good just to get something down on paper and work with it…

    Good article :d

    • I don’t think it has to do with the language in question at all. I only use this approach when I can’t think of a good *algorithm* straight away. Sometimes I even use pseudo-code for the first draft or a mix of pseudo-code and JS.

  • Pingback: IOshared - 为了写出好程序,有时候你需要先写出烂程序()

  • Pingback: 【外刊IT评论网】为了写出好程序,有时候你需要先写出烂程序 | IOshared()

  • Pingback: 【外刊IT评论网】为了写出好程序,有时候你需要先写出烂程序 — 见贤思齐()

  • Pingback: satta matka()

  • Pingback: clemsondeckbuilders.com/()

  • Pingback: Daftar Agen Bola Terpercaya()

  • Pingback: http://www.tradeonixbonuses.com/()

  • Pingback: buy oral and injectable steroids for sale online()

  • Pingback: Live streaming video()

  • Pingback: tumblr blog()

  • Pingback: Life Insurance()

  • Pingback: http://blogspot.com()

  • Pingback: sattamatka()

  • Pingback: metrology services()

  • Pingback: https://tribot.org/forums/topic/26339-damraurooftopagility-draynor-varrock-falador-thru-ardy-currently/()

  • Pingback: handmade sofa essex()

  • Pingback: provimed balkan()

  • Pingback: correct golf swing plane()

  • Pingback: BBQ()

  • Pingback: more info()