15 ms·

Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel. Let's get a little more specific... Most code sucks because the

• michael_dorfman 15y ago
  All of those are absolutely true, and many of them reduce to one thing - didn't have a frickin' clue what the code was supposed to do I remember reading the old cartoon (and it was already old when I saw it 25 years ago) of the manager saying "You guys start writing code, I'll go find out what they want", and swearing I would never be that kind of manager only to find, all those years later, that many of my programmers had already internalized the notion and routinely sat down to write code without having a clear idea of what the block of code was supposed to accomplish.
  • jodrellblank 15y ago
    You say that on a site where the ethos is "start building a company and product now, we'll figure out what it should do later" - because that's a way that works.
    • michael_dorfman 15y ago
      I think the ethos here is clearly different than you suggest. Trying to build a product without having an idea what it should do is not a way that works. Being open to refining your idea or pivoting as you go is a horse of a different color. But trying to write code without a clear purpose in mind is the equivalent of monkeys banging away at typewriters, to return to our "writing" metaphor.
    • pkandathil 15y ago
      37 Signals in their book rework put it really well. You have a business model from day 1. Not everyone is Facebook and Twitter so having a concept of a business model is very important. So yes, having a clear vision of your product is necessary. That vision can change while you are building but you still need to have a starting point.
• dustingetz 15y ago
  meh. i work at a small shop. most of the code i see that sucks was written by competent programmers under high schedule pressure. the code is clearly not well understood anymore, but if you trace the history you can see it's due to a few years of tacking on features as quickly as possible. the technical debt surely slows us down sometimes, but hey that was a business decision, maybe even a correct one! core business functionality is rock solid, its mostly UI code that sucks. I wonder what the average startup codebase looks like?
  • david927 15y ago
    I get tired of the "blame the shitty programmers" line of thought. We're all shitty programmers. Yet we all "understand variable scope" and "what the code was supposed to do." Some of us have such a large ego that we think it's others. No, Sancho. It's you. Code gets complex as hell very quickly. If it was building a house, it would be built in a week and architected on the fly. The person mixing the concrete, who has to know the concrete grade and drying time, also has to know that the upstairs has just shifted and now the load is too much on the center beam. The reality is that, unless your dealing with tiny apps, that "bad programmer"? It's you.
    • true_religion 15y ago
      I've seen applications with fairly large scope that have clean code. For the most part the Django codebase has clean code, and its rapidly understandable. Where that's not true is the original SQL db, and the Forms library. Elsewhere its a dream to hack with. I'd also praise the codebase of SQLite, and Lighttpd---these two are very clean.
      • dustingetz 15y ago
        good low level backend stuff takes years of iteration under static business requirements. its also a well-understood domain with many prior implementations to learn from, and the 'companies' tend to be product-based so you have much less customer pressure. teams reacting to changing or poorly-understood requirements (think enterprise and defense software contracts) have a much harder task. nobody has solved the problem before, nobody understands the problem, and project managagement is typically forced into waterfall in order to make sales, so its not like there's time to redo things that get duct-taped together, if the duct-tape holds.
• dspeyer 15y ago
  The worst code I've seen is from programmers who had no mental model of what they were doing, just changed things at random until tests passed. The worst writing I've seen: * is ungrammatical to the point of incoherency * loses its train of thought mid-sentence and talks about something unrelated * is full of irrelevant details * simply ignores everything above the sentence level, producing mere text, no argument, story or whatever it was supposed to be Not really the same failure modes.
  • michael_dorfman 15y ago
    Not really the same failure modes. Really? Because except for the first one (which we have compilers to thank for), your three remaining points apply equally well to a lot of code I've seen.
    • lurker14 15y ago
      Even if you are working in a compiled language, you still can't always rely on the compiler. The compiler will not stop a programmer from writing invalid code, without any tests, and checking it into a repository, where it silently waits for an unsuspecting programmer to discover it months later.... "How do I do what I want here? Aha, someone already wrote ExactlyWhatIWantHere.... WTF, it doesn't even compile? But how is anyone using it? Oh, it's not being used anywhere? How the heck did it get here? Ugh..."
    • yxhuvud 15y ago
      The first point applies as well, to when his counterexample has happened. Who has not seen a piece of code that is so bad they don't even understand how it can compile, coming out of a newbie? Doing strange undefined things in C comes to mind as a usual case where this happens.
• SMrF 15y ago
  I think you can check off everything on this list and still write inscrutable code. The worst code I've seen is code that was written so that only one person understands what's happening -- the author. Typically the code has too many branches and ridiculous call stacks. The writing analog is a run-on sentence. This usually happens when the programmer at fault is really smart but still hasn't learned that at some point in the future, someone needs to come along and understand the code he/she wrote. Maybe we need editors?
  • murkt 15y ago
    What you think code reviewing is for?
    • pkandathil 15y ago
      Totally agree that more code reviews are needed. I guess then the question becomes, how do you teach someone to do a good code review. Code reviews come from experience I get it, so if you are a junior programmer then you get your code reviewed by someone senior. But there is also one very important part to a code review. It being able to give good advice to someone. Not to be over critical but to provide help that is actually going to build someone up. At a company I use to work at, they did this beautifully. 1) Every check in required a code review by a peer. In your commit statement, you specify who reviewed your code. 2) If a senior programmer wrote code for a feature that wasn't too complex he would get a code review from a junior programmer. The junior programmer doing the code review, learned what good code looks likes and second learned how to give feedback in a constructive manner as he was talking to someone with more experience than him/her.
    • gruseom 15y ago
      No, traditional code reviewing is just spot checking. That is analogous to having an editor only look at a few passages of a novel. An editor needs to work with the whole text. This is the trouble with formal code reviews. Pair programming attempts to solve this by making all code get reviewed as it gets written. Like it or hate it, that at least tries to solve the core problem.
• pnathan 15y ago
  The only tickybox that matters is the last one: if that is ticked, there's no hope for it but to put up Dilbert around your work space and sing sad songs while you work.
• rimantas 15y ago
  I think that the point of original post is precisely that many do know and understand all the things you listed, but for some reason fail to apply them on the job.