6 ms·

Great code, like great literature, should entertain, challenge and make you question your preconceptions and yourself.

imiric 9y ago
Oh, the code I'm working with certainly does all that, but I wouldn't qualify it as good. :) I jest, but I agree with your statement.
NicoJuicy 9y ago
Great code is understandable for all. So it's not the code from insert developers name here
- TeMPOraL 9y ago
  No, it isn't. Programming is specialized work (I'd call it a discipline, but then we'd have to argue whether it's more an engineering discipline or art discipline). You have to gain knowledge and experience to understand it. A bridge blueprint is not understandable for all. It is understandable for all who took time and effort to gain education necessary to understand it. (The motivation between this comment is to counter the increasingly noticeable sentiment in our industry that everything needs to be dumbed down to the lowest common denominator; it's an understandable sentiment if you're selling something and want the biggest market, but it goes against what's needed to build great things.)
  - crdoconnor 9y ago
    >everything needs to be dumbed down to the lowest common denominator That kind of ought to be the default for most code. However, it's the natural tendency of code to become abstruse and unnecessarily complicated. Since market forces will often tend to exploit rather than reward the work done by programmers to "dumb their code down" and inadvertently reward "clever magic understood by a limited number of experts" there's more of an incentive to amplify this effect than to work against it - especially where money is involved. I'm a bit conflicted because on the one hand I don't want to help developer compensation get ground down by billionaires or other business owners with an entitlement complex who consider developers to be "spoiled brats", but I do prefer working with clean, straightforward code.
    - barrkel 9y ago
      There are times when you simply have hard problems. For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. You'd also like the code generation itself to be fast. That puts a limit on how much you can break it up into parts that can be understood individually and in isolation. Optimization works in opposition to abstraction because the optimal often requires steps that span multiple abstraction layers, and often requires multiple instances of the specific over few instances of the general. Personally, I think the two biggest reasons code becomes unnecessarily complicated these days are (a) testing and (b) local modifications. Unit testing in particular encourages over-parametrization so that dependencies can be replaced for the purposes of testing; while normal software maintenance under commercial pressure leads to local modification because nobody has time to understand the whole. People instead make conservative local changes by adding parameters, extra if-statements, local lookup maps, etc. I've found elegant solutions are often on the other side of a hill from over-engineering. You write specific solutions, then you climb the a hill of abstraction as you add layers, indirections, parameters etc., until you reach a summit, where you can see the whole, and can then start boiling things back down again, only retaining abstraction where it's actually necessary, or perhaps replacing multiple abstractions with a single more powerful abstraction (I've found this to happen a lot with monads; another one is converting control flow into data flow).
      - crdoconnor 9y ago
        >There are times when you simply have hard problems. > >For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. Yeah sometimes you do, and that is exactly the kind of problem that is irreducibly complex, but I think new kinds of problems like this don't tend to crop up in the wild very often and when they do they tend to show up in subtle and non-obvious ways. The problem you've described is far from a new problem - it's the same problem space that is covered by ORMs. Furthermore, if I were working on a team where a developer has uttered the words "I've created my own ORM" (or something to that effect), my face has probably already landed in my palms. The rest of what you wrote I'm in vigorous agreement with though- especially the parts about unit testing, local modifications and "the other side of the hill". Seen all of that.
  - fauigerzigerk 9y ago
    The thing is, people have been building bridges for thousands of years. What a bridge is and what it does changes very slowly. Almost all the specialised knowledge that bridge builders have is about _how_ to build a good bridge. Software is not like that. We may be experts in programming languages, algorithms and data structures, but the things we create and the problems we solve keep changing all the time. We're not usually experts in these problem domains and in some cases there are no such experts at all. So our code needs to be a lot more descriptive and written for readers that may not be very familiar with the problem at hand. We are more like lawyers supporting law makers or even like law makers themselves.
    - frostyel 9y ago
      no, more like Kings or Emperors WE'RE GODS!
    - falcolas 9y ago
      We think bridges are a very well explored domain. Then something like the Tacoma Narrows incident happens, and we realize how much of a fallacy that really is. Bridges are unique to their locations and their scale: what works over a creek will not work over a ravine. What works for a pedestrian will not work for a car. What works for a car will not work for a train. What works for a train will not work for a marching army.
      - fauigerzigerk 9y ago
        The Tacoma bridge collapse has a wikipedia entry exactly because bridge building is a very well explored problem and bridges don't usually collapse. I don't doubt that each bridge comes with unique challenges. But the purpose, user interface and constraints of bridges have remained stable enough for long enough to allow specialisation. That is not the case in many areas of software development.
  - hyperpallium 9y ago
    Speaking rationally, finding lowest common denominators (usually) aids computation.
