5 ms·

Well said. I recently inherited a code base which was developed by some devs-for-hire while the company started building up the team to take over (including me

Well said. I recently inherited a code base which was developed by some devs-for-hire while the company started building up the team to take over (including me). I met the last remaining dev-for-hire for the handover and got the impression that the company paid very very close attention to how many hours they billed and which meetings they were allowed to attend, and 0 attention to the code they produced as long as it worked. Thankfully, the code was actually working well enough - and the thing that I appreciated most of all was the fact that at lots and lots of places in the code, there were frank comments like // This is completely undefined as of yet. I'm just implementing this how I think it should work, you can probably delete this and start over if it no longer makes sense. So incredibly helpful. No Chesterton's fencing around, just clarity about the parts of the code everyone knew was just around to do its job, then get rid of.

tobr 4y ago
> No Chesterton's fencing around That’s an interesting way to put it. I think that might be a good rule of thumb to help future maintenance: Avoid unintentionally erecting Chesterton’s fences.
- heywoodlh 4y ago
  > Avoid unintentionally erecting Chesterton's fences This is a great rule of thumb. I often find I unintentionally do that all the time and then I have to figure out why I did something I did. Trying to avoid that with good comments, documentation, etc. earlier in my career would have been a great practice. I find I often think something is so common-sensical that I would never forget and then come back a while later and have completely forgotten.
- galdosdi 4y ago
  The opposite of Chesterton's fence is "traffic cones" in my lexicon. As in, "put some traffic cones around that hack" meaning make sure there is a comment or appropriate error message or something that will make it clear to posterity that this is a known temporary sketchy situation, not an accidentally load bearing wall"
  - ThePadawan 4y ago
    See, this is the sort of behavior I would wish companies would test for when hiring engineers. Another (in-house, salaried) contributor to the project I took over added a error message (in a very specific error handler for exactly one REST endpoint), and I quote raise Exception("could not load data because of error")
    - galdosdi 4y ago
      FWIW I got this way thanks to a stint in the sysadmin/support/operations world at the start of my career. I wonder if trying to give juniors similar experiences might help jumpstart the process of getting this kind of intuition. When you operate software, you realize all the little things a developer can do to make the operator's life much easier or harder. I always thought this was the "true meaning of DevOps" -- thinking of how to make it easy to operate the software at dev/design time, as if it were an old school shrinkwrapped application like Windows 95... but instead it got turned into writing terraform or something haha.
      - ThePadawan 4y ago
        Well, funny thing is, that developer was also the operator. Because if he's the only one that understands the error message, he's the only one that can fix the problem. That's how you get credit with the suits if something breaks. No one ever notices a stable application. A programmer fixing a problem that no one understands? That must be a very smart person indeed. I'm being needlessly cynical at this point. This was just one person at one company. Overall, I do think that given the right incentives, what you describe can happen. But it does not someone in leadership to care. And that's a hard sell to me.
        galdosdi 4y ago
        Sigh, this is cynical but I've seen that sort of thing too and it really bums you out. When you're in an environment where this kinda crap isn't well understood it becomes frustrating, you end up feeling like you're rewarded for mediocre software engineering and punished for thinking ahead.

tobr 4y ago

> No Chesterton's fencing around That’s an interesting way to put it. I think that might be a good rule of thumb to help future maintenance: Avoid unintentionally erecting Chesterton’s fences.

heywoodlh 4y ago
> Avoid unintentionally erecting Chesterton's fences This is a great rule of thumb. I often find I unintentionally do that all the time and then I have to figure out why I did something I did. Trying to avoid that with good comments, documentation, etc. earlier in my career would have been a great practice. I find I often think something is so common-sensical that I would never forget and then come back a while later and have completely forgotten.
galdosdi 4y ago
The opposite of Chesterton's fence is "traffic cones" in my lexicon. As in, "put some traffic cones around that hack" meaning make sure there is a comment or appropriate error message or something that will make it clear to posterity that this is a known temporary sketchy situation, not an accidentally load bearing wall"
- ThePadawan 4y ago
  See, this is the sort of behavior I would wish companies would test for when hiring engineers. Another (in-house, salaried) contributor to the project I took over added a error message (in a very specific error handler for exactly one REST endpoint), and I quote raise Exception("could not load data because of error")
  - galdosdi 4y ago
    FWIW I got this way thanks to a stint in the sysadmin/support/operations world at the start of my career. I wonder if trying to give juniors similar experiences might help jumpstart the process of getting this kind of intuition. When you operate software, you realize all the little things a developer can do to make the operator's life much easier or harder. I always thought this was the "true meaning of DevOps" -- thinking of how to make it easy to operate the software at dev/design time, as if it were an old school shrinkwrapped application like Windows 95... but instead it got turned into writing terraform or something haha.
    - ThePadawan 4y ago
      Well, funny thing is, that developer was also the operator. Because if he's the only one that understands the error message, he's the only one that can fix the problem. That's how you get credit with the suits if something breaks. No one ever notices a stable application. A programmer fixing a problem that no one understands? That must be a very smart person indeed. I'm being needlessly cynical at this point. This was just one person at one company. Overall, I do think that given the right incentives, what you describe can happen. But it does not someone in leadership to care. And that's a hard sell to me.
      - galdosdi 4y ago
        Sigh, this is cynical but I've seen that sort of thing too and it really bums you out. When you're in an environment where this kinda crap isn't well understood it becomes frustrating, you end up feeling like you're rewarded for mediocre software engineering and punished for thinking ahead.