655 stories
·
2 followers

Good Low-Tech Design: This Vet Care Meds Chart

1 Comment

Recently I had to take my dog in for surgery. Over nearly 20 years of owning multiple dogs, this isn't new. But this is the first time design actually played a helpful role for my pet's post-op care.

At every other veterinary practice I've been to—over a half-dozen, from Manhattan to the rural countryside—they hand you med vials with the dosage instructions printed on them. The font on the labels is tiny (requiring reading glasses, for me) and it's impossible to read a full sentence without rotating the vial.

This time, however, this new vet handed me this simple chart:

I was really impressed by the low-tech efficacy of the design. The days are delineated by tonal differences, and a pink highlighter was used on all but one of the boxes, to remind me that one of the drugs was not to be administered on the morning of 2/7 (due to lingering medication from the surgery, I was verbally told). Two of the drugs are meant to be administered for 7 days in a row, and the third for 14 days in a row; the vet tech was easily able to modify the chart to indicate this.

All of this information is on the three barely-legible labels on the vials. But by consolidating it into one chart, the vet practice made the information much easier to grasp and track.

I do wonder why, having been to so many vets, this is the first time I'd seen such a chart. It should be standard practice.



Read the whole story
GaryBIshop
12 hours ago
reply
Great idea!
Share this story
Delete

Don’t Bet on the Super Bowl

1 Comment

If you have studied probability, you might be familiar with fractional odds, which represent the ratio of the probability something happens to the probability it doesn’t. For example, if the Seahawks have a 75% chance of winning the Super Bowl, they have a 25% chance of losing, so the ratio is 75 to 25, sometimes written 3:1 and pronounced “three to one”.

But if you search for “the odds that the Seahawks win”, you will probably get moneyline odds, also known as American odds. Right now, the moneyline odds are -240 for the Seahawks and +195 for the Patriots. If you are not familiar with this format, that means:

  • If you bet $100 on the Patriots and they win, you gain $195 – otherwise you lose $100.
  • If you bet $240 on the Seahawks and they win, you gain $100 – otherwise you lose $240.

If you are used to fractional odds, this format might make your head hurt. So let’s unpack it.

Suppose you think the Patriots have a 25% chance of winning. Under that assumption, we can compute the expected value of the first wager like this:

def expected_value(p, wager, payout):
    return p * payout - (1-p) * wager
expected_value(p=0.25, wager=100, payout=195)
-26.25

If the Patriots actually have a 25% chance of winning, the first wager has negative expected value – so you probably don’t want to make it.

Now let’s compute the expected value of the second wager – assuming the Seahawks have a 75% chance of winning:

expected_value(p=0.75, wager=240, payout=100)
15.0

The expected value of this wager is positive, so you might want to make it – but only if you have good reason to think the Seahawks have a 75% chance of winning.

Implied Probability

More generally, we can compute the expected value of each wager for a range of probabilities from 0 to 1.

ps = np.linspace(0, 1)
ev_patriots = expected_value(ps, 100, 195)
ps = np.linspace(0, 1)
ev_seahawks = expected_value(1-ps, 240, 100)

Here’s what they look like.

plt.plot(ps, ev_patriots, label='Bet on Patriots')
plt.plot(ps, ev_seahawks, label='Bet on Seahawks')
plt.axhline(0, color='gray', alpha=0.4)

decorate(xlabel='Actual probability Patriots win',
        ylabel='Expected value of wager')
_images/48c1402d18913b4e4a43f62a11e1f6206cac36ff426a02adefd811caa7714e50.png

To find the crossover point, we can set the expected value to 0 and solve for p. This function computes the result:

def crossover(wager, payout):
    return wager / (wager + payout)

Here’s crossover for a bet on the Patriots at the offered odds.

p1 = crossover(100, 195)
p1
0.3389830508474576

If you think the Patriots have a probability higher than the crossover, the first bet has positive expected value.

And here’s the crossover for a bet on the Seahawks.

p2 = crossover(240, 100)
p2
0.7058823529411765

