Team Lead & Developer Resources
Many of these are aimed specifically at team leads, but there are more general articles as well. If you're a lead, you will probably also want to have a look at the Engineering Manager resources, particularly if you're leading a large team or multiple teams.
- Getting Toasty: Observations on Burnout - If you're overwhelmed, depressed, or burned out, ask for help. Everyone else has been there too.
- Global IT Burnout Index - Another good set of resources and a quick check of your own burnout level.
- A Guide to Mindful Communication in Code Reviews
- 7 Code Review Best Practices and Dynamics You Can Identify and Act On: Part 1
- 7 Code Review Best Practices and Dynamics You Can Identify and Act On: Part 2
- 10 Lessons Learned Conducting Code Reviews
- When Developers Disagree
- Code Review — The Ultimate Guide
- How to do a code review - A section of Google's engineering practices documentation.
- Keep Code Review from Wasting Everyone’s Time
- How to Make Good Code Reviews Better
- The Engineering Manager's Guide to the Code Review Process - From GitPrime
- How to do High-Bar Code Review Without Being a Jerk
- How to Create a Great Team Culture (and Why It Matters)
- the Origins of Opera and the Future of Programming - "You don’t hire star developers, put them together, and poof get a great team. It’s the other way around. When developers form a great team, the team makes us into great developers."
- Do Software Developers Normally Code on Weekends? Work-life Balance and Overtime in the Tech Industry
Documentation, Communications and Status
- Want to be happier and more successful? Write about yourself every week.
- Making Engineering Team Communication Clearer, Faster, Better - Patterns for design documents & design reviews "Most engineering teams rely on design documents to describe, scope, and approve projects or features. Those aren’t new in and of themselves (they're just the foundation of what we'll talk about here). Kicking off a project without one would be like a hiker heading into the forest without a map. Engineering teams don’t have that kind of time."
- What nobody tells you about documentation - "There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four. They are: tutorials, how-to guides, explanation and technical reference. They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most software documentation - often immensely." Blog post from Divio.
- On Helping Junior Developers - "Communication Styles and Why Juniors Should Pick Their Own Mentors"
- Micro-promotions and mentorship: the big impact of small actions in an engineering culture
- [[https://blog.pragmaticengineer.com/developers-mentoring-other-developers/| Developers mentoring other developers: practices I've seen work well]]
- Heroes and Juniors: Increasing Engineering Team Velocity
- Ten Principles for Growth as an Engineer
- How to Deal With a Tech Lead Who Doesn’t Give You Enough Feedback - Don't be that lead.
- OKRs for your Engineering Team
- Hate OKRs? Avoid these 7 mistakes
- Google's OKR Playbook
- OKRs: Potential Issues and How to Deal with Them
- Guide:Set Goals with OKRs
- The Beginner's Guide to OKR
- The Pros and Cons of Individual OKRs
- OKRs Aren't Going to Fix Your Communication Issues
- OKRs from a development team’s perspective
- Alignment through OKR’s and Hypotheses
- Why OKRs are broken and how can we fix it?
- Ask the EM: Can You Really Measure Individual Developer Productivity?
Planning and Stories
- Agile Story Essentials - A visual aid going through one way of thinking about user stories.
- Everyone Should Read Customer Support Emails
- Do This Now: 8 Ways to Focus your Product Team on Impact, Not Features
- How to Write Good User Stories
- Coaching Tools – The Narrative
- Products Over Projects - "Software projects are a popular way of funding and organizing software development. The organize work into temporary, build-only teams and are funded with specific benefits projected in a business case. Product-mode instead uses durable, ideate-build-run teams working on a persistent business issue. Product-mode allows teams to reorient quickly, reduces their end-to-end cycle time, and allows validation of actual benefits by using short-cycle iterations while maintaining the architectural integrity of their software to preserve their long-term effectiveness."
- Definition of Done Examples for Software Projects - "Definition of Done as a shared understanding of what it means for work to be complete. To be honest, each agile team has its own Definition of Done. Basically, a team agrees on, and displays somewhere in the team room or in slack, google drive, whatever, a list of criteria which must be met before a product increment, normally it is a user story and there should be a clear definition of when it is considered “done”."
- What Happens & When During a Sprint - "Successful Scrum implementations involve a handful of important ceremonies. This includes sprint planning, the sprint review, the daily scrum, the sprint retrospective and more. There’s often a lot of confusion about who participates, when these ceremonies are conducted, how long each can take, the purpose of the ceremony, and more. To reduce the confusion, we’ve created infographics that answer each of these questions for sprints of 1-, 2-, 3- and 4-weeks."
- Startups: How to Use Amazon’s Narrative Process to Set Goals and Think Clearly
- Yes, You Should Estimate Software Projects
- Why Standups are Useless and How to Run Great Product Team Meetings - I don't think standups are useless, but it's worth thinking about why and how you do them.
- Makers, Don't Let Yourself Be Forced Into the 'Manager Schedule'
- What’s the Difference between a Project and a Product?
- Results vs. Hours: creating a results-focused workplace
- Managing product requests from customer-facing teams: top 2 things - "A simple technique to maintain a reasonable backlog while making customer-facing teams feel empowered"
- 15 Questions to Ask at the Start of a New Software Project
- Driving engineers to an arbitrary date is a value destroying mistake
- How to kill a project - Know your enemy.
- Designing Autonomous Teams and Services - "Modern, high-performing organizations employ continuous discovery and delivery to develop better products faster than their competitors. They are constantly running experiments to discover innovative new ways to solve customer problems, and they build high-speed engineering capabilities to deliver value every day, creating ultra-short customer feedback cycles."
- Habits of High-Functioning Teams
- Technical Debt Is Like Tetris
- What Ticketmaster is doing about technical debt - "This post describes the journey Ticketmaster has been on over the last year to define and measure technical debt in its software platforms." Patterns for mapping, reporting on, and tracking remediation of technical debt
- The Technical Debt Myth - Conflating many issues under this one heading makes them all harder to tackle. Are you really facing technical debt?
- How to tackle technical debt
- How to invest in technical infrastructure.
- The ONE chart every developer MUST understand - "This chart says that most teams could deliver their software projects sooner if they focused more effort on defect prevention, early defect removal, and other quality issues."
- How to Make Things High-Quality - If it's not worth doing well, it's not worth doing at all.
- Technical Debt is Soul-crushing
- Tech Debt and the Pragmatic Middle Ground
- Taming the Rate of Change - Developing a culture of safety so you can simultaneously get frequent deploys and high quality.
- All the best engineering advice I stole from non-technical people
- Papers We Love - "Papers We Love is a collection of academic computer science papers and a community who loves reading them."
- An incomplete list of classic papers every Software Architect should read - Links to lots of good stuff starting with Turing's “On computable numbers with an application to the Entscheidungsproblem”
- The Product-Minded Software Engineer - "At companies building world-class products, product-minded engineers take teams to a new level of impact."
- A Senior Engineer's CheckList
- 15 Easy Questions for Easy Change Management - "If your systems keep breaking when changes are made, answer these questions." A good checklist for major deployments.
- Thriving on the Technical Leadership Path
- The Leadership Library for Engineers - Huge list of resources
When Things Go Wrong
- The Pre-Mortem: A Simple Technique To Save Any Project From Failure
- It's about what broke, not who broke it - "The important thing at the time was that we cared about what broke, not who broke it. Who broke it is frequently just a roll of the dice: who got that particular task, bug, or ticket assigned to them, and happened to run this valid command instead of that also-valid command? Why would you ever assign blame based on that?"
- The Conjoined Triangles of Senior-Level Development - "The simplest explanation of seniority across companies is this: How much direction will this person need, and how much will they be able to provide to others?"
- On Being A Principal Engineer - "I also realized that while I am still an individual contributor, the principal engineer role carries enough cross-organization work, and enough people skills, that it is much closer to management than it may seem without engineers reporting directly to me."
- Cognitive Biases in Programming - As developers, we’re familiar with the various problems that interfere with our productivity. But often we overlook the broad picture. Some subtle, some huge, some you can do something about, and some you just, well, can’t. These all combine to form a sort of internal feedback loop that can lead to lost hours of productivity, bugs, and just all-around frustration. If we can minimize the impact of one or two of these, we can break the cycle and neutralize the rest.
- The Effective Tech Lead is a 100x Engineer - The Webflow Tech Lead Guide
- Techie to tech lead: My five biggest mistakes - Some advice from a current Head of Technology at ThoughtWorks: "As a young, ambitious developer with a strong sense of my own talent, I was eager to become a tech lead, and it took less than four years for me to achieve this goal. But over the next two years, the experience and reality of leading a team put me off leadership completely. For several years after, I retreated into the security of the technology, shunning any opportunity to take on more responsibility. Over time, I gained an understanding of the root causes of my mistakes and eventually regained the confidence to accept new leadership opportunities and grow as a leader, and with the right support over the last two years, I've grown as a Head of Technology inside ThoughtWorks. As I have coached and mentored other leads, I’ve learned that some of my mistakes weren't unique to me but are common among technologists who move into leadership."
- How to Grow as an Engineer (Working Remotely) - "I have over 20 years of experience as an engineer or engineering manager. I’ve spent the last seven years working for The New York Times, and have been remote for the past three years. How do I keep myself constantly learning and growing, both personally and professionally, while at the same employer, especially now that I’m a remote worker?"
- Being Glue - How to handle it if you move into a less-coding but still-technical "connector" role
- DACI Playbook]]from Atlassian
- Software Development is more like a professional competition than building a house]] - Metaphorical exploration from Christopher Drappier