HN user

2mol

695 karma
Posts16
Comments72
View on HN

Is “unagentic engineer” a euphemism for human/not-AI?

No, it refers to people that are not "high agency", i.e. they might be smart and competent but need guidance on what to work on, as opposed to taking initiative themselves.

That's beside the point, we all know that one terrible engineer who is just incredibly productive and completely lacks any self-critical instincts. With LLMs this type of output becomes much more easy to produce, so what are you going to do if you're asked to review 10x the amount of code that you're reviewing right now?

Great article. I have an observation to the "engineers should know this and do good engineering" though: I work for a payments company and there is a fundamental career problem with becoming the ledger ninja: It's not enough work, and it's eventually done!

I've seen the following major phases of this work: 1) Build the ledger (correctly), and it will work well for a while. 2) Add convenience code for the callers, assist finance in doing reports/journaling, fix some minor bugs, take care of the operational bits (keep the database up). 3) Reach the scaling limits of your initial approach, but there are some obvious (not trivial) things to do: re-implement the transaction creation directly in the database (10x perf gain), maybe sharding, maybe putting old tx into colder storage, etc.

This is spread out over a while, so I haven't seen it be a full-time job, even at real startup-level (+10% MoM) growth. Even if it was, that's one person, not a whole team. I understand engineers that instead are pulled towards projects where they are in higher demand.

In another comment somebody said ledger systems are trivial when done right and super hard when done wrong - so if you did a good job it kinda looks like you just created 3 tables and some code. That seems thankless, and job searching as this type of specialist is harder than just being a generalist.

I mean, tigerbeetle looks extremely cool (I've watched the project develop since its inception), and I trust them to be rock-solid. But saying "just use this project that is very new and unproven, written in a new and unproven programming language" is just pretty unserious. At least talk about pros, cons, risks, and tradeoffs.

Sorry if this is ignorant, but I never understand what serverless Postgres means. What's different from a hosted Postgres instance? Some scaling characteristics or the fact you interact with it via an API instead of some library, ORM, or plain SQL?

Maybe as a slight input to why your comment would get downvoted: You're expressing a few semi-related frustrations, but it reads pretty incoherent, since you seem to assume folks already know the concepts you're talking about and agree with that worldview.

As such you're not really making sense, and human to human suggest the following: Try to get a different perspective and mingle more with offline people. The whole culture war topics and politics can really lead you down a crappy path, and it doesn't really reflect most of reality.

I hope this comes across as compassionate.

A while ago my team needed exactly this kind of auth solution, so the eng team reached out to Ory to clarify some technical questions that weren't covered by the docs. We were super enthusiastic about Ory. It looked solid, was open-source, and ticked all the right boxes.

We got an immediate response by a very motivated sales person who insisted to be connected with management and refused to put us in touch with anybody technical. It was a pretty off-putting experience, because it basically presumed that our eng team wasn't the decision maker (it was). I know a lot of companies throw their sales people at you, wanting to get in touch with somebody higher in the org chart, but it's still a pretty insulting experience for a tech-driven organization.

Needless to say we went with something else (not Auth0 either) and have been very happy.

The Forme of Cury 3 years ago

If you're into historical recipes, I can't recommend the "Tasting History" channel on youtube enough. It intersperses replicating the recipes with a whole load of historical context and nuance. "The Forme of Cury" has made some appearances on it as well.

https://www.youtube.com/@TastingHistory

It's generally agreed that it is totally safe (it solves the crossloading issue). I think we can all stick with the proven safe knots that we are comfortable with, and the fact it makes partner check a bit trickier applies also to the double bowline on a bight. I'm equally happy to triple-check myself and make it clear to my belayers that they are off the hook there.

Here is my pitch for "doppelter bulin" (double bowline on a bight):

Even if by some miracle the ENTIRE retraced half of that knot came undone, you would STILL be tied in with a normal bowline. I do a stopper knot too, but I think that illustrates just how bomber it is. And I only use it for single pitches for lead falls, on multipitches I still simply do a figure 8, because why get fancy?

The yosemite variant is fine, but maybe we shouldn't take the world's best climber as a reference who has a lot more context and experience to make very measured tradeoffs:

IMPORTANT: This knot is methodically NOT recommended and yes, it MAY untie while you are climbing. It can happen if your rope is new-ish (and that means it slides easily) and if you don’t tighten the knot with a lot of force. I am always splashing chalk on the knot in case of new rope to increase the friction and I do tighten it with a lot of force. The reasonable and recommended alternative, pretty common and very safe is double bowline. It is almost as big as eight, but at least it is always easy to untie.

https://adamondra.com/updates/my-climbing-more-about-feeling...

Nobody does a bowline, that's insane because you can't ring-load (cross-load) it. [0]

Europeans sometimes do the double bowline (traced), but the naming is ambiguous in english, so you have to google double bowline on a bight.

Americans used to do yosemite bowlines, but that fell out of fashion because figure eight (safe and foolproof) and double bowline (safe, trivial to untie after hefty lead falls) cover literally every use case perfectly.

[0] https://www.saferclimbing.org/en/blog/cross-loading-on-knots

It amuses me to no end to read all these nuanced (dis)agreements, but then miss the obvious connection: HN is exactly one of those proposed intellectual leagues!

A place in which curious people explore and debate their common interests, where you don't have to be an intellectual superstar to participate (although those occasionally show up).

I'm conflicted between

- this looks very useful, and

- "parse, don't validate" has proven to me to be a far better approach for all my use-cases.

I guess validation that is language/consumer-agnostic is more useful in a big-tech context? Or maybe the advantage is to put constraints on data that you are sending to a system out of your control?

Keen to hear opinions of people that worked with similar tools.

Yes! Those couple of seconds wait-time are a big bummer for that style of fast-feedback coding (for which there is the built-in `dotnet watch run` by the way).

Made me sad when I was playing around with generative art, where you would really want to see the result of your changes in a split-second.

You can check out ".NET Interactive Notebooks" in VSCode, that executes much faster, but it doesn't do this live watch.

Yup, I love Thoth. At work we just use System.Text.Json + FSharp.SystemTextJson though, that also generates (de)serializers, and it has a bunch of options to fine-tune naming conventions, sum type encoding, etc. Super useful and easy to hammer out the correct type for very big and nested JSONs.

Yeah, those boundaries between beautiful domain type <-> DTO <-> database is also something my team and I struggle with. In the end we're happy with just writing it out, but there is this nagging feeling that it could be more ergonomic.

I'd be interested to hear about other approaches. You could in theory just dump (automatically generated) JSON to the database and evolve your types with tagged versions, but then you have to write some boilerplatey converters between TypeV1, TypeV2, TypeV3, ...

I guess that's the price for staying away from full-blown ORMs?

It reminds me a bit of how in Elm you just suck it up and write the JSON en-/decoders by hand. Annoying at first, but then you get super obvious and maintainable code out of it, which is quite a joy.