If you think the Seahawks have a probability higher than this crossover, the second bet has positive expected value.

So the offered odds imply that the consensus view of the betting market is that the Patriots have a 33.9% chance of winning and the Seahawks have a 70.6% chance. But you might notice that the sum of those probabilities exceeds 1.

p1 + p2
1.0448654037886342

What does that mean?

The Take

The sum of the crossover probabilities determines “the take”, which is the share of the betting pool taken by “the house” – that is, the entity that takes the bets.

For example, suppose 1000 people take the first wager and bet $100 each on the Patriots. And 1000 people take the second wager and bet $240 on the Seahawks.

Here’s the total expected value of all of those wagers.

total = expected_value(ps, 100_000, 195_000) + expected_value(1-ps, 240_000, 100_000) 
plt.plot(ps, total, label='Total')
plt.axhline(0, color='gray', alpha=0.4)

decorate(xlabel='Actual probability Patriots win',
        ylabel='Total expected value of all wagers')
_images/4cbfc771ae7a96120417d15491ffc998549738a707551c824a63cfbaa12536b4.png

The total expected value is negative for all probabilities (or zero if the Patriots have no chance at all) – which means the house wins.

How much the house wins depends on the actual probability. As an example, suppose the actual probability is the midpoint of the probabilities implied by the odds:

p = (p1 + (1-p2)) / 2
p
0.31655034895314055

In that case, here’s the expected take, assuming that the implied probability is correct.

take = -expected_value(p, 100_000, 195_000) - expected_value(1-p, 240_000, 100_000) 
take
14244.765702891316

As a percentage of the total betting pool, it’s a little more than 4%.

take / (100_000 + 240_000)
0.04189636971438623

Which we could have approximated by computing the “overround”, which is the amount that the sum of the implied probabilities exceeds 1.

(p1 + p2) - 1
0.04486540378863424

Don’t Bet

In summary, here are the reasons you should not bet on the Super Bowl:

  • If the implied probabilities are right (within a few percent) all wagers have negative expected value.
  • If you think the implied probabilities are wrong, you might be able to make a good bet – but only if you are right. The odds represent the aggregated knowledge of everyone who places a bet, which probably includes a lot of people who know more than you.
  • If you spend a lot of time and effort, you might find instances where the implied probabilities are wrong, and you might even make money in the long run. But there are better things you could do with your time.

Betting is a zero-sum game if you include the house and a negative-sum game for people who bet. If you make money, someone else loses – there is no net creation of economic value.

So, if you have the skills to beat the odds, find something more productive to do.

The post Don’t Bet on the Super Bowl appeared first on Probably Overthinking It.

Read the whole story
GaryBIshop
1 day ago
reply
Good advice!
jgbishop
1 day ago
"Folks, when you're right 52% of the time you're wrong 48% of the time." "Why didn't you say that before?!?"
Share this story
Delete

The Forgotten Epidemic Born Out of Poverty

1 Comment

In the early 20th century, scientists sought to get to the bottom of a mysterious disease that caused thousands of deaths per year in the United States. By 1912 in South Carolina alone, more than 30,000 cases were reported with a fatality rate of 40 percent.

Nautilus Members enjoy an ad-free experience. Log in or Join now .

This ailment is known as pellagra, and it was discovered as early as the 18th century when it inflicted Spanish peasants. At the time, it was commonly confused with leprosy as it can cause skin sores. The condition also triggers symptoms throughout the body including diarrhea, neurological issues like tremors, and even dementia. In 1869, Italian criminologist Cesare Lombroso suggested that pellagra comes from spoiled corn, as it often affects people with corn-heavy diets.

Lombroso’s theory entered the conversation when pellagra became epidemic throughout the Southern U.S. Some eugenicists suggested that it stemmed from racial or hereditary factors. A 1912 investigation of a South Carolina mill village reported that the disease was infectious, a finding that guided doctors for years.