d4mi3n 9y ago
I highly disagree with this, though I like your statement on principal. Greatness is highly dependent on context. I think your statement on greatness would apply to code that helps you learn and think. This is, however, NOT the kind of code I'd want to see at work. Great code in a business setting is simple, easy to understand, and has absolutely no subtlety. If I was looking for a literary example, great code in a business setting would be like the writing style you'd see in a newspaper: written for easy consumption by the greatest number of people possible.
saltedmd5 9y ago
I hope this comment is ironic. Great code should be predictable, obvious and easy to change.
- akvadrako 9y ago
  If it's predictable and obvious it'll be so boring, I won't even want to read it. A good program needs conflict and moral ambiguity!
  - bryanrasmussen 9y ago
    No, it needs lyrical beauty!
    - ogdoad 9y ago
      In C, everything rhymes in ';'.
      - 52-6F-62 9y ago
        LOL! I almost spit out my lunch. Which wouldn't be good because I'm sitting at my desk, in front of my station, in a very quiet office. Bravo.
  - hyperpallium 9y ago
    If your code doesn't give me existential angst, or make me ask, "who am I - really?", you're doing it wrong.
lmm 9y ago
Great code is so obvious and simple that once you've read it you can't possibly imagine ever finding the problem it solves difficult or confusing.
- lou1306 9y ago
  The problem is, the converse is not always true. Problems that are very easy to formulate ("find the k shortest paths from my house to my office") might require very sophisticated, non-obvious, non-simple code to be solved in a non-naive way.
  - lmm 9y ago
    We all know that sometimes problems are easy to state and hard to solve. To my mind the problem you describe sounds quite possibly impossible to do better than brute force, so any code at all that solved it would be to a certain extent insightful (but the simpler, the better - and truly great code for that problem would be code that let me understand how an easier solution was possible).
oblio 9y ago
> Great code, like great literature, should entertain, challenge and make you question your preconceptions and yourself. Preferably at 2 AM on a Saturday, when production is down ;)

Oh, the code I'm working with certainly does all that, but I wouldn't qualify it as good. :) I jest, but I agree with your statement.

NicoJuicy 9y ago

Great code is understandable for all. So it's not the code from insert developers name here

TeMPOraL 9y ago
No, it isn't. Programming is specialized work (I'd call it a discipline, but then we'd have to argue whether it's more an engineering discipline or art discipline). You have to gain knowledge and experience to understand it. A bridge blueprint is not understandable for all. It is understandable for all who took time and effort to gain education necessary to understand it. (The motivation between this comment is to counter the increasingly noticeable sentiment in our industry that everything needs to be dumbed down to the lowest common denominator; it's an understandable sentiment if you're selling something and want the biggest market, but it goes against what's needed to build great things.)
- crdoconnor 9y ago
  >everything needs to be dumbed down to the lowest common denominator That kind of ought to be the default for most code. However, it's the natural tendency of code to become abstruse and unnecessarily complicated. Since market forces will often tend to exploit rather than reward the work done by programmers to "dumb their code down" and inadvertently reward "clever magic understood by a limited number of experts" there's more of an incentive to amplify this effect than to work against it - especially where money is involved. I'm a bit conflicted because on the one hand I don't want to help developer compensation get ground down by billionaires or other business owners with an entitlement complex who consider developers to be "spoiled brats", but I do prefer working with clean, straightforward code.
  - barrkel 9y ago
    There are times when you simply have hard problems. For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. You'd also like the code generation itself to be fast. That puts a limit on how much you can break it up into parts that can be understood individually and in isolation. Optimization works in opposition to abstraction because the optimal often requires steps that span multiple abstraction layers, and often requires multiple instances of the specific over few instances of the general. Personally, I think the two biggest reasons code becomes unnecessarily complicated these days are (a) testing and (b) local modifications. Unit testing in particular encourages over-parametrization so that dependencies can be replaced for the purposes of testing; while normal software maintenance under commercial pressure leads to local modification because nobody has time to understand the whole. People instead make conservative local changes by adding parameters, extra if-statements, local lookup maps, etc. I've found elegant solutions are often on the other side of a hill from over-engineering. You write specific solutions, then you climb the a hill of abstraction as you add layers, indirections, parameters etc., until you reach a summit, where you can see the whole, and can then start boiling things back down again, only retaining abstraction where it's actually necessary, or perhaps replacing multiple abstractions with a single more powerful abstraction (I've found this to happen a lot with monads; another one is converting control flow into data flow).
    - crdoconnor 9y ago
      >There are times when you simply have hard problems. > >For example, take code generation (I actually have in mind a SQL query generator, but a compiler back end would do just as well). The problem is already abstract - the input is code, you're naturally writing code that manipulates code, like you would with macros or reflection. The problem is complex: you can generate simple code, but it won't perform well. There's irreducible complexity here that cannot be simplified away. Yeah sometimes you do, and that is exactly the kind of problem that is irreducibly complex, but I think new kinds of problems like this don't tend to crop up in the wild very often and when they do they tend to show up in subtle and non-obvious ways. The problem you've described is far from a new problem - it's the same problem space that is covered by ORMs. Furthermore, if I were working on a team where a developer has uttered the words "I've created my own ORM" (or something to that effect), my face has probably already landed in my palms. The rest of what you wrote I'm in vigorous agreement with though- especially the parts about unit testing, local modifications and "the other side of the hill". Seen all of that.
