Software Developer

Developers often know most clearly where the problems are: which components are unsafe, which defaults are dangerous, which defect classes keep reappearing.

Surprisingly, they are also frequently least empowered to act. The decisions that produce unsafe software are usually made upstream: language choices, architecture, velocity targets, technical debt tolerance. But developers have more influence than they often realize, not just in the code they write, but in the questions they ask and the tradeoffs they name out loud.

Discussion prompts

• What recurring defect classes exist in your codebase? Is anyone tracking them systematically, or are they being fixed instance by instance?
• What would it take to change what happens when you raise a security concern that conflicts with a velocity target?
• Who would need to be in the room to approve eliminating a defect class entirely rather than fixing individual instances?