[ThePadawan]

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]

> 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]

> 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]

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]

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]

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]

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]

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.