How to be a problem solver?
summary
Argues that being a problem solver means using concrete frameworks not buzzwords: adopt LNO (leverage/neutral/overhead) to prioritize work, keep an in-team working agreement document, write RFCs with a recommendation matrix and milestones, and use an engineering daybook and closure documents to reduce technical debt. Gives a finance example: 2,000 partner users would cost ~$1M, 50% unused, so prune every 3 months or opt for managed access. Emphasizes test quality (accuracy, speed, reliability) and starting with quick wins.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:52Problem-solving for developers
- 2:35Business needs and stakeholders
- 8:51Time management
- 15:16Context in legacy and greenfield
- 22:28RFCs and recommendation matrices
- 37:37Continuous learning
- 42:15Influence and impact
- 50:25Soft skills and feedback
- 56:09Closing thoughts
