[necovek]

I am generally fine with duplicating some of the "scaffolding" between projects to aid with readability and have less magic when trying to understand the code.

Eg. most languages would enable you to build a custom library, but then it becomes non-obvious what's exactly happening to someone diving into the project, a most engineers never bother fixing/improving the original library, and you end up with crap on top to "work-around" the poorly understood behaviour.

Eg. recently, I've fixed an internal library holding multiple locks around one tiny block of async code, rendering the entire thing synchronous, which was being worked around by devs using multiprocessing or multithreading for a couple years. I've reduced that library code to basically a couple of functions, but my preference would be to actually copy-paste those 200 lines into every component using it — while you have the problem when you want to update it everywhere, your average engineer focused on solving a different business problem will be better equipped to handle it.

My personal gripe is with the abuse of @decorators in Python, which are side-effect pits of hell (yes, the code can look really nice).

I personally don't use snippets, but I do copy-paste some of that scaffolding between projects (though I am mostly a manager these days and hardly get any time to code, so take that with a huge grain of salt) — snippets as such never added much value to me.

[necovek]

> ...abuse of @decorators in Python, which are side-effect pits of hell.

And just as I posted this, an articles shows up on the front page (https://www.dbos.dev/blog/what-is-lightweight-durable-execut...) claiming this:

> So how does this work? The key is in those decorators, DBOS.workflow() and DBOS.step(). They wrap your functions with the code that durably executes them. At a high level, they persist your program’s execution state–which workflows are currently executing and which steps they’ve completed–in a Postgres database.

Ouch! Those innocent looking lines of @DBOS.workflow or @DBOS.step make decorated functions actually connect to a Postgres database somewhere, and you can't be certain if you can test those functions without Postgres anymore. Ouch, ouch, ouch!

So, developers, please, remember the implicit vs explicit rule of thumb.

[js8]

IMHO What you describe is mostly a tooling problem. Current tooling doesn't let users to see the referenced/abstracted code as simply as the local code (for example, expand function definitions). So people tend to avoid abstracting it.

[necovek]

Yeah, that's a great point!

But solving that tooling issue is hard (or we'd have a great solution already), and we choose our compromises based on the reality we live in. Neither is perfect, and we should continue thinking how we can improve the situation from all angles, including improving the tooling as you suggest.