5 ms·

You should view this condition as something to fix in yourself. Take joy in doing these things with precision and efficiency, and making your work easy to under

You should view this condition as something to fix in yourself. Take joy in doing these things with precision and efficiency, and making your work easy to understand and explain to others. It's hubris and, frankly, rude to subject your professional colleagues to your artistic expression.

ahelwer 7y ago
Look bud, not all of us want to take delight in being an easily replaceable automata. It ain't a personality flaw.
- derefr 7y ago
  So you’d take joy in making your coworkers’ lives hell instead? I understand the kind of joy-of-expression that lives in things like https://poignant.guide/dwemthy/ https://poignant.guide/dwemthy/, but if you attempt to put that in a production codebase, I’m not gonna be at-all positive in code review.
  - ahelwer 7y ago
    Great, I'll let every reviewer of my code know that they've been doing it wrong.
    - derefr 7y ago
      Are you saying that you actually write the kind of code that I linked? Because my expectation was that you’d look at it and say “well, my code certainly doesn’t look like that. It’s quite reasonable in comparison, in fact.” I don’t think I’ve ever seen anyone write code like Dwemthy’s Array in a project that has to “do something productive”, even if they’re the only one working on it.
      - ahelwer 7y ago
        Maybe the sort of code you linked isn't the sort of code we're talking about? Nobody is running around bigco writing demoscene stuff or whatever.
- sagichmal 7y ago
  Doing the things I said well makes you an irreplaceable member of a team, worth your weight in gold. Save art for the canvas, for your weekends, for your loved ones. Bring a professional self to your job.
  - ahelwer 7y ago
    Not sure why you seem to think code written with feeling behind it is some unmaintainable mess. That's been the opposite of my experience. The way people fail in this line of work, if they have skill, is burnout. Burnout is the thing that'll get you. So you do whatever you can to stave it off - and that requires working on something you actually care about in some way.
    - sagichmal 7y ago
      We aren't talking about "code with feeling behind it" but rather "code as some kind of art".
      - nicoburns 7y ago
        You might have a different idea of what art looks like. Well designed abstractions are elegant, conceptually simple, and not-leaky. These tend to make code more maintainable and easier to comprehend.
        sagichmal 7y ago
        This definition of art, though not wrong, is so expansive as to be meaningless, especially in the context of this discussion.
        tensor 7y ago
        One of the things you learn after writing code long enough, is that there is no such thing as a perfect abstraction, or even a non-leaky one. Eventually you run into edge cases, either in performance or functionality, that causes you to add warts to your abstraction.
leetrout 7y ago
"making your work easy to understand and explain to others" This is the hallmark of a professional (very likely mature and senior) team member. Nothing to prove and interested in a maintainable project. There are times for clever, no doubt. Every rule has an exception. Bill (William) Kennedy at Ardan Labs has a line he uses in his talks: the bottom level developers need to grow and come up and the top level developers need to avoid cleverness and come down and everyone meet in the middle.
Redoubts 7y ago
> Take joy in doing these things with precision and efficiency, and making your work easy to understand and explain to others. If you think this is different than what the parent is describing then you’re doing it wrong
- sagichmal 7y ago
  "Code as art" implies a strictly different set of criteria than the ones I listed. If the Venn diagrams overlap a lot for you, that's great, but it's rare.
  - thinkpad20 7y ago
    I think you have a very specific, and not widely shared, definition of “code as art.” Code as art does not mean code full of pointless Rube Goldberg mechanisms or following some esoteric golden ratio whatever. For me, “code as art” means code which is well-abstracted, readable, correct, concise, maintainable, extensible, well-documented, performant, etc — I.e. reflecting the things that matter to me as a developer. The process of getting to the point where the code has all of those things, or as many as possible, is indeed the “art” of coding. To assume that the result is some horrible morass of spaghetti that no coworker wants to read is a strange one for sure.
    - mntmoss 7y ago
      The thing I detest about discussions of code aesthetics is the idea that the quality metrics you speak of have such a direct relationship to the "product features" of the language, that we can simply know it's good by looking at it, and we are hapless simpletons unable to write this so-called "beautiful" or "clean" code if we do not have the feature available. That is all bullshit. Most of the features are shiny baubles for raccoons and magpies, I do NOT know what good code looks like(I can only state whether the coding style eliminates some class of errors), and what matters the most is the overall shape of the tooling. Some languages have a big bag of tricks, other languages let you extend them to the moon, and still others make you work at it a little. In the end it's all just computation, and the tool choice can be reduced to a list of "must haves" and "cannots". If you need more expressive power -- make your build a little more complex and start generating code, give it a small notion of types or static invariants. It only has to generalize as much as your problem does, and that leads you to build the right abstraction instead of dumping an untried language feature on the problem in the hope that it is a solution.

