rbetts

Median wealth of a US households by race: white $250k; black: $27k; asian: $320k

https://www.pewresearch.org/2023/12/04/wealth-gaps-across-ra...

The message is also that consumerism is driven by demand creation - and that demand creation takes its toll on both the demander and the buyer.

Many studies find that a majority of personal bankruptcies in the US involve medical debt with some estimates of ~500,000 medical-cost contributed bankruptcies per year. A hospital (might) not kick you to the curb if you are dying in their emergency room. However, this is not the same as catastrophic coverage.

The article discussed this and had an interesting point (and some stats for evidence) - that shooters waiting in the corner create space for driving to the basket.

Right? Trans people being comfortable being open in public. Obama's "open borders" while deporting record numbers of immigrants (https://www.the-independent.com/news/world/americas/us-polit...). Uncomfortable protests in support of Palestine. What a shit-show. I can't believe we made it out alive.

I believe (most) people contribute their ambitions to nurture safe, peaceful, friend-filled communities. AGI won’t obsolete those human desires. Hopefully we weather the turbulence that comes with change and come out the other side with new tools that enable our pursuits. In the macro, that’s been the case. I am grateful to live in a time of literacy, antibiotics, sanitation, electricity… and am optimistic that if AGI emerges, it joins that list of human empowering creations.

Here's a paper by the author on the topic:

https://www.researchgate.net/publication/355443578_The_origi...

This assumes that vendors have IP rights to open source the firmware, which seems unlikely. Presumably there are third party commercial components they don't have rights to publish.

A rule like this essentially forbids closed source software. (Which, hey, might be a good thing... but then just mandate that directly and outlaw closed source software licensing.)

That would make today the worst day to plant a tree?

I find the MBA hate on HN so weird. The founders and leaders of these companies are technologists first. We need to look in the mirror - there's no dodge that software developers, not MBAs, have built these invasive, addictive, misleading, and dangerous products.

> burn-down / velocity charts

You need some coarse odometer to know where the finish line is. Burn-up charts are a reasonable input to that and can be very low effort. Just knowing where you hit the inflection point between new-issues added to a milestone vs. issues resolved is useful. If you can replace a burn up chart with tangible test results matrix or similar - even better.

> retrospectives

I have never found per-sprint retros useful, either. I guide teams to do a retro when the issues raised in the previous retro are resolved. WIP control FTW.

> poker sessions

In my experience, planning sessions are one of the most impactful parts of the stereotypical scrum process for three reasons: (a) Planning creates a consensus within the team about what the story actually means; (b) Planning often leads to someone proposing a good 80/20 trade-off or raising an important point that avoids future re-work or unexpected tech debt. (c) Breaking big tasks into actionable, independently useful, small tasks is one of the hardest things for junior developers to learn. A lot of mentorship and teaching happens in good planning meetings. I encourage teams to try planning for the benefits of the process and not worry at all about fine grained points - "trivial", "medium", "unknown" is typically enough. Lots of mature teams will plan ad-hoc as they are ready for new work. This is my personal preference. But teaching teams how to plan effectively in a weekly planning meeting is often a good starting point.

> daily stand-ups

Standups that are control points for managers and expensive status gathering shortcuts are horrible. standups that are self-organizing, especially for teams that have ops + dev responsibilities, can be really useful. Nothing wrong with making a plan for the day - it should just take 10m.

> user stories and related tickets (eg in JIRA)

You should write down what you want to do somewhere and a few checklists go a long ways towards improving quality management.

I have never found scrum to be a good process (like the article, I find it very grinding) and I strongly agree with the posted article. But a good dev process likely includes all of these elements in some shape.

When your enterprise product is a superset of your open source product, you need a trigger that leads to buying. If that trigger is a feature, then it is only effective as a trigger if it is broadly useful to the product. In which case, you either withhold it from open source or cripple (or rate limit it) in open source. Your sales team - told to meet quarterly revenue targets and held accountable to that - will lobby for strict limits on these features.

My first hand experience is that there are two likely outcomes: (1) You limit the utility of the open version to create a buying trigger and your open source users dwindle away as the open product doesn't meet their needs. Or, (2) your community has sufficient momentum to build the feature itself and your sales team starts losing deals to your open source offering.

This model also creates harmful intra-organization conflict between those who argue for short-term revenue (probably their continued employment depends on that) vs. those who argue for the largest open source user base. It also creates conflict with your users as you intentionally offer a worse product to your largest user group (open source users).

