5 ms·

Having seen too many times how throwaway code and proof of concepts went into production I try to always write decent code. You don’t need all the bells and whi

Having seen too many times how throwaway code and proof of concepts went into production I try to always write decent code. You don’t need all the bells and whistles but just give things decent names, put repeated stuff into functions, avoid memory leaks, define constants and so on. It also reduces cognitive overhead. A lot of people seem to spend a Lot of energy thinking about whether a project needs proper coding or not.

hinkley 7y ago
There was a time where this got so bad at one company, that I was getting neurotic. To put an order of magnitude on it, my mentor got fired for calling out his boss on some of the demo-ware shipping bullshit. Before this all came to a head, I started doing proof of concept work as command line only. This allowed me to give them estimates they had to listen to, instead of them just assuming that because they could see a UI that we could just pretty it up and ship it next month. Clearly, they reasoned (as if anything they did resembled reason) my two to three month estimate was sandbagging and it was okay to tell the customer we’re almost done.
- hinkley 7y ago
  I fear I have given a false impression by saying 'he was fired'. John, let's call him, was summarily fired. GTFO. And in an early morning meeting, no less. I got to hear it from the coworker who was best at deadpan jokes, so I didn't believe him the first time when I asked, "Did I miss anything?"
avetisk 7y ago
I totally agree! Most of the time you just needed that little effort to keep things neatly and tightly together. No need to separate it: we just need to keep the minimal good habits all the time!
heavenlyblue 7y ago
That's one of the key reasons why I hate when people say they can "develop" in <insert your average text editor>. In an IDE I can quickly type out a full function body with 1-character variable names, then run it and see what happens. Immediately after I have seen it work I can go back and rename all of the variable names into something more descriptive. This is also easier now because you know exactly what the variables are used for. You can do the same immediately for constants (most of the IDEs will allow you to "extract the given expression as a constant on the module level" or alike). This can never work in a text editor because you need to know how that specific 1-letter tokens. There is no reason to write non-descriptive code unless you're trying to save maybe 5% of your time. At a job where timelines can easily go orders of magnitude higher than expected, you're trying to shave off a minor portion of your net time spend...
- gregmac 7y ago
  I'd questing even saving any time, let alone 5%. I guess the supposed time would be typing and thinking of a good name? Maybe you save a bit of time during very initial prototyping, when you're just trying to create the exact algorithm for something (eg working with a dozen or so lines of code). As soon as it's actually used, even if in a "proof-of-concept" prototype, you'll easily spend double that time on cognitive overhead (eg, the next day/week, trying to remember what that variable is) or just in typing out comments. If other people are ever looking at or using the code, it's easily 10x the work you're creating. Another way of saying this: once your code exists for more than a couple hours, it should have good (not necessarily perfect) variable/function/token names. I agree on the ide vs text editor comment, and add: another nice thing about using a good ide is you can rename the declaration and let the ide update everything else.
  - samatman 7y ago
    Agreed, this is just one of those moments where I learn that other people have a very different workflow from mine. I can't write an algorithm without coming up with decently descriptive names for the components. Of course, sometimes I come up with better ones later, but the entire idea of using placeholders is deeply foreign to how I think. Which isn't to say I don't use single-letter variables, `d` is a perfectly cromulent way to spell delta although `Δ` is better if it's allowed. It's uncommon, and when I do, they're no more likely to change than any other name.
  - usrusr 7y ago
    Do we even parse all the variable name when reading code? I know I do at least sometimes, because I know how often I am renaming in anger, but a lot of times I just see the IDE default of (in java syntax) "Foo foo; Bar bar;" and I'm perfectly happy with it. The tokens have a certain length that helps keeping them apart visually and they are not outright deceptive. Real life class names can be long, but the IDE even helps chopping them down reasonably. Good enough naming can be tremendously easy, sloppy even, once you've learned which names don't pass that bar. Where naming does get hard, and where inconsistencies become painful, is when you have too many things that could have the same name.
