If you do use terraform, for the love of god do NOT use Terraform Cloud. Up there with Github in the list of least reliable cloud vendors. I always have a "break glass" method of deploying from my work machine for that very reason.
Off topic, and I don't want to knock the presenter here, but if you're ever going to give a public talk or presentation at work _please_ review the Death By Powerpoint slide deck[0] first.
Thanks for the link. I went through it but I'm not sure what it's telling me to change. Can you elaborate? If it's "be more engaging", i think is unfortunately going to be hard to improve because this is just how i am.
I appreciate your frank oppenness to feedback! I'd like to give you some, but first I want to call out that (1) I'm certainly no expert and (2) you may have been voluntold to make a powerpoint on material that isn't well-fit for powerpoint.
My feedback:
- I think you could improve by being more excited / exciting (the Death By Powerpoint slide deck says "passionate"). Personally, I try to mitigate this problem by drinking coffee shortly before I'm expected to be engaging. It is a drug, and for me it works.
- You could also draw the main impactful points out of the background info. The presentation you give here has a lot of deep technical detail, which is certainly of interest for the correct audience, but I think generally fits poorly in a powerpoint presentation. I think you'd generally want to focus on more high-level performance characteristics, or particularly interesting details. Perhaps a 3-4 page document would be better for this sort of deep technical material. Or maybe the level of detail is actually perfect, and I'm just not the correct audience.
I really love your response here. You seem like a great person, I think your coworkers are lucky to have you.
The presentation was mainly for the audience that was present at the conference, which was mainly people who have used jj for a relatively long time, so I think part of the problem is just a mismatch between audiences there and on YouTube.
I agree about being more exciting. Not sure how to improve that :P I drink too much coffee all the time that I don't notice any difference. Harder drugs, perhaps :)
Which is fair as is not expecting everyone to be able to deliver a barnstorming talk. At least not without training.
I'd also flag that the audio is not good which isn't your fault. The trend towards conferences just pointing a camera at a lectern and throwing the footage on YouTube is unfortunate especially when it replaces circulating the slides as opposed to augmenting them. As a form of archive for attendees to review it works but not as a distribution channel.
I think GP is suggesting using less words on a slide, having visual aids and often, thinking of 2-3 ideas that someone would remember from your presentation. To the first point, if you take more than 1 min on a single slide, you need to split it into more slides.
Also, present things that you are passionate about if you want to make people care about your presentation.
Thanks for presenting. I was a fig lover so this area is interesting to me.
This is a really hard topic since it's hard to understand the significance of the jj contributions without explaining a ton of internal details like Piper, CitC, TAP, blaze, etc. I think you struck a good balance here.
I don't think you need to "be more engaging" or be more passionate, and when people say that, it indicates they aren't engaged, but it's not a useful suggestion of how to improve.
I think the main issue was that on just about every slide, I found myself wanting to read ahead on the slides instead of waiting to listen to you talk. There are a couple factors to this:
1. Impatience. I want to ingest information faster. Believe it or not, the "talk slowly" advice is usually not good for a technical talk with decent acoustics. E.g. listen to a talk by Bryan Cantrill and notice how fast he talks while still being clear. Rehearsal helps, but if you simplify your slides, you can also make them easier to perform. Listen to a random slide in your video and notice how much time is filled with silence or filler words.
2. Scanning the slide because I'm unsynchronized with the speaker. E.g. if everything you say isn't clearly correlated with the content of the slide in a linear way, then I have to scan the slide to attempt to "resychronize" and figure out what bullet you are on. Sometimes presenters don't want to read the bullets verbatim, which makes it difficult to match up the spoken language with the written language, whereas if you said the first word in a bullet, I could quickly seek to that line. Skipping bullets also causes this, especially at the end of a slide, since then I want to try to read all the bullets on a slide ahead of you in case you decide to skip them in the future.
Fewer bullets per slide and fewer words per bullet help with both of these. Aggressively cut or summarize material so you don't have to skip over anything (e.g. instead of listing 6 jj piper commands and only talking about 2, list just 2 and write the number of total commands e.g. "we added 22 subcommands including mail and submit"). Put extra material (if any) in an appendix after the end if you think you might have extra time or want to use it for Q&A. Rehearse until you can belt out what you want to say on each slide without fillers or pauses (and record yourself so you can tell how much you are doing this). When I'm sharing my screen, I actually like to point my mouse cursor at the bullet I'm on so nobody has to guess where we are, but sometimes that's not available.
Your first slides essentially teach the audience how to consume your talk. E.g. a good pattern is if (1) all your bullets are short (2) you read every bullet verbatim, elaborate on that bullet for a bit, and then repeat on the next bullet. If you stick with a pattern like that, then your audience knows how to follow along. Other patterns work too.
I'm sorry this wasn't shorter and I hope it's helpful.
Again, amazing to be seeking feedback (or open to it). I'm at minute 13 (code review management / bookmarks, etc.), and will give my feedback from there:
"SCAR", which I learned as "Situation, Consequences, Actions, Results" but the above essay will let you go deeper.
Bad: "Two people stood up there, said a few words, and then everybody had cake and went home"
Good: "The situation was... it was a beautiful venue, everybody was dressed nicely, there was music, a slow walk. What these two people were doing was going to bond them together for the rest of their life (or until they had an ugly divorce, whichever came first). They gave a great speech that they'd been practicing all morning in the mirror, gave each other a kiss and a ring to seal the deal, then everyone had cake, danced, and went home tired but happy!"
...this is obviously (hopefully!) exaggerated, and there's a whole bunch more fluffery in the 2nd than the first but imagine this:
1) The situation is that google on perforce or git was dog slow and blah blah not designed for the scale of our monorepo, etc.
2) The consequences was reduced development velocity and increased errors in prod b/c people were trying to bypass CI/CD steps b/c everything was so slow
3) We introduced CitC / Cloud Commits, and => {your technical brilliance described here...}
4) ...and the result was butterflies and rainbows, and here's a graph that shows the production incident rates going down and the changelist rates going up after we GA'd `jj` on linux.
5) The End!
As it stands, much of the presentation is #3 but you're not even giving yourself the credit of bragging about how you discovered the problem (challenge) and the cleverness that went in to inventing your solution.
re: bookmarks:
"We often had people mailing around patches -or- Sometimes PR's were tough to review due to ... -or- I've always wanted an easy way to ..."
=> "Without good bookmark support [adoption would suffer|it would be seen as a step back|collaboration wasn't instant|...]"
=> "So I built bookmarks for `jj`, they work like ..., and solves most of the problem"
=> "It's [better|faster|cheaper|quicker|more fun] than [GitHub|Our Old System|getting yelled at by Linus Torvalds|...etc..."
=> "The IMPACT of bookmarks is: ..." => "It IMPACTED the technical bits here: ..." => "The USER IMPACT is: ..." => "...and finally the business gets: ..." => "What a powerful impact!"
I'd _LOVE_ to see you run a breakdown of any kindof arbitrary slide in the deck and post a deconstruction in this format as kindof a practice/workshop.
It's very OK if (at first) it's pretty mechanical! It's just super-helpful to basically "disassemble" what you're trying to talk about in this mechanical way, and then you can take the proper bits and put them back together.
If you just string a bunch of technical details or technical choices together, you're missing the whole "compelling story" that exists. Even if you just "set the stage" with a single "Situation" slide at the beginning, and a single "Results/Impact" slide at the end... each interior "loop iteration" can be easily set up with a short "Challenge/Consequence" & "Action/Detail/Choice"
"Git + Monorepo was yuck!" => [ "Slow FS" + "CitC" ] => [ "Big Checkouts" + "VFS" ] => [ "Branches?" + "Chose `cp $FILES branches/*` ; Feedback?" ] => "JJ has been well accepted and has a bright future, inside and outside of el-goog!"
My target audience were the people at the conference, who are mostly long-term jj users. The topic was "Jujutsu at Google: Architecture and future plans", i.e. explaining how it works and what our plans are at Google. I'm mentioning this because I think what you're suggesting is for a different presentation, more explaining what the advantages of Jujutsu at Google are rather than how it works. My goal was not to sell the solution to this audience because they're presumably already sold on it.
Sorry if this was obvious to you and you're saying that part of my problem was that I should have chosen a different topic and/or target audience (focusing more on potential new users, perhaps).
Not at all! So for example at ~20-25m, you're explaining "the revset engine"
Just basically flip the first two bullet points:
Situation: "Our repo shape can assume: ..."
Consequences: "Non-mainline graphs fit in memory ..."
Actions: "Tada! Revset engine!"
Result: "Monotonic commit numbers"
Impact: "b/c we can sort ranges => unlocks filtering, client-side processing, etc"
(please excuse my poor understanding of the DETAILS of `jj-at-goog` internals, so I'm butchering some of the details of impact, etc).
...another comment mentioned "death by powerpoint". You can still do/make your slides as you're currently doing it, but when you're "done", just move all the text down into the "speakers notes", and focus on providing some illustrations or comparisons for the visual portion.
On the revset, a bunch of it could be helped by "illustrating the impact" or "compare and contrast"
| RevSet | Git-on-ext3 |
+----------------+----------------+
| Indexed | FS-Traversal |
| Working Memory | Disk Cache |
| Strong Server | Local Limits |
| 456 > 123 | $RAND != $RAND |
...etc...
...and in your speakers notes, you can record some of the technical details you want to talk through.
You're so deep in the weeds it's like asking a fish what they think about water (and to clarify: I'm absolutely not meaning this in any sort of insulting way)... it's just that when you're communicating to others, you may have to end up moving "back and forth" or "up and down" ... illustrated: https://www.youtube.com/watch?v=3amL4O8BSAg ... stretching things out so you can see the individual threads then putting them back, or giving them a twist and blending in a new topic.
Because of your intimate familiarity with the inner workings, sometimes in your talk you're describing an inner working (ie: there's 206 bones in the human body!) but there's no context about what makes that better, or worse, or how they're conceptually connected with each other.
On the grand scale, what is the IMPACT you want your talk to have? To put words into your mouth: "We're about to go GA at google, which is a big deal."
How do you get there? Where did you start from? To put words into your mouth: "JJ is solving google-scale problems, and there's _demand_ and _support_ for bringing it about." [that's your situation]
Consequences? Actions? => now you have set the scene for your very same technical deep dives on JJ.
1) Google has big problems, JJ is solving lots of them!
2) The consequences of (jj-solving-them) or (suffering-further-with-git) are: ...
3a) The actions that have helped jj forge ahead (better than git) are: ...
3b) The actions that jj reduces suffering compared to git are: ...
4) ...as a result, we're about to go GA
5) The impact is increased community trust, improved internal development capabilities, etc...
...again: it's _mostly_ about rearranging things, and providing a little bit more context so that what you _are_ presenting hits your audience better. (3a and 3b are kindof what your current presentation was all about... just set it up a little more on how those interact with the larger picture)
Situation: You've done a great technical thing, and are being asked to present more and be an advocate for it (and yourself)
Consequences: ...if people don't understand JJ, there will be less adoption, or people that would be well-served by it won't use it, or won't contribute
Action: ...you're taking feedback on presentation skills, will continue your systematic learning and iterative improvement approach to this tech-adjacent skill
Result: Butterflies! Rainbows! 150% increase in JJ contributors and 5000% increase in JJ adoption... world peace imminent! :-P
<3 ... best of luck, and free free to reach out if you'd like to continue the conversation!
Not parent but I think the link is pretty clear about what they want to say. I haven't got the time to actually watch the full video, but I could tell this is not a great presentation just by randomly clicking at random timestamps. And almost any presentation from Google (technical or not) I watched on YouTube is better than this.
If you really want me to explain it for you, and just one issue:
There are way too many words on your slides.
P.S. You should click that link and go through it again. If you still don't get it, try once more.
If you don't care about the material, why on earth would anybody sit around for 15 minutes/30 minutes/an hour listening to you talk about the material. The sole reason for a presentation over a technical reference buried somewhere is because the presenter wants the audience to care about the thing they're presenting. If that isn't reflected in the presentation, it's not a worthwhile presentation.
But this was a technical presentation at a conference dedicated to the technology in question. A person stumbling across this on HN does not magically make them part of the target audience.
A technical presentation is a still a presentation, as opposed to a reference document. If you want to give someone a block of technical information, you do so in a reference document. You talk in front of a room full of people in order to convince them that this matters enough to bother.
Sure, but I don’t think this is relevant to the comment thread we’re in, which started off by sharing generic advice that mostly applies to TED-style motivational talks or “keynotes” at large conferences etc.
Ugh, I'd prefer people keep passion for the bedroom and just convey information straightforwardly without trying to "sell" it to me.
Adding a false excitement signal to the information is a hindrance to me as a viewer. If you want Tony Robbins then go and see him. If you want an overview of the new product architecture lets keep calm and get on with it.
I disagree, but it doesn’t mean you’re wrong - we might just be looking for different things.
My view is that if you’re going to talk like a bored robot, then I need a transcript or a paper which is much shorter than a talk. I distinctly remember not going to classes at university because the teachers wouldn’t give me anything beyond reading a book aloud. I just read the book at home.
Now, if you’re able to indicate what’s important and not important, what’s interesting and what isn’t , and why you like it , I’ll be delighted to watch your talk.
I think it’s very difficult to be interested in something new if the presenter doesn’t seem to care about it. This is different from something written , where I expect something dry anyway.
The irony the deck presents 3 very different presenters to show that you don't need to be Tony Robbins to be passionate.
If you can't be passionate, don't make it a presentation. Passionate doesn't need to mean over-the-top, but it means speaking on the topic effectively and in a way that reflects believing there's a reason for these people to sit there and listen to you.
No one is forcing people to do presentations, but once you put people in a situation where they're expected to give you their undivided attention for a block of time, those are very reasonable table stakes.
There's always blog posts, articles, mailing lists, HN posts, etc. if you don't believe there's a strong need for people to set aside time consume your information in the form of a presentation.
"passion" here means "be excited about the subject", which usually (neurospicy people exluced naturally) automatically brings up feelings from the speaker in a "this is cool and I want to share it" kind of way.
If I want to listen to someone read a slide deck word for word in a monotone voice, I can have an AI do it. I'd much rather read a blog post at that point though.
I've seen the exact same thing at multiple companies. The teams were always so proud of themselves for being "multi-cloud" and managers rewarded them for their nonsense. They also got constant kudos for their heroic firefighting whenever the system went down, which it did constantly. Watching actually good engineers get overlooked because their systems were rock-solid while those characters got all the praise for designing an unadulterated piece of shit was one of the main reasons I left those companies.
I became one of the founding engineers at a startup, which worked for a little while until the team grew beyond my purview, and no good engineering plan survives contact with sales directors who lie to customers about capabilities our platform has.
> Watching actually good engineers get overlooked because their systems were rock-solid while those characters got all the praise for designing an unadulterated piece of shit
That is the computing business. There is no actual accountability, just ass covering
multi-cloud... any leader that approves such a boondoggle should be labelled incompetent. These morons sell it as a cost-cutting "migration". Never once have I seen such a project complete and it more than doubles complexity and costs.
Eh, the "best practices" that would've prevented this aren't trivial to implement and are definitely far beyond what most engineering teams are capable of, in my experience. It depends on your risk profile. When we had cloud outages at the freemium game company I worked at, we just shrugged and waited for the systems to come back online - nobody dying because they couldn't play a word puzzle. But I've also had management come down and ask what it would take to prevent issues like that from happening again, and then pretend they never asked once it was clear how much engineering effort it would take. I've yet to meet a product manager that would shred their entire roadmap for 6-18 months just to get at an extra 9 of reliability, but I also don't work in industries where that's super important.
Like any company over a handful of years old, I'm sure they have super old, super critical systems running they dare not touch for fear of torching the entire business. For all we know they were trying to update one of those systems to be more resilient last night and things went south.
Cloud Run lets you cap the number of instances when you create a service. So you can just set max_instances to 1 and you never have to worry about a spambot or hug of death from blowing up your budget. I run all my personal sites like this and pay (generally) nothing.
I worked at a Health Tech Silicon Valley company and our clients were healthcare companies. Our job was essentially to delay and put up barriers to care. So before they could see a doctor they would have to call us, go through the computer system, get routed to a phone doctor who would suggest cheaper things than what they really needed, give them a bunch of hoops to jump through before they could really get the thing they needed.
A big part of my job was to re-route people who needed wheelchairs into getting cheaper things. Our clients were United Healthcare, unions, large health insurers.
It sucked working there it was a total hellhole. I quit when they actually defrauded medicare. Their glassdoor reviews were wild. The owners daughter bragged about dating a glassdoor exec and that he would take down all the honest bad reviews for her.
If it’s not up to health insurers to limit healthcare spending, then which organizational role in the healthcare system do you think is appropriate to place this responsibility with?
The sheer amount of overhead induced by insurance is staggering. For example, the sum of the net profits of all insurers represents money extracted from the system without contributing to health. And the amount of time doctors spend documenting patient care over and above what’s medically necessary purely to make insurers happy is time not spent seeing patients. Clinic staff spending hours on the phone each day arguing against denials is wasted money. (Anecdote: an insurer refused to authorize an MRI for a patient until my wife xrayed their damaged tendon, which doesn’t show up on xrays. She had to conduct a useless medical procedure on the patient before they’d pay for one with actual diagnostic value.)
The whole overhead imposed by the useless rent seekers is money not spent on making people healthier.
What do you imagine is the profit margin of a health insurance company?
According to this report by the national association of state regulators, the profit margin of the health insurance industry in 2023 was 3%, or $25 billion.
Compared to over $1T of premiums, and over $4T of total healthcare spending in the US, that doesn't seem "staggering" to me.
Profit margin is the wrong metric in this debate. The person you are replying to is saying that the insurance companies as a whole is a waste, including all the salaries paid to their employees.
Yes. I owned a medical practice. These numbers affected how much money we took home every month, and I know them with far more personal interest than almost anyone else weighing in here.
If I can reliably sell people $1 bills for $1.03, in extremely large quantities, I'll be very, very happy.
Low margin, high volume is very different than low margin, low volume. The Walton family is very pleased with their tiny margins and the wealth it has delivered them.
Health insurance companies do not provide any medical services. They are the middle man between patients and the places/people that actual do provide medical services. So when they deny coverage, they just keep all the premiums paid by the patient. That money is sucked up by the middle man. So you don't need to raise premiums, you need to lower profits at health insurance companies. Every billion they make in profit is a billion paid by patients and not received in services.
You could say the are negative medical services providers as they remove doctors from practicing medicine in order to have the doctors do non-medical insurance coverage work.
> Health insurance companies do not provide any medical services.
This is substantively not true (though literally true at the level of a company, due to separate companies within the Kaier consortium) of the nation’s largest managed core organization, the Kaiser consortium consisting of the Kaiser Foundation health plans and the Kaiser Permanente Medical Groups.
> No when they deny coverage, they just keep all the premiums paid by the patient. That money is sucked up by the middle man. So you don't need to raise premiums, you need to lower profits at health insurance companies.
Something like limiting retained profits at the plan level to a fixed fraction of costs covered, and requiring refund of excess premiums to members?
The solution is to provide the medical services people bought the insurance to cover and not reflexively deny claims counting on at least some people to give up or die.
Irrespective of how healthcare is financed, they are going to do that (well, the government is, it is possible that the government may not be comprised of elected representatives), the question isn’t whether they should, but how many other actors that are neither you nor your doctor should.
You cannot trust your clients. Period. It doesn’t matter if they’re internal or external. If you design (and test!) with this assumption in mind, you’ll never have a bad day. I’ve really never understood why teams and companies have taken this defensive stance that their service is being “abused” despite having nothing even resembling an SLA. It seemed pretty inexcusable to not have a horizontally scaling service back in 2010 when I first started interning at tech companies, and I’m really confused why this is still an issue today.
I fully agree. The rate limits are how you control the behaviour of the clients. My suggestion of leaving caching to the clients, which they may want to do in order to avoid hitting the rate limit.
>why teams and companies have taken this defensive stance that their service is being “abused” despite having nothing even resembling an SLA.
I mean because bad code on a fast client system can cause a load higher than all other users put together. This is why half the internet is behind something like cloudflare these days. Limiting, blocking, and banning has to be baked in.
Something that was drilled into me early in my career was that you cannot expect your cache to be up 100% of the time. The logical extension of that is your main DB needs to be able to handle 100% of your traffic at a moment’s notice. Not only has this kind of thinking saved my ass on several occasions, but it’s also actually kept my code much cleaner. I don’t want to say rate limiters and circuit breakers are the mark of bad engineering, butttt they’re usually just good engineering deferred.
Reminds me of gas plumbing, the indoor lines are only a few psi above ambient, but the lines themselves have to take line pressure to 300psi is case the regulator fails. It's good advice!
You can never trust clients to behave. If your goal is to reduce infra cost, sure, rate limiting is an acceptable answer. But is it really that hard to throw on a cache and provision your service to be horizontally scalable?
Scaling matters, but why pay for abusive clients or bots? Adding a cache is easy; the hard part is invalidation, sync, and thundering herd. Use it if the product needs it, not as a band-aid.
reply