This advice has worked very well for me.

But but but, in some scenarios it has been at the expense of my well being. It’s not good to take on more work and not let go of some of the things you’re currently doing. Moreover, finding “permission” from your boss to let those things go can be challenging.

I’ve found this works best when you and your boss agree on the problem you’re stepping into (not necessarily your solution). It may be that you need to stick your neck out and suffer for awhile for them to see your perspective.

When you’re on the same page about what you’re solving, a good manager will clear room for you.

In my experience, which is series A or earlier data intensive SaaS, you can gauge whether a program is taking a reasonable amount of time just by running it and using your common sense.

P50 latency for a fastapi service’s endpoint is 30+ seconds. Your ingestion pipeline, which has a data ops person on your team waiting for it to complete, takes more than one business day to run.

Your program is obviously unacceptable. And, your problems are most likely completely unrelated to these heuristics. You either have an inefficient algorithm or more likely you are using the wrong tool (ex OLTP for OLAP) or the right tool the wrong way (bad relational modeling or an outdated LLM model).

If you are interested in shaving off milliseconds in this context then you are wasting your time on the wrong thing.

All that being said, I’m sure that there’s a very good reason to know this stuff in the context of some other domains, organizations, company size/moment. I suspect these metrics are irrelevant to disproportionately more people reading this.

At any rate, for those of us who like to learn, I still found this valuable but by no means common knowledge

I'm not sure it's common knowledge, but it is general knowledge. Not all HNers are writing web apps. Many may be writing truly compute bound applications.

In my experience writing computer vision software, people really struggle with the common sense of how fast computers really are. Some knowledge like how many nanoseconds an add takes can be very illuminating to understand whether their algorithm's runtime makes any sense. That may push loose the bit of common sense that their algorithm is somehow wrong. Often I see people fail to put bounds on their expectations. Numbers like these help set those bounds.

Thanks this is helpful framing!

Can you help me understand what the value or use case of poethepoet is?

It allows you to define common tasks such as linting, running tests, building docs, etc under an alias.

So you can run

uv run poe docs

Instead of

uv run sphinx-build -W -b dirhtml docs/source docs/build

Many languages have a task runners baked into their package manager, but many others don’t. In Ruby it’s roughly the equivalent of Rake.

I think the question being asked is, if you’re already using mise (which has a built-in task runner) what is the advantage of going with the other one?

> Today we just don’t know

You never knew. There are plenty of intelligent, well-intentioned software engineers that publish FOSS that is buggy and doesn’t meet some arbitrary quality standards.

I think so. People will behave in the guardrails they are provided. If we have a problem with those rails, then in the US at least, democracy is (ostensibly maybe) the tool to make them more aligned with what we want.

> [Linear] mentioned that this approach is working very well for them, and they have achieved, at the time of writing, 96% retention.

Is this evidence that their hiring process is sound, and is it more a consequence of Linear being a rocketship? Perhaps if their retention number includes when a bad hire is let go, this is more believable that they are meeting their standards.

I’ve only worked at small startups, but usually “retention” means that no one has left for somewhere better.

This is a valid point. But I think there is merit on working for a few days with a potential hire in order to see how good of a fit they are to you and you to them. You reduce the chances of having a false positive hire.

Intuitively I agree with this too. I would love to see results from other companies as evidence it’s correct, is all

Unfortunately in practice you see snowflake implementations left and right in python.

It’s still unclear to me if python is too expressive for its own good, or if it’s so widely used, that it’s impossible to avoid nonsense

I assume like 70% of Python developers do not even know the Zen of Python, let alone PEP-8. It's likely the size.

Sorry this may be a dumb question, why would you cache a flow?

This is interesting to me, too! My team is in the midst of opening new reqs. A leader wants to hire based on skillset. The team wants to hire based on upcoming work. We had a decent employee churn recently because the work wasn’t what they thought they were hired for.

I can see both sides. We don’t have work planned more than a quarter out (a good thing IMO). Generalist SWEs make a good fit. But we think we need someone specialized in AI/ML. Unclear to me if that’s the case… and how to plan for it if we don’t want to explore concrete features we _might_ build.

Amen to this. Everyone is worried about losing their job. I’m pretty sure at the same time it’s cementing them.