Accidentally in Code

Tag: driyourcareer

  • Announcing: Breaking Into the Security Mindset

    Image credit: Joe Groove

    Application security might seem like a strange thing to build a coaching course about.

    But the thing that makes coaching work is that the person comes out feeling bigger than the problem. That’s useful in many things. It’s especially useful in a field that seems to have been designed to be opaque. We’ve partnered with Halle Winkler to bring you a blend of her security expertise and our coaching mindset, in the DRI async+audio format.

    This is our first partner course, and it gives us an opportunity to bring in another collaborator, with different skills. I’ve learned so much working on this, and I’m so excited to share it with you.

    Halle and I met at an iOS conference years ago. She’s now an offensive security researcher and application security engineer, a Certified Ethical Hacker with twelve Apple security credits. Her CVE proofs of concept include a macOS remote-control camera and a Lock Screen keylogger.

    There’s more talk about application security than there has ever been, which can make it seem more intimidating than ever – but we think it’s an opportunity to get to grips with it. If you’re a product engineer, you probably know more about this than you think you do. You understand systems. You’ve spent years thinking about managing a full range of inputs and all the unexpected states. What’s missing is the vocabulary, a map of the field, and the sense that you’re allowed to do this at all if you didn’t start hacking at thirteen. You are.

    What is Breaking Into the Security Mindset?

    Breaking Into the Security Mindset is an 8-week course for engineers and engineering managers who want to bring security into their engineering and product work. It isn’t magic and it isn’t only for lifelong hackers.

    The course has 4 modules:

    1. Finding Yourself in Security — three personae: you as the defender, adversaries, and who you protect and why. Then threat modelling, the state of the art on both sides, and our ethics and safety practices.
    2. Your Project, Part 1 — build a small offensive research script or agent against a safe synthetic target, using local LLM workflows, and write up a vulnerability report on what you find.
    3. Your Project, Part 2 — research your vulnerability, remediate it, and then how you can adjust your development practices to prevent it being built in the first place.
    4. Bringing It Together — CI/CD and supply chain, secure coding as policy, which shift-left tooling applies to your products, and staying current so you can sleep at night.

    Each module includes:

    • Written content and frameworks, so the jargon is demystified
    • Audio conversations between Halle and me
    • Exercises to apply what you’ve learned to your situation
    • Personal feedback from us on everything you turn in
    • Project work you drive at your own pace

    Plan for around 60 minutes a week. The project is the biggest variable. If it pulls you in, you might blow past that – and your bedtime!

    Why now?

    The agentic era of software development is also the agentic era of vulnerability exploitation. Teams are shipping AI-assisted code at volume, and a lot of people aren’t sure what risk that introduces or how to set guardrails around it. A lot of other people have quietly become the de facto security person on their team without ever deciding to.

    This course is for you if you know security is a gap and it has felt too intimidating to begin. You’ll want to be actively coding, to the extent that building and debugging a small tool is possible for you. It’s not for you if you already work in security and want advanced technique.

    Enrollment is open now.

    Early bird pricing: $599 USD

    Regular pricing: $699 USD

    The course starts October 12th, 2026.

    👉 Learn more

  • Maturing our development process as an AI-first 2 person team

    Credit: Landiva Weber / Pexels

    We’re doing a big release this week for DRI Your Career. Mostly bug fixes and reliability work nobody will notice, but the two things worth mentioning:

    • Audio episodes are now available as a private podcast feed.
    • Made significant progress towards supporting multiple coaches (yes this implies some very exciting announcements – more soon).

    We’ve come a long way since it was just Jean and “Claude the intern”, but mostly very iteratively. We’d come to a point where it seemed worth rethinking. We wanted to ship some bigger things – this release was nearly 100 PRs over about a week, passing back and forth between Ireland and California – and to do that we had to mature our approach.

    1. Release branch and release process (vs pulling from main). I know this goes against conventional wisdom, but for a 2 person team with no on-call SRE, I think it’s better to be able to schedule your problems for a convenient time.
    2. Orchestrator + merge queue. The merge queue tends to be stricter, so everything gets 2 code reviews, follow-ups filed, and so on. It also handles sequencing and rebasing – the things I used to burn CI minutes on when I was chaotically working in 5 tabs.
    3. Board hygiene. P0/P1/P2/P3 issues, aligned with the orchestrator + merge queue setup. Everything related to features slated for the next release gets tagged so it gets prioritised.
    4. Devex and optimisations. Ephemeral DB targets, authenticated E2E tests, env var requirements, a full design system, automated nightly DB backups.

    What I find interesting is that these four pieces map onto four different phases of a team maturing.

    1. Overkill. Slightly anal for two people. But the natural progression for a 2 person team no longer wanting to deploy main on every PR.
    2. The AI-native piece. Only necessary because AI exists – also allows Claude to work overnight whilst we are sleeping (and don’t need the tokens for everything else we are doing).
    3. The setup of a well-organised 6+ person team. What keeps the orchestrator (and us!) focused on impact rather than maxing out token and CI spend. Brought in when I realised we could easily ship >50 PRs but no finished headline feature.
    4. A level I used to watch 20+ person teams struggle to reach. Necessary to support the velocity.

    All of this to say that a sensible setup for a 2-person team has shifted dramatically from even a year ago. If the shift is that big for a small team running a small website on top of other activities, it’s going to be even more dramatic for larger teams. The list above is our specifics, but the categories are transferable: even if your process was right sized for your team before, it isn’t – or shouldn’t be – once each person on your team is running a team of agents.

    1. What is your release process? How do you validate, find issues and monitor?
    2. How do your agents run, what guard rails are in place?
    3. How do you maximize value for token spend?
    4. What’s your DevEx setup and how does it need to evolve?

    Lately I’ve been thinking about the AI shift as upending the standard bottlenecks for team scaling. That’s moved me from “we need a new playbook” to “we need to update the existing one with different priorities”. All but one of these are things I’ve done as part of scaling a team in the before times. I just didn’t used to do them all in a week.

    This is why I stay optimistic about developers even as writing code gets automated. You can’t just “AI it”: getting AI to solve problems faster than it creates them takes judgement. Claude helps enormously in moving things forward, but knowing what to prioritise and what it should be doing is a critical input.

    This is the kind of work good managers do – evolving how the work gets done as the team evolves, to keep things moving. So we’ve decided, again, that we “don’t need managers”, at the exact moment there’s more of that work to do than ever… My hot take from years of experience scaling teams and being deeply immersed in AI-dev for the last 8 months or so? We’ll come back to the same conclusion – managers matter 🍿