ADVERTISEMENT
Nautilus Members enjoy an ad-free experience. Log in or Join now .
DISEASE DETECTIVE: Joseph Goldberger went against the grain and helped the U.S. combat a devastating disease. Photo courtesy of Wikimedia.

Around this time, Congress asked the Surgeon General to investigate pellagra. He tapped Joseph Goldberger, a medical officer in the U.S. Public Health Service, to take the reins. Goldberger was already recognized for his work on epidemics such as typhus and yellow fever.

Goldberger suspected that the disease was linked to a diet lacking key nutrients, not infection—a possibility also raised by researchers in Europe. In the early 20th century, low-income people in the South mostly ate cornmeal, meat, and molasses. Due to the region’s thriving cotton industry, little land remained to grow vegetables.

ADVERTISEMENT
Nautilus Members enjoy an ad-free experience. Log in or Join now .

It was already known that wealthy people were far less likely to develop pellagra, and Goldberger had observed the condition among patients and residents at the mental hospitals and orphanages he visited, yet not the staff. 

Following his intuition, he carried out an experiment on male inmates at a Mississippi prison that began on this day in 1915. These men received pardons for their participation, an unethical exchange that wouldn’t be approved today. He observed how they fared on their usual diet, which included dairy products and vegetables grown at the farm they worked at, versus a typical Southern diet at the time. Eleven subjects stayed on this diet until late October 1915, six of whom experienced pellagra symptoms. “I have been through a thousand hells,” one participant remarked. All of these individuals eventually recovered.

Read more: “Fruits and Vegetables Are Trying to Kill You

ADVERTISEMENT
Nautilus Members enjoy an ad-free experience. Log in or Join now .

Goldberger had also studied populations at orphanages and asylums in the South, and came to the conclusion that an unbalanced diet can trigger pellagra. In fact, some asylum patients with dementia saw such drastic improvements on an improved diet that they were discharged.

Still, Goldberger’s advice mostly went unheeded. Southern politicians and doctors tended to reject his theory linking the condition to poverty in their region, insisting pellagra was an infectious disease or that it stemmed from moldy corn. This prompted Goldberger to organize “filth parties,” where people took pills containing skin, urine, and other samples taken from individuals with pellagra, yet attendees didn’t go on to develop the condition. 

Despite Goldberger’s breakthroughs, he couldn’t pinpoint the exact ingredient required to prevent pellagra. In 1927, he found that a daily dose of brewer’s yeast offered an effective treatment, and a year later he asserted that pellagra likely results from a vitamin deficiency. The next year, though, pellagra reached its peak in the South and killed nearly 7,000 people.

ADVERTISEMENT
Nautilus Members enjoy an ad-free experience. Log in or Join now .

Before Goldberger could get to the bottom of it, he died from kidney cancer in 1929. But less than a decade later, scientists landed on that specific vitamin: niacin. Biochemist Conrad Elvehjem arrived at this discovery after administering small amounts of niacin to dogs with the canine equivalent of pellagra, and the treatment ended up working for humans, too. Corn does contain niacin, but in a form that our bodies can’t absorb well—Indigenous people in the Americas have rendered niacin easier to digest for centuries by soaking corn kernels in limewater.

Today, pellagra is rare in many countries thanks to flour fortified with niacin, a practice that ramped up in the U.S. during World War II. It’s considered a massive public health success story, effectively wiping out one of the most devastating nutritional deficiency diseases ever documented in the country.

Enjoying  Nautilus? Subscribe to our free newsletter.

ADVERTISEMENT
Nautilus Members enjoy an ad-free experience. Log in or Join now .

Lead image: hartono subagio / Pixabay

Read the whole story
GaryBIshop
4 days ago
reply
Nixtamalization is the key step Europeans failed to learn.
Share this story
Delete

Lessons Learned Shipping 500 Units of My First Hardware Product

1 Comment

Building in consumer hardware as a software engineer

1 year ago (Jan 2025) I quit my job as a software engineer to launch my first hardware product, Brighter, the world’s brightest lamp. In March, after $400k in sales through our crowdfunding campaign, I had to figure out how to manufacture 500 units for our first batch. I had no prior experience in hardware; I was counting on being able to pick it up quickly with the help of a couple of mechanical/electrical/firmware engineers.

The problems began immediately. I sent our prototype to a testing lab to verify the brightness and various colorimetry metrics. The tagline of Brighter was it’s 50,000 lumens — 25x brighter than a normal lamp. Instead, despite our planning & calculations, it tested at 39,000 lumens causing me to panic (just a little).

So with all hands on deck, in a couple of weeks we increased the power by 20%, redesigned the electronics to handle more LEDs, increased the size of the heatsink to dissipate the extra power, and improved the transmission of light through the diffuser.

alt

This time, we overshot to 60,000 lumens but I’m not complaining.

Confident in our new design I gave the go ahead to our main contract manufacturer in China to start production of mechanical parts. The heatsink had the longest lead time as it required a massive two ton die casting mold machined over the course of weeks. I planned my first trip to China for when the process would finish.

alt

Simultaneously in April, Trump announced “Liberation Day” tariffs, taking the tariff rate for the lamp to 50%, promptly climbing to 100% then 150% with the ensuing trade war. That was the worst period of my life; I would go to bed literally shaking with stress. In my opinion, Not Cool!

alt

I was advised to press forward with manufacturing because 150% is bonkers and will have to go down. So 2 months later in Zhongshan, China, I’m staring at a heatsink that looks completely fucked. Due to a miscommunication with the factory, the injection pins were moved inside the heatsink fins, causing the cylindrical extrusions below. I was just glad at least the factory existed.

alt
alt

I returned in August to test the full assembly with the now correct heatsink. At my electronics factory as soon as we connect all the wiring, we notice the controls are completely unresponsive. By Murphy’s Law (anything that can go wrong will go wrong), I had expected something like this to happen, so I made sure to visit the factory at 10am China Standard time, allowing me to coordinate with my electrical engineer at 9pm ET and my firmware engineer at 7:30am IST. We’re measuring voltages across every part of the lamp and none of it makes sense. I postpone my next supplier visit a couple days so I can get this sorted out. At the end of the day, we finally notice the labels on two PCB pins were swapped.

With a functional fully assembled lamp, we OK mass production of the electronics.

Our first full pieces from the production line come out mid October. I airship them to San Francisco, and hand deliver to our first customers. The rest are scheduled for container loading end of October.

alt
Wesley, CEO of Aragon.ai

Early customers give some good reviews:

alt
alt

People like the light! A big SF startup orders a lot more. However, there is one issue I hear multiple times: the knobs are scraping and feel horrible. With days until the 500 units are loaded into the container, I frantically call with the engineering team and factory. Obviously this shouldn’t be happening, we designed a gap between the knobs and the wall to spin freely. After rounds of back and forth and measurements, we figure out in the design for manufacturing (DFM) process, the drawings the CNC sub-supplier received did not have the label for spacing between the knobs, resulting in a 0.5mm larger distance than intended. Especially combined with the white powder coating which was thicker than the black finish, this caused some knobs to scrape.

alt
old knobs (too big)
alt
fixed knobs

Miraculously, within the remaining days before shipment, the factory remakes & powder coats 1000 new knobs that are 1mm smaller in diameter.

The factory sends me photos of the container being loaded. I have 3 weeks until the lamps arrive in the US — I enjoy the time without last minute engineering problems, albeit knowing inevitably problems will appear again when customers start getting their lamps.

alt
alt

The lamps are processed by our warehouse Monday, Dec 12th, and shipped out directly to customers via UPS. Starting Wednesday, around ~100 lamps are getting delivered every day. I wake up to 25 customer support emails and by the time I’m done answering them, I get 25 more. The primary issue people have is the bottom wires are too short compared to the tubes.

alt

It was at this point I truly began to appreciate Murphy’s law. In my case, anything not precisely specified and tested would without fail go wrong and bite me in the ass. Although we had specified the total length of the cable, we didn’t define the length of cable protruding from the base. As such, some assembly workers in the factory put far too much wire in the base of the lamp, not leaving enough for it to be assembled. Luckily customers were able to fix this by unscrewing the base, but far from an ideal experience.

There were other instances of quality control where I laughed at the absurdity: the lamp comes with a sheet of glass that goes over the LEDs, and a screwdriver & screws to attach it. For one customer, the screwdriver completely broke. (First time in my life I’ve seen a broken screwdriver…) For others, it came dull. The screwdriver sub supplier also shipped us two different types of screws, some of which were perfect, and others which were countersunk and consequently too short to be actually screwed in.

alt
alt
alt

Lessons Learned

1. Plan way, way more.

Coming from software, the most planning you’re exposed to is linear tickets, sprints, and setting OKRs. If you missed a deadline, it’s often because you re-prioritized, so no harm done.

In hardware, the development lifecycle of a product is many months. If you mess up tooling, or mass produce a part incorrectly, or just sub-optimally plan, you set back the timeline appreciably and there’s nothing you can do but curse yourself. I found myself reaching for more “old school” planning tools like Gantt charts, and also building my own tools. Make sure you have every step of the process accounted for. Assume you’ll go through many iterations of the same part; double your timelines.

In software, budgeting is fairly lax, especially in the VC funded startup space where all you need to know is your runway (mainly calculated from your employee salaries and cloud costs).

With [profitable] hardware businesses, your margin for error is much lower. Literally, your gross margin is lower! If you sell out because you miss a shipment or don’t forecast demand correctly, you lose revenue. If you mis-time your inventory buying, your bank account can easily go negative. Accounting is a must, and the more detailed the better. Spreadsheets are your best friend. The funding model is also much different: instead of relying heavily on equity, most growth is debt-financed. You have real liabilities!

2. Overcommunicate. Overspecify. Follow Up.

Anything that can go wrong will go wrong. Anything you don’t specify will fail to meet the implicit specification. Any project or component not actively pushed will stall. At previous (software) companies I’ve worked at, if someone followed up on a task, I took it to mean the task was off track and somebody was to blame. With a hardware product, there are a million balls in the air and you need to keep track of all of them. Though somewhat annoying, constant checkins simply math-out to be necessary. The cost of failure or delays is too high. Nowadays as a container gets closer to shipment date, I have daily calls with my factories. I found myself agreeing with a lot of Ben Kuhn’s blog post on running major projects (his blog post on lighting was also a major inspiration for the product).

3. Test everything, often, on many units

When I worked at Meta, every PR had to be accompanied with a test plan. I took that philosophy to Brighter, trying to rigorously test the outcomes we were aiming for (thermals, lumens, power, etc…), but I still encountered surprising failures. In software if you have coverage for a code path, you can feel pretty confident about it. Unfortunately hardware is almost the opposite of repeatable. Blink and you’ll get a different measurement. I’m not an expert, but at this point I’ve accepted the only way to get a semblance of confidence for my metrics is testing on multiple units in different environments.

4. Geopolitics matter

As someone who generally stays out of politics, I didn’t know much about the incoming administration’s stance towards tariffs, though I don’t think anyone could have predicted such drastic hikes. Regardless, it’s something you should be acutely aware of; take it into consideration when deciding what country to manufacture in, make sure it’s in your financial models with room to spare, etc…

5. Visit your suppliers early

I wish I had visited my suppliers much earlier, back when we were still prototyping with them. Price shouldn’t be an issue — a trip to China is going to be trivially cheap compared to buying inventory, even more so compared to messing up a manufacturing run due to miscommunication. Most suppliers don’t get international visitors often, especially Americans. Appearing in person conveys seriousness, and I found it greatly improved communication basically immediately after my first visit. Plus China is very different from the US and it’s cool to see!

What Did I Do Right?

To me, this process has felt like an exercise in making mistakes and learning painful lessons. However, I think I did do a couple of key things right:

1. Validated the market

The first thing I did before starting manufacturing—and even before the crowdfunding campaign—was setting up a simple website where people could pay $10 to get a steep discount off the MSRP. Before I committed time and money, I needed to know this would be self-sustaining from the get go. It turns out that people were happy to give their email and put down a deposit, even when the only product photos I had were from a render artist on fiverr!

2. Charged a sustainable amount

From talking to other hardware founders, these kinds of mistakes happen to everyone; hardware is hard as they say. It’s important to have a healthy enough business model to stomach these mistakes and still be able to grow.

Coolest Cooler had an incredibly successful crowdfunding campaign, partly because they packed a lot of features into a very attractively priced product. Unfortunately, it was too attractively priced, and partway through manufacturing they realized they didn’t have enough money to actually deliver all the units, leading to a slow and painful bankruptcy.

3. Prioritized customer support

When the first 500 units were being delivered, I knew there were bound to be issues. For that first week, I was literally chronically on my gmail. I would try to respond to every customer support issue within 1-2 minutes if possible (it was not conducive to my sleep that many of our customers were in the EU).

Some customers still had some issues with the control tube knobs & firmware. I acknowledged that they were subpar and decided to re-make the full batch of control tubes properly (with the correct knob spacing), as well as updated firmware & other improvements, and ship them to customers free of charge.

Overall, it’s been a very different but incredibly rewarding experience compared to working as a software engineer. It’s so cool to see something I built in my friends houses, and equally cool when people leave completely unprompted reviews:

alt
alt
alt

Adblock test (Why?)

Read the whole story
GaryBIshop
5 days ago
reply
He's only done software but believes picking up hardware skills will be easy. The EE's at SUN assumed mechanical engineering was easy; they built some terrible cooling systems.
Share this story
Delete

PyBites: The missing 66% of your skillset

1 Comment

Bob and I have spent many years as Python devs, and 6 years coaching with Pybites and we can safely say that being a Senior Developer is only about 1/3 Python knowledge.

The other 60% is the ecosystem. It’s the tooling. It’s all of the tech around Python that makes you stand out from the rest.

This is the biggest blind spot keeping developers stuck in Tutorial Hell. You spend hours memorising obscure library features, but you crumble when asked to configure a CI/CD pipeline. (That’s not just made up by the way – many of you in dev roles will have seen this with colleagues at some point or another!)

These are the elements of the Python ecosystem you should absolutely be building experience with if you want to move from being a scripter to an engineer:

  • Dependency Management: Stop using pip freeze. Look at uv.
  • Git: Not just add/commit. Learn branching strategies and how to fix a merge conflict without panicking.
  • Testing: print() is not a test. Learn pytest and how to write good tests.
  • Quality Control: Set up Linters (Ruff) so you stop arguing about formatting, and ty for type checking.
  • Automation: Learn GitHub Actions (CI/CD). Make the robots run your tests for you.
  • Deployment: How does your code get to a server? Learn basic Docker and Cloud.
  • The CLI: Stop clicking buttons and get comfortable in the terminal. Learn Makefiles and create a make install or make test command to save your sanity.

It looks like a lot. It is a lot. But this is the difference between a hobbyist and a professional.

Does this make you feel overwhelmed? Or does it give you a roadmap of what to do this year?

I’m curious! Feel free to hit me up in the Community with your thoughts.

And yes, these are all things we coach people on in PDM. Use the link below to have a chat.

Julian

This note was originally sent to our email list. Join here: https://pybit.es/newsletter

Read the whole story
GaryBIshop
13 days ago
reply
Good advice.
Share this story
Delete

Saturday Morning Breakfast Cereal - Unified

2 Comments and 4 Shares


Click here to go see the bonus panel!

Hovertext:
10 points to anyone who tries this argument in real life.


Today's News:
Read the whole story
GaryBIshop
19 days ago
reply
Love this!
Share this story
Delete
1 public comment
jlvanderzwan
18 days ago
reply
The fun bit is that a large number of big names in biology these days are physicists who jumped ship because they realized physics was hitting a wall, and biologists are still naive about how to process big data.
Next Page of Stories