> the purpose of the trust metric is to certify that a given user account on Advogato is known by the Advogato community to actually belong to the individual who claims it and is known to be a member of the free software and open source community. The user may be an crank, annoying, or of a political persuasion that you don't agree with. What the trust metric attempts to guarantee is that they really are who they say they are
Sounds like a slightly different goal but certainly an interesting system to look at
Yep but using 2 DBs within the same PG instance won't improve performance since it's using the same disk.
Managing multiple DB instances across multiple hosts requires a lot more effort, configuration and doubles your hosting costs vs running Redis on the same host with Sidekiq IMO.
A lot of people seem to have zeroed in on "the manager's decision" and completely missed that it referred to the department manager, not the team manager, and the story is told from the perspective of the team manager.
Not sure the story is even real but apparently that was going on long enough without his manager knowledge that the manager was dead set on making tims exit preparations
One of the challenges with this approach is answering "how much will it cost" and "how long will it take" - that being said, its often hard for non-developers to articulate exactly what they want without connecting it to something more concrete in the form of user interface.
Those questions aren't answerable in the first place.
I like the general idea behind ShapeUp: don't ask "how long will it take" but "how much time are you willing to literally throw in the bin to learn more about the problem". Committing to research is easy and HONEST. Committing to a finished product by a date is incredibly hard/impossible and a lie.
It's quite rare to be in a scenario where not making timeline estimates is even an option.
* If you're B2B, your marginal clients are constantly deciding whether to sign or renew their contracts, and their money directly depends on promises you make them about when features they want will be available.
* If you have competitors, you have to evaluate how your product will match up with them over time. If there's some killer feature you could build with 3 engineers in the next quarter, you should probably do it. If there's a killer feature your competitors could build that fast, but you have some tech debt that would make it take 3 years, you'd better find a strategy to make that feature less important.
* If you have a large or growing product, you have more potential projects to do than people to do them, so you're going to have to decide which will produce the most benefits for a given unit of time investment.
If you have a small, non-contract-based project with no direct competitors? Sure, it's possible to get away with the "we'll finish when we finish" strategy. But there's not a ton of space in that niche, and unless you get quite lucky it's not where the big bucks are going to be.
I think this is largely a matter of habit, and not of reality. Yes, you might get the business short term if you lie and say some feature will be available Q3. But over time that type of constant lying erodes trust and hurts you.
I get it, you might need to do it to survive in the beginning because competitors will be doing the lying. But I'm saying you need to stop lying as soon as possible for the long term health of the relationship.
I didn't want to quibble about whether it's fair to call it "lying", but I think the term is misleading you. There's simply no such thing as a business relationship without time estimates. It's not a short term vs. long term or trust vs. distrust tradeoff - unless your business model consists entirely of off-the-shelf purchases, your customers will want estimates about what you'll do in the future and when.
There is something delightfully odd about a Tailwind project saying, "instead of writing 100 class names, use semantic class names" – which, yanno, is pretty much what everyone was doing already before Tailwind.
Yeah, I think the DaisyUI developers miss the point of Tailwind. You should almost never use "semantic class names" with Tailwind (and what even is a semantic class name, honestly? It's all context-, developer-dependent) and instead go for a component (using a js framework, a web component, or other) and write the component with utility classes.
I tried out DaisyUI and I think it had kind of best of both worlds and was pretty ergonomic. IMO the main issues with it were that it's just CSS (not much accessibility etc. thought out for me), but the design isn't that great (in practice writing custom components without DaisyUI could have gotten the same results).