ahelwer 7y ago

Look bud, not all of us want to take delight in being an easily replaceable automata. It ain't a personality flaw.

derefr 7y ago
So you’d take joy in making your coworkers’ lives hell instead? I understand the kind of joy-of-expression that lives in things like https://poignant.guide/dwemthy/ https://poignant.guide/dwemthy/, but if you attempt to put that in a production codebase, I’m not gonna be at-all positive in code review.
- ahelwer 7y ago
  Great, I'll let every reviewer of my code know that they've been doing it wrong.
  - derefr 7y ago
    Are you saying that you actually write the kind of code that I linked? Because my expectation was that you’d look at it and say “well, my code certainly doesn’t look like that. It’s quite reasonable in comparison, in fact.” I don’t think I’ve ever seen anyone write code like Dwemthy’s Array in a project that has to “do something productive”, even if they’re the only one working on it.
    - ahelwer 7y ago
      Maybe the sort of code you linked isn't the sort of code we're talking about? Nobody is running around bigco writing demoscene stuff or whatever.
sagichmal 7y ago
Doing the things I said well makes you an irreplaceable member of a team, worth your weight in gold. Save art for the canvas, for your weekends, for your loved ones. Bring a professional self to your job.
- ahelwer 7y ago
  Not sure why you seem to think code written with feeling behind it is some unmaintainable mess. That's been the opposite of my experience. The way people fail in this line of work, if they have skill, is burnout. Burnout is the thing that'll get you. So you do whatever you can to stave it off - and that requires working on something you actually care about in some way.
  - sagichmal 7y ago
    We aren't talking about "code with feeling behind it" but rather "code as some kind of art".
    - nicoburns 7y ago
      You might have a different idea of what art looks like. Well designed abstractions are elegant, conceptually simple, and not-leaky. These tend to make code more maintainable and easier to comprehend.
      - sagichmal 7y ago
        This definition of art, though not wrong, is so expansive as to be meaningless, especially in the context of this discussion.
      - tensor 7y ago
        One of the things you learn after writing code long enough, is that there is no such thing as a perfect abstraction, or even a non-leaky one. Eventually you run into edge cases, either in performance or functionality, that causes you to add warts to your abstraction.

leetrout 7y ago

"making your work easy to understand and explain to others" This is the hallmark of a professional (very likely mature and senior) team member. Nothing to prove and interested in a maintainable project. There are times for clever, no doubt. Every rule has an exception. Bill (William) Kennedy at Ardan Labs has a line he uses in his talks: the bottom level developers need to grow and come up and the top level developers need to avoid cleverness and come down and everyone meet in the middle.

Redoubts 7y ago

> Take joy in doing these things with precision and efficiency, and making your work easy to understand and explain to others. If you think this is different than what the parent is describing then you’re doing it wrong

sagichmal 7y ago
"Code as art" implies a strictly different set of criteria than the ones I listed. If the Venn diagrams overlap a lot for you, that's great, but it's rare.
- thinkpad20 7y ago
  I think you have a very specific, and not widely shared, definition of “code as art.” Code as art does not mean code full of pointless Rube Goldberg mechanisms or following some esoteric golden ratio whatever. For me, “code as art” means code which is well-abstracted, readable, correct, concise, maintainable, extensible, well-documented, performant, etc — I.e. reflecting the things that matter to me as a developer. The process of getting to the point where the code has all of those things, or as many as possible, is indeed the “art” of coding. To assume that the result is some horrible morass of spaghetti that no coworker wants to read is a strange one for sure.
  - mntmoss 7y ago
    The thing I detest about discussions of code aesthetics is the idea that the quality metrics you speak of have such a direct relationship to the "product features" of the language, that we can simply know it's good by looking at it, and we are hapless simpletons unable to write this so-called "beautiful" or "clean" code if we do not have the feature available. That is all bullshit. Most of the features are shiny baubles for raccoons and magpies, I do NOT know what good code looks like(I can only state whether the coding style eliminates some class of errors), and what matters the most is the overall shape of the tooling. Some languages have a big bag of tricks, other languages let you extend them to the moon, and still others make you work at it a little. In the end it's all just computation, and the tool choice can be reduced to a list of "must haves" and "cannots". If you need more expressive power -- make your build a little more complex and start generating code, give it a small notion of types or static invariants. It only has to generalize as much as your problem does, and that leads you to build the right abstraction instead of dumping an untried language feature on the problem in the hope that it is a solution.