Git clients became popular interfaces to SVN. This is how the organizations I was at moved from svn to git -- we/devs started preferring git locally and eventually migrated the backends to match.

Sales people are trying to discern what pain you are facing, your level of urgency for solving that pain, the consequences if you don't solve it, your budget, and your authority to make a purchasing decision.

SDRs/BDRs are often compensated by a "meetings set" goal. They may linger on the phone with you if they think you will agree to a meeting with an account exec. But outside of this initial marketing outreach, effective sales people don't want to waste their time with you. Much more so than engineers, they are measured and paid on objective results and specific productivity metrics.

You could sue a hammer manufacturer if they regularly advertised hammers as weapons to children and children started killing each other with them, though.

> how many miles your mouse had moved...

I remember those! Perhaps something like "mouse pedometer?"

The US is large - but roughly 1 in 10 residents live around LA or NYC. As much as it is large, it is also non-uniform.

I feel like the focus on trace/log/metrics terminology is overshadowing Charity's comments on the presentation and navigation tier, which is really where the focus should be in my experience. Her point about making the curious more effective than the tenured is quite powerful.

Observability databases are quickly adopting columnar database technologies. This is well aligned with wide, sparse columns suitable to wide, structured logs. These systems map well to the query workloads, support the high speed ingest rate, can tolerate some about of buffering on the ingest path for efficiency, and store a ton of data highly compressed, and now readily tier local to cloud storage. Consolidating more of the fact table to this format makes a lot of sense - a lot more sense than running two or three separate database technologies specialized to metrics, logs, and traces. You can now end the cardinality miseries of legacy observability TSDBs.

But the magic sauce in observability platforms is making the rows in the fact table linkable and navigable - getting from a log message to a relevant trace; navigating from an error message in a span to a count of those errors filtered by region or deployment id... This is the complexity in building highly ergonomic observability platforms - all of the transformation, enrichment, and metadata management (and the UX to make it usable).

While cost of food (as a percentage of income) has declined significantly, hunger is a real issue in the US and shouldn't be downplayed.

Currently, in the US, there an estimated 40M people and 13M children at risk or experiencing hunger: https://www.ers.usda.gov/publications/pub-details?pubid=1077...

I think Gates has given away ~$50B - which would seem to be enough to tip the scales? I'd rather compare the billionaires by what they redistribute vs. the size of their hoard.

Who is ultimately responsible, though when data is stolen in this fashion? The analyst who ETL'd this to Snowflake without MFA enabled? Or maybe the employee who inadvertently installed a data sniffer that captured usernames and passwords? Really want to send your coworkers to jail for falling for a phishing attack?

If you want corporate-death-sentence level fines, are you willing to work in environment with exceedingly strict regulatory oversight? Will you work from an office where the computing infrastructure is strictly controlled? Where you can't bring personal devices to work? Where you have no privileges to alter your work station without a formal security review?

Why not advocate for more resources to capture and try the actual criminals? Or, as elsewhere in this thread, simply make this kind of data collection illegal?

"Please don't take my job. Take my accountant's job instead."

I wonder if these indexing deals will become more antitrust evidence.

If you don't mean to say that trans people exist as a fad, you might edit this comment for clarity.

Looks like shipt/target successfully converted gig work back from a percentage of revenue (percentage of cart value) to a task based rate. Workers lose when they can't capture value proportional to the revenue generation they support, only in proportion to their hours of labor.

I have aphantasia. I don't see / imagine imagery either awake or asleep. So I don't know that my dreaming experience is particularly different from my waking experience in this way.

> If we assume that the problem with self-serve BI is not SQL, but the context and semantics of the data, then it follows that the solution is to teach people about the data they're querying, regardless of interface.

This has been the basic truth of any self-serve BI system I've used.

Even in smallish orgs there are often three steps - the engineer who instruments code/implements a metric, the engineer who builds the ETL pipeline into the underlying BI warehouse, and the person querying that data. So there are minimally three people in potentially three different roles who need a shared specification and understanding.

Also, self-serve BI tools can be surprisingly opaque and their output can be hard to validate/test. So even if you know accurately what data you are querying, testing that your query is what you intend is hard.

Subscription implies that your costs are roughly the same across different usage patterns by different users (otherwise you collect expensive users who under-pay for the resources they consume). Or, that you can tier your subscriptions in a way that makes sense for the bulk of your users.

Usage-based comes with more work in the short-term: more internal metering, controls for bill-shock, observability so users can see usage by billing vector, pricing/marketing work to help users understand their expected costs for different workloads.