We talk a lot about outcomes over outputs and how engineers are supposed to get us over the water, not blindly build a bridge because someone asked for a bridge. But how do you do that in practice?

Swizec's platform provides resources for developers, covering a diverse range of topics such as programming languages, web development frameworks, data visualization techniques, and software engineering best practices. Through tutorials, guides, and coding challenges, Swizec offers hands-on learning experiences and practical insights for developers at all skill levels. Readers can explore  technologies, industry trends, and software development methodologies to enhance their technical proficiency and advance their careers in the tech industry. Additionally, Swizec shares personal anecdotes, career advice, and productivity tips to inspire and motivate aspiring developers on their journey of continuous learning and professional growth.

swizec.com

A practical technique for engineers to build better software: sit with users or support staff and watch them work for an hour. This 'frustration-driven development' approach surfaces hidden bugs, missing features, broken workflows, and misaligned assumptions that would never appear in a ticket or spec. Real examples from three sessions include a missing button that support had been working around for months, a finance team running a multi-hour process across 6 pages in 3 tools, and discovering that adding more info to support tickets wasn't actually the bottleneck. The key insight is to find the biggest levers — often automation or better self-service — rather than patching symptoms.

Watch people work

<p>Idk about that, no one works the same when someone is looking. Thats why code screening processes are so stressful for the majority of developers.</p>


<p>That was a good point about having the developers do the work that they’re looking to automate. Too frequently are devs isolated from the work itself and don’t have a complete understanding of what it takes to accomplish the task (unless there’s a long concerted effort to capture in depth requirements). So there’s often a substantial amount of time revisiting the automation/process afterward, patching the holes or identifying other things that weren’t considered in the tools development.</p>