- fauigerzigerk 9y ago
  The thing is, people have been building bridges for thousands of years. What a bridge is and what it does changes very slowly. Almost all the specialised knowledge that bridge builders have is about _how_ to build a good bridge. Software is not like that. We may be experts in programming languages, algorithms and data structures, but the things we create and the problems we solve keep changing all the time. We're not usually experts in these problem domains and in some cases there are no such experts at all. So our code needs to be a lot more descriptive and written for readers that may not be very familiar with the problem at hand. We are more like lawyers supporting law makers or even like law makers themselves.
  - frostyel 9y ago
    no, more like Kings or Emperors WE'RE GODS!
  - falcolas 9y ago
    We think bridges are a very well explored domain. Then something like the Tacoma Narrows incident happens, and we realize how much of a fallacy that really is. Bridges are unique to their locations and their scale: what works over a creek will not work over a ravine. What works for a pedestrian will not work for a car. What works for a car will not work for a train. What works for a train will not work for a marching army.
    - fauigerzigerk 9y ago
      The Tacoma bridge collapse has a wikipedia entry exactly because bridge building is a very well explored problem and bridges don't usually collapse. I don't doubt that each bridge comes with unique challenges. But the purpose, user interface and constraints of bridges have remained stable enough for long enough to allow specialisation. That is not the case in many areas of software development.
- hyperpallium 9y ago
  Speaking rationally, finding lowest common denominators (usually) aids computation.

d4mi3n 9y ago

I highly disagree with this, though I like your statement on principal. Greatness is highly dependent on context. I think your statement on greatness would apply to code that helps you learn and think. This is, however, NOT the kind of code I'd want to see at work. Great code in a business setting is simple, easy to understand, and has absolutely no subtlety. If I was looking for a literary example, great code in a business setting would be like the writing style you'd see in a newspaper: written for easy consumption by the greatest number of people possible.

saltedmd5 9y ago

I hope this comment is ironic. Great code should be predictable, obvious and easy to change.

akvadrako 9y ago
If it's predictable and obvious it'll be so boring, I won't even want to read it. A good program needs conflict and moral ambiguity!
- bryanrasmussen 9y ago
  No, it needs lyrical beauty!
  - ogdoad 9y ago
    In C, everything rhymes in ';'.
    - 52-6F-62 9y ago
      LOL! I almost spit out my lunch. Which wouldn't be good because I'm sitting at my desk, in front of my station, in a very quiet office. Bravo.
- hyperpallium 9y ago
  If your code doesn't give me existential angst, or make me ask, "who am I - really?", you're doing it wrong.

lmm 9y ago

Great code is so obvious and simple that once you've read it you can't possibly imagine ever finding the problem it solves difficult or confusing.

lou1306 9y ago
The problem is, the converse is not always true. Problems that are very easy to formulate ("find the k shortest paths from my house to my office") might require very sophisticated, non-obvious, non-simple code to be solved in a non-naive way.
- lmm 9y ago
  We all know that sometimes problems are easy to state and hard to solve. To my mind the problem you describe sounds quite possibly impossible to do better than brute force, so any code at all that solved it would be to a certain extent insightful (but the simpler, the better - and truly great code for that problem would be code that let me understand how an easier solution was possible).

oblio 9y ago

> Great code, like great literature, should entertain, challenge and make you question your preconceptions and yourself. Preferably at 2 AM on a Saturday, when production is down ;)