(this was in my drafts, but didn't go out!) Final (non-lightning) talk of the day, @MaggieFero explains the importance of good documentation practice, regardless of who is reading it. #pybeach #pybeach2026
Search
53 results for “MaggieFero”
-
RE: https://mastodon.social/@RonJeffries/117502908774333109
Yesterday at #pybeach, I mentioned that a relatively common AI tooling error is reversing negation... here's an example 😅
(Thanks for sharing it, @ronkjeffries !)
-
Now @kattni can edit circuitpython instructions on a phone
-
PyScribBLE is @kattni 's Bluetooth Low Energy package supported by toga-code-editor (with syntax highlighting) and toga-console to run beeware on a tiny hardware device!
-
In closing his #pybeach talk, @andrew informs us all that mountain rescue in the US is always free, and they'd rather be called sooner than later if you think you might need it.
As a security professional, please also notify us sooner than later if something feels weird, whether you clicked a link that felt wrong in retrospect or a process is suddenly taking an unexpected length of time. Most of us wanna help!
-
-
-
-
-
CW: discussion of peril
Practice incident response, and practice it proportionate to how often that type of incident occurs (with some extra reps on higher-risk areas).
Leave time in your schedule for problems to happen! If you're scheduled 100% of the time, you have no margin of error.
Try to move slowly and steadily, with small, frequent releases. Big jumps are riskier.
Have a safety culture: blameless is good, but also every single person must be able to call stop and *actually* cause an evaluation. That's not to say you should never tolerate risk, but that you should consider it carefully.
-
CW: discussion of peril
In software, we can limit the scope of what we collect, by not creating user data unnecessarily, for example. Also, we have the opportunity to cheaply roll back our mistakes. They're not literally set in stone like some other disciplines' mistakes may be.
In mountain rescue, if there's a problem with a rope system for example, someone may already be over the edge and fully dependent on it, so you can't fix that. - @andrew @ #pybeach
-
-
CW: discussion of peril
Andrew also introduces the risk matrix: likelihood of occurring and severity of consequences if it occurs. In mountain rescue, you're guaranteed high consequences and that it's dangerous (you didn't get called out to have tea).
We also have risk in our codebases, but we can likely impact both the likelihood and the consequences, using some of the same levers that mountain rescue teams use. - @andrew @ #pybeach
-
CW: discussion of peril
Search and rescue doesn't use the helicopter as often as you'd think; it's more common to hike out and get someone. They do search (looking for someone missing), rescue (helping someone who needs it, whose location is known), and recovery (retrieving deceased people from the field).
For mountain rescue specifically, you also describe by angle: flatland (no ropes), low angle (you need a rope, but it's not holding full weight), and high angle (your full weight is on a rope, like a rappelling example we saw). - @andrew #pybeach
-
-
Finally, @coderanger reminds #pybeach to be kind, to ourselves and others
-
Some of the ways we trust code review require hypervigilance, which leads to burnout. Hypervigilance also leads to cognitive overload, because you only have but so many things you can keep track of. - @coderanger at #pybeach
-
When we explicitly declare the purposes of our code review and choose specific smaller bits to look at, we can keep ourselves from trying to reconstruct the mental state of the developer, which is in turn one of the most effective ways to successfully accomplish large-scale code review. - @coderanger at #pybeach
-
Explicitly declaring types, staying consistent (and trying linters to ensure it), and other automation layers let us save the squishy bits for squishy humans with a nice firm safety net.
Code review can also help, and it's one of the most common ways we often assess each other's code. Code review is a way to reduce defects, but it's also good for team training, architecture consensus, and specialist consultation. HOWEVER, it's easy to miss things; code review isn't great at finding defects! It can also be time-consuming and timing, in a way that gives people a reduced sense of agency. - @coderanger
-
Unit tests are subjective, and so is coverage reporting. Make those decisions deliberately and thoughtfully.
Instead of overall coverage, @coderanger likes patch coverage: what's the difference in test coverage before versus after this change? if it's not enough, get curious about why important-seeming code doesn't look tested. #pybeach
-
Creating a checklist culture, like @coderanger learned as a diver and practices in frequent, repetitive, high stress, or high-impact-of-errors situations, can help us move through processes in a streamlined way and reduce human error. That checklist must be followable, explicit, and shouldn't have a lot of steps people are expected to skip.
You've got to practice that checklist, though! It should be routine by the time it matters.
Finally, checklists must be blameless. Failures after following the checklist are a problem with the process, not the person. #pybeach
-
One of the ways that @coderanger , as a human, is bad at things, is a way we're all bad at things, too! Confirmation bias is a form of cognitive shortcut that can save us time, but can also cause predictable problems.
inattentional blindness is when we remember only what we were paying attention to, and miss something important.
Recency bias causes us to map things to recent events, repetition blindness keeps us from noticing "boilerplate", and overconfidence bias in many forms is SUPER prevalent in tech. #pybeach
-
Oooh, @coderanger is going to tell #pybeach he's bad at things, and why that's okay. We're going to start off with how we fail, move on to where we can improve, and close out on the human cost.
-
Once a vulnerability is found, having an inventory (like an SBoM, software bill of materials) lets you more quickly identify where you might be vulnerable or using the problematic dependency. This can help you get quickly into the remediation work. - @gaborbernat at #pybeach
-
Creating lockfiles is a good protection against new pushes with vulnerabilities, but also ensure that you're subscribed to relevant advisories in case a vulnerability is found in a package that was already released earlier. - @gaborbernat at #pybeach
-
Updates can wait, but security fixes may not! Make sure you know your exception flow for situations where you may need to upgrade a critical dependency before your usual timeline. - @gaborbernat at #pybeach
-
If you think something may have happened to a release, you can rebuild independently from the provided source to verify. Allowing this can give your users confidence in the integrity of your package.
Immutable releases are also helpful, because it's rare to need to rebuild an already-released wheel; you'd normally cut a new release instead. - @gaborbernat at #pybeach
-
Using PyPI's Trusted Publishing lets you decrease the credential exposure risk for your packages, and you can add another layer with file attestation. Attestations live in PyPI itself, and there's an official GitHub action you can use to publish them for a year at a time.
In the December 2024 Ultralytics attack, malicious releases were identifiable by their lack of attestations. - @gaborbernat at #pybeach
-
Any shared cache you restore from is a potential security risk, too, because the cache can be modified by others then is trusted.
Limiting where the build can connect helps you to decrease boundaries, too.
If you're using agents, that adds surface as well: an untrusted actor is using your credentials.
- @gaborbernat at #pybeach
-
You should also watch for keys leaking across boundaries. Minimizing access to keys can decrease that surface area. - @gaborbernat at #pybeach