Hacker News new | past | comments | ask | show | jobs | submit | mandevil's comments login

This prevalence is true in the US (and most Western countries I think, though not as certain), is definitely not true in Sub-Saharan Africa (where 75% of the world's HIV+ population lives). Women and girls are more likely to have it in Sub-Saharan Africa. See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10126805/ estimates that over 60% of all new infections in SSA are in women. Parts of that region the HIV+ prevalence rate is above 5%. That is why they are focused on testing that population in that region, they are the most at risk.

60% of new infections are women, yet they had a completely women-only trial?

For the existing HIV-preventing medications we have, such as PrEP, the treatments are much more effective in men than women. It can easily take a month for PrEP to be effective in Assigned Female At Birth folks, but I saw studies during the COVID era that a few days were plenty for Assigned Male At Birth folks. There's some logic to focusing on the cohort that usually has the lowest success rate with these kinds of medication.

The difference in efficacy has to do with the way the body is designed to absorb fluids, and its one of the few areas where hormones and surgery don't make a difference. (A trans guy on HRT with a full set of surgeries generally has male chances of cardiovascular issues, male levels of calorie consumption/muscle-building, etc.)


Slides have two distinct purposes: as a part of a presentation, and separately as a way to learn or review material outside of the presentation. Unfortunately they are at cross-purposes. For accompanying an oral presentation you don't want lots of data, you want a simple clear image that sync with what you are saying, and to change them rapidly. For learning outside the actual presentation, you want rich, detailed slides with lots of data on them, and leave them up for a while so people can absorb the information.

Ideally, we would build two different decks, each optimized for their purpose. But no one has time for that, so people try and do both in one deck, generally going with lots of information except for one or two images keyed to specific jokes. And it makes the whole thing less effective.


I think bullet points capture the worst of both worlds. You have text (which people focus on, rather than on the presenter), but you don't have enough that one could learn from them outside the presentation.

There's a saying that bullet points are called so because they 'kill' a presentation, and I think there's some truth to that.


I think short bullet points are great. That way the audience can take them in quickly (I highlight one at a time to prevent them from reading ahead/behind) without being distracted for more than a fraction of a second. It also helps people to see how many items are being discussed (e.g., "there are three reasons that language X is better than language Y"). For me at least, that makes it easier to remember the reasons, since it functions as a checksum.

Do you mean that full paragraph is better? Strong disagree if so.

Perhaps not full paragraphs, but the phrase-style nature of bullet points has never really helped me understand the material. If there must be text, I would rather see complete sentences on a presentation.

I've used the assertion-evidence framework[0] for presentations[1] before, where the idea is to have a complete sentence at the top of your slide, with images below that illustrate your point.

[0] https://www.assertion-evidence.com/ [1] While these presentations _were_ about engineering, they were more educational than technical in nature.


Ideally you'd have slides purely for presentation, and an accompanying interactive self-contained HTML document for the documentation of the talk.

And nobody wants to do both (or has the incentive to do both). I'll do sorta-both but probably in an informal way--e.g. article that grew out of a talk--or vice versa.

I've been doing annotated versions of my talks for a while, takes. Few hours of extra effort but greatly increases the impact the talk can have: https://simonwillison.net/tags/annotatedtalks/

Maybe it's because I write a lot but I reached the conclusion that if it makes sense to do an article/blog, I should do so rather than speaker notes--which make sense in handing off a presentation to someone else in a company setting but I'm less sold on, in general, as a personal thing.

> Slides have two distinct purposes: as a part of a presentation...

Many years ago I went to a presentation on giving good presentations, focusing on making good slide decks. (It's currently annoying me that I can't remember where this was, even though I can picture the room in my head.)

The presenter had a short example slide deck, and gave a mock technical presentation using it.

The deck had a different, eye-catching background image for each slide, chosen to be noticeable, but not dominate attention, and be well-suited color-wise for any text or images to be placed on top of the background. The presenter suggested that the background image didn't need to have anything to do with the content of the slide, and that it's mainly there for its general visual impact. The slides were not uniformly designed. It wasn't like someone had used a template where the title, text, images, etc. were all in the same or similar places on each slide. The most noticeable part of this was putting the title in different places. This variety was in itself engaging.

The slides themselves were very light on text, and were mostly about presenting charts, graphs, tabular data, or images relevant to the talk. When there was text, the presenter never read the text verbatim (or sometimes even at all); the text there was a jumping-off point to discuss in detail whatever the topic of the slide was. The argument there was that people know how to read, can read in their heads faster than you can read to them out loud, and if you're just going to read slides to them, you don't need to present it and you should instead just email a document for your attendees to read, and skip the presentation entirely.

Finally, the slide deck itself did not have all that many slides. The presenter dwelled on each slide a lot longer than I've seen in most presentations. The slides were more guideposts to mark the overall topics and outline of the presentation, to provide milestones and transitions. For the most part, the presentation could have been done without the slides at all; the slides were there to add visual flair, help keep attention, and (occasionally) prevent data or images that would be easier to understand visually rather than spoken.

Ultimately I found the mock presentation given to be incredibly engaging, much more so than the vast majority of presentations I'd attended before or have attended since, and I remember that the topic wasn't even something that would usually hold my interest so tightly. I very rarely gave/give presentations, but I've tried to take all this to heart when I had the opportunity to do so. I don't think I ever really did the variety-of-background-images thing (honestly, I never enjoyed giving presentations, and treated it as a chore, and never felt motivated enough to find a bunch of suitable background images). But I at least always tried to keep text to a minimum, so the meat of my talk would be in what I was saying out loud. I wouldn't call myself a particularly good presenter or public speaker, but I think my talks were better than they otherwise would have been.

> Slides have two distinct purposes: [...] as a way to learn or review material outside of the presentation

I've come to think that slides aren't very good for this second purpose, and probably shouldn't be. The information density is never going to be high enough, and if it is, that's going to make for a terrible slide during the presentation. I would much rather read a transcript of the talk later, or, better, a detailed summary. If the slides have charts or other data, then sure, it's useful to have those outside of the talk, but those can also be inserted in-line into the transcript or summary.

I get that it's more work to write up a transcript or summary (and I know I myself would probably balk at having to do this), but if you've prepared properly for the presentation, you probably already more or less have something approaching a transcript in your talk notes. Cleaning them up for publication isn't zero effort, of course, but it should be much less work than writing something from scratch.


Handouts and speaker notes are a thing, although people rarely use them both when building presentations and when reviewing them later.

This piece, about a Lawyer with a Ph.D in economics who bounced back and forth between (and often working at the same time) for the Government directly, as a professor at the Antonin Scalia School of Law at George Mason University, and as a private practice lawyer while simultaneously harassing women who are his students into having affairs with him and then getting them jobs in one of the many places he works so they will be quiet (and he can continue to threaten their livelihood) is bad for one's blood pressure.

His house of cards ends up collapsing because he gets one of the women a fellowship at a different university, that was supposed to be paid by Meta and Google (who used Wright as a lawyer to ward off Government anti-trust challenges) and the money never actually got to her- apparently because of an administrative mistake at the tech giants. So after months of her not getting any money she files a Title IX complaint with his university and the end result is he loses all of his jobs, all but one of his mistresses (he is apparently engaged to one of them!), and his wife.

Just a real piece of excrement all the way around.


“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”- Donald Knuth, The Art of Computer Programming


Sadly, this no longer really applies. Programmers today do absolutely grotesque things unimaginable to Knuth of that era. One look at any modern pipeline that converts to and from JSON a dozen times, sometimes even inside the same process between modules, would make Knuth recall all of that.

Programmers now have done the impossible: written code so consistently bad that there are no hotspots, because the whole codebase is non-performant trash.


I was going to get a t-shirt printed with “Knuth Was Wrong”

We’re going to be in a world of hurt when the newest process node doesn’t save us.


Knuth was right! Profiling would indicate whether your JSON serialization/deserialization is actually a problem. Maybe it is. Maybe it isn't.


There's key parts left out of that quote that changes the tone quite a bit. Here is the full one

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Donald Knuth


Knuth was writing in an era when scientific programs tended to be dominated by inner loops. There was an input part, a compute part that did some number-crunching, and an output part. Only performance in the compute part mattered.

Many programs today have no inner loop. Compilers were the first important programs that didn't. Most interactive programs have an outer loop processing events, rather than an inner compute loop.

Note that "AI" programs are much more like the scientific problems of Knuth's era. All the compute is in tight loops wrangling matrices.


Well the last time the thread thing bit me was actually a case where it wasn't premature optimization; I had written the code in such a way that I thought was pretty enough, and we were hitting bottlenecks, so my genius brain thought "ok I'll make this use 20 threads and it'll go faster". It did not.


Pretty sure I’ve made exactly the same mistake. I feel like everyone who ever writes concurrent code learns that lesson at some point. It’s absolutely astonishing how much mileage one can get out of thread-per-core-fed-by-work-queues architectures.


Oh with modern architectures this sentence is so wrong. If you don't think about grooming the hardware in the right way from the get go you will never touch peak performance by a couple orders of magnitudes period. See how games are developed and I tell you they don't just use OOP with virtual interfaces and neat indirections all over the place then think oh it is ok we will optimize after the fact.


Every third person who comes in has their router hacked, that's the problem. We know that Sam is good at what he does and to not be wrong about this, but Cox can't rely on everyone being that good, nor on their very poorly paid front-desk worker to have the ability to tell if they are an idiot or a expert.

Source: was a volunteer front-desk person at a museum. Spent a lot of my life dealing with people. They were sure of incorrect things all the time and could not be relied on to know.

In retrospect, Sam should definitely have hit the responsible disclosure page (if such a thing even existed in 2021) but I don't fault anyone for the choices they made here.


I think it is quite possible that NVidia's customers[1] are the ones selling hot air. If those customers go away then it turns out that NVidia made legitimately huge profits today, but it was still based on hot air, and their future profits are much smaller just of necessity. It is possible that someone will figure out a good monetization for LLM's, but I'm not aware of any existing yet, which is why I think this is a possible outcome. At least figure out monetization soon enough and with enough free cash flow thrown off that the business case closes with fancy, super expensive accelerators rather than just regular CPU's, which will Moore's Law up eventually.

NVidia is getting rich following the old "in a gold rush, be the ones selling picks and shovels" aphorism, and when the gold rush ends, you still have your money, but the discounted future profits might well be much smaller than you expected.

1: I don't think it would necessarily hurt NVidia, but I do think it might hurt their suppliers. I would be very curious as to how much of the current fab boom across TSMC, Intel, United Micro, Samsung etc. is based on assumptions about AI demand continuing to grow. Those companies would be the ones I would expect to suffer if the demand doesn't materialize because those fabs are going to be ridiculously expensive if they don't keep their order books full.


Semiconductors are a cyclical industry. Undersupply followed by oversupply. Boom and bust. Feast and famine. But demand for semiconductors has gone up, albeit cyclically, for 6 decades. Not a trend I would bet against.

Every car will get AI chips, every laptop, every server, every phone, and many home appliances. And I expect people will eagerly upgrade their electronics to get the faster AI chips in the decade to come.


Will it be a AI accelerator chip or just a regular CPU, which after X number of years of Moore's Law development will be as powerful as a H100 is today? Can you charge that much extra for it in X years, if you are NVidia?

At a certain point the AI chip market disappears and it's absorbed into general purpose computing.


For comparison, in the first dotcom boom, Sun and Cisco did extremely well as infrastructure providers, and subsequently suffered disproportionately.


I just love the sound of goalposts moving in the morning! First it was "Sam will never be charged with it because of his donations!" then it was "Sam will never be convicted because of his donations!" now its "A conviction of 25 years (where the average convict serves 85% of their sentence) is a sign of the power of his donations!"

Please provide evidence from your detailed understanding of Chapter 5 for why a life sentence was so certain?


Half a dozen years ago in a conference talk, Joel Spolsky claimed credit for inventing these sorts of whiteboard interviews (with his Guerilla Guide to Interviewing), and that it had broken software engineering hiring.

https://thenewstack.io/joel-spolsky-on-stack-overflow-inclus...


FTA:

“I think you need a better system, and I think it’s probably going to be more like an apprenticeship or an internship, where you bring people on with a much easier filter at the beginning. And you hire them kind of on an experimental basis or on a training basis, and then you have to sort of see what they can do in the first month or two.”

Well, if he fucked it up, I don’t see any reason why his ideas can’t also fix it.


Unfortunately this only works for interns and new grads. Nobody experienced want to take a job on an experimental basis.


Fortunately people with experience have resumes and are easier to tell if they're bsing their resume.

Fuck man, people do this with engineers who work on classified projects. You all are over thinking it. You're trying to hyper optimize for a function that is incredibly noisy and does not have optimal solutions.


And how would it scale to a number of candidates greater than one? A classroom full of competing peers? That's what talent shows are for.


Aren't probationary periods pretty standard, in many/all industries and countries too not just software?


Yes and such a system makes hiring so much easier because mistakes cost much less. But the US ties things like healthcare to employment so a company that has a reputation for firing people after hiring them (however legitimate) would probably be one people would avoid. In Sweden, for example, I’ve found interviews so much more reasonable. Then again, I had healthcare there regardless of employment.


Oh, I see. I'm in the UK, so more like Sweden; no experience of having healthcare tied to employment (other than optional private healthcare as a perk).


Insurance is a minor issue for vets, essentially none of the population has animal insurance. It's also not a super big deal for dentists, as I understand it, though I don't know as much about the back-end of dental practices (wife is pharmacist, sister-in-law is a vet tech, so I know those businesses pretty well). Insurance reimbursement from the monopoly PBM's (three of them control 80% of the drug insurance market) are what is killing independent pharmacies- you have to be one of the national chains to have the scale to effectively negotiate against the PBM's, otherwise reimbursement rates are routinely below your wholesale price.

From talking to my wife it's not really compliance and government regulation in the pharmacy space (which is far more regulated than the vet space, naturally) that has forced consolidation. For the most part the regulations haven't changed that much in decades. What's changed is heavily reduced insurance reimbursement rates from those monopoly PBM's plus one other factor: educational debt. The idea that our intrepid young vets/pharmacists/dentists/doctors graduate with a huge pile of educational debt (200k or more), then have to take out massively more debt to start up a new business(1), at the same time they are also in prime child-bearing/rearing/caring age, that's a really hard sell for most. That's why being an employee is such an attractive thing.

1: And those loans have to be much bigger than before, because drugs are more expensive so your inventory costs are higher, people want nicer places offering more amenities, etc. They also need to be able to pay off those software licenses, which may not be individually expensive but are another new cost that wasn't present 30 years ago that has to be paid on the reduced reimbursement rates from the PBMs.


According to Wikipedia, at least two of the five founders of Anduril came from Palantir and several of the investors are the same across both companies (probably including Peter Thiel? It's not exactly clear from skimming the wiki). So I suspect that the correct f-verb is not "fight."


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: