tl;dr:The ambiguous zone lies between doing what we are told as engineers and doing what we want. If we are given specs that are missing something obvious, should we ignore what’s missing and do what we’re told? “The most effective developers I've worked with understand this, and are adept navigating this zone. They are curious about the perspectives and needs of other stakeholders, and ask good questions. They push back when things don't make sense, but do so tactfully.”
tl;dr:"There are two projects, both deemed important by the business, and both need a UI developer. Unfortunately, only one UI developer is available. Why not let the UI developer split time across both projects?" Ben explains why this doesn't work using the equation: Productive Time = Total Time - Overhead.
tl;dr:How do we best divvy up responsibilities in an engineering team, given the complexities of modern day technology stacks. Ben argues there are 4 things to consider: (1) Optimizing for productivity, (2) Code quality, (3) Risk of a developer leaving, (4) Developer happiness. Once we know how to weigh each, there are several models to consider: ownership, free-for-all, stewardship and conservatorship, all discussed here.
tl;dr:It pays to cram all the technologies used in a project onto your resume, since that's what job matching algorithms are designed to parse. Ben has designed an interactive resume to present your work in a different way.
tl;dr:Completing a project with some time left, you can do "more, extra or nothing," and "reasonably happy developers distinguish themselves by choosing extra" - providing a small, additional, tangential contribution to the project. If you're building a web form, research input security concerns. This provides a sense of "free will" and adds to your knowledge base.
tl;dr:While the rules of chess are consistent, the rules of software are not. To be an architect, you need to understand the specific "game you're in" - the business drivers, risks, technical constraints, integrations, trade-offs, and so on.