seanmcdirmid 7y ago
If you work in a strictly prototyping or research org, then it is much easier to accept what you are doing is a demo/prototype, and since you aren’t part of a production org, their is little chance of your code going accidentally into production (eg for a UX prototyper/design technologist). These are only things at big companies, however, and even bigger companies often have developers pulling double duty. Still there is a huge opportunity cost if getting the wrong code up to production quality prevents working on the next prototype that gets you closer to the right thing. And I’m not talking about best coding practices, but putting in extensive comments, doing a bunch of tests, etc...
- Ididntdothis 7y ago
  Personally I question the assumption that prototyping with bad code is faster than writing decent code. You don’t need full test coverage or deploy pipeline but I doubt that introducing constants, meaningful names, functions and other basic stuff slows down prototyping.
  - sdenton4 7y ago
    Yeah, lots of these things are just about cultivating good habits... Once it's a habit, there's no cognitive overhead. I also tend to wonder how often research results are tainted by subtle implementation bugs that may have been more obvious with better coding habits.
  - Scene_Cast2 7y ago
    If your prototype only has a couple of buttons (or images you can select, or whatever) - it's faster to hardcore the names and handle those cases explicitly. A good abstraction requires knowing how you'll be expanding the code (e.g. will there be more images in the future? Hundreds or billions? Or will that feature Y need to be built out?). Building that abstraction right away can definitely slow you down, as you'll be fighting it a lot of the time.
    - nicoburns 7y ago
      Lack of abstraction for a one off (or two off) feature is rarely a problem. And if you need to do something 3 or more times, rhen you can probably build the abstraction pretty quickly...
harikb 7y ago
Most people underestimate the value of refactoring existing code. Even a prototype provides a good base to start the refactoring. Of course it will help if the programming language helps with easy refactoring. In my projects, I expect to refactor the code at least 3 or 4 times before it reaches a state I am comfortable with. IMHO, this is far better than starting from scratch. Both code and SQL are meant to refactored. Don’t over-engineer from the beginning adding usecases we know nothing about.
- capableweb 7y ago
  Well, you could also start from scratch multiple times and get better and faster each time, as you learn more things. And in the end you get a more fitting design for the final learnings.
  - Ididntdothis 7y ago
    If I had to rewrite something from scratch several times I would get very bored and the quality would probably go down. Better to refactor.
    - usrusr 7y ago
      I like to refactor in the big and to rewrite in the small. In the big, the n-th rewrite will be just as constrained by how much we can keep in our head at the same time as the original attempt. Refactoring essentially means offloading to the computer what you already have in a computer-readable format. What an opportunity! What I mean with rewriting in the small is taking an existing logic-wart and, while trying to decipher it, taking notes in the form of a rewrite. After finishing the first approximation you take a long, skeptical look at both versions, "is that simple, elegant thing really doing the same?" and then you see the additional corner cases (and/or bugs, sometimes you'll never know) in a clarity that would be impossible to achieve just looking at the original code. It's mostly a reading tool. Sometimes I will trash the rewrite, but often the new version, with the non-obvious bits added will be far more readable than the original because it was written from the perspective of a reader with little knowledge of what the code should do, not by someone deeply immersed in the problem space.

hinkley 7y ago

There was a time where this got so bad at one company, that I was getting neurotic. To put an order of magnitude on it, my mentor got fired for calling out his boss on some of the demo-ware shipping bullshit. Before this all came to a head, I started doing proof of concept work as command line only. This allowed me to give them estimates they had to listen to, instead of them just assuming that because they could see a UI that we could just pretty it up and ship it next month. Clearly, they reasoned (as if anything they did resembled reason) my two to three month estimate was sandbagging and it was okay to tell the customer we’re almost done.

hinkley 7y ago
I fear I have given a false impression by saying 'he was fired'. John, let's call him, was summarily fired. GTFO. And in an early morning meeting, no less. I got to hear it from the coworker who was best at deadpan jokes, so I didn't believe him the first time when I asked, "Did I miss anything?"

avetisk 7y ago

I totally agree! Most of the time you just needed that little effort to keep things neatly and tightly together. No need to separate it: we just need to keep the minimal good habits all the time!

heavenlyblue 7y ago

That's one of the key reasons why I hate when people say they can "develop" in <insert your average text editor>. In an IDE I can quickly type out a full function body with 1-character variable names, then run it and see what happens. Immediately after I have seen it work I can go back and rename all of the variable names into something more descriptive. This is also easier now because you know exactly what the variables are used for. You can do the same immediately for constants (most of the IDEs will allow you to "extract the given expression as a constant on the module level" or alike). This can never work in a text editor because you need to know how that specific 1-letter tokens. There is no reason to write non-descriptive code unless you're trying to save maybe 5% of your time. At a job where timelines can easily go orders of magnitude higher than expected, you're trying to shave off a minor portion of your net time spend...

gregmac 7y ago
I'd questing even saving any time, let alone 5%. I guess the supposed time would be typing and thinking of a good name? Maybe you save a bit of time during very initial prototyping, when you're just trying to create the exact algorithm for something (eg working with a dozen or so lines of code). As soon as it's actually used, even if in a "proof-of-concept" prototype, you'll easily spend double that time on cognitive overhead (eg, the next day/week, trying to remember what that variable is) or just in typing out comments. If other people are ever looking at or using the code, it's easily 10x the work you're creating. Another way of saying this: once your code exists for more than a couple hours, it should have good (not necessarily perfect) variable/function/token names. I agree on the ide vs text editor comment, and add: another nice thing about using a good ide is you can rename the declaration and let the ide update everything else.
- samatman 7y ago
  Agreed, this is just one of those moments where I learn that other people have a very different workflow from mine. I can't write an algorithm without coming up with decently descriptive names for the components. Of course, sometimes I come up with better ones later, but the entire idea of using placeholders is deeply foreign to how I think. Which isn't to say I don't use single-letter variables, `d` is a perfectly cromulent way to spell delta although `Δ` is better if it's allowed. It's uncommon, and when I do, they're no more likely to change than any other name.
- usrusr 7y ago
  Do we even parse all the variable name when reading code? I know I do at least sometimes, because I know how often I am renaming in anger, but a lot of times I just see the IDE default of (in java syntax) "Foo foo; Bar bar;" and I'm perfectly happy with it. The tokens have a certain length that helps keeping them apart visually and they are not outright deceptive. Real life class names can be long, but the IDE even helps chopping them down reasonably. Good enough naming can be tremendously easy, sloppy even, once you've learned which names don't pass that bar. Where naming does get hard, and where inconsistencies become painful, is when you have too many things that could have the same name.

seanmcdirmid 7y ago

If you work in a strictly prototyping or research org, then it is much easier to accept what you are doing is a demo/prototype, and since you aren’t part of a production org, their is little chance of your code going accidentally into production (eg for a UX prototyper/design technologist). These are only things at big companies, however, and even bigger companies often have developers pulling double duty. Still there is a huge opportunity cost if getting the wrong code up to production quality prevents working on the next prototype that gets you closer to the right thing. And I’m not talking about best coding practices, but putting in extensive comments, doing a bunch of tests, etc...

Ididntdothis 7y ago
Personally I question the assumption that prototyping with bad code is faster than writing decent code. You don’t need full test coverage or deploy pipeline but I doubt that introducing constants, meaningful names, functions and other basic stuff slows down prototyping.
- sdenton4 7y ago
  Yeah, lots of these things are just about cultivating good habits... Once it's a habit, there's no cognitive overhead. I also tend to wonder how often research results are tainted by subtle implementation bugs that may have been more obvious with better coding habits.
- Scene_Cast2 7y ago
  If your prototype only has a couple of buttons (or images you can select, or whatever) - it's faster to hardcore the names and handle those cases explicitly. A good abstraction requires knowing how you'll be expanding the code (e.g. will there be more images in the future? Hundreds or billions? Or will that feature Y need to be built out?). Building that abstraction right away can definitely slow you down, as you'll be fighting it a lot of the time.
  - nicoburns 7y ago
    Lack of abstraction for a one off (or two off) feature is rarely a problem. And if you need to do something 3 or more times, rhen you can probably build the abstraction pretty quickly...

harikb 7y ago

Most people underestimate the value of refactoring existing code. Even a prototype provides a good base to start the refactoring. Of course it will help if the programming language helps with easy refactoring. In my projects, I expect to refactor the code at least 3 or 4 times before it reaches a state I am comfortable with. IMHO, this is far better than starting from scratch. Both code and SQL are meant to refactored. Don’t over-engineer from the beginning adding usecases we know nothing about.

capableweb 7y ago
Well, you could also start from scratch multiple times and get better and faster each time, as you learn more things. And in the end you get a more fitting design for the final learnings.
- Ididntdothis 7y ago
  If I had to rewrite something from scratch several times I would get very bored and the quality would probably go down. Better to refactor.
  - usrusr 7y ago
    I like to refactor in the big and to rewrite in the small. In the big, the n-th rewrite will be just as constrained by how much we can keep in our head at the same time as the original attempt. Refactoring essentially means offloading to the computer what you already have in a computer-readable format. What an opportunity! What I mean with rewriting in the small is taking an existing logic-wart and, while trying to decipher it, taking notes in the form of a rewrite. After finishing the first approximation you take a long, skeptical look at both versions, "is that simple, elegant thing really doing the same?" and then you see the additional corner cases (and/or bugs, sometimes you'll never know) in a clarity that would be impossible to achieve just looking at the original code. It's mostly a reading tool. Sometimes I will trash the rewrite, but often the new version, with the non-obvious bits added will be far more readable than the original because it was written from the perspective of a reader with little knowledge of what the code should do, not by someone deeply immersed in the problem space.