Observability in Software Engineering
- Plan:
- Teach programmers to distinguish reliable research from plausible punditry
- Use the problem of programmer productivity as the motivating issue
- Pro:
- Topical: debates about the impact of AI are vacuous without an understanding of what productivity means
- Motivates study of both qualitative and quantitative methods
- Practical exercises are straightforward to create
- Con:
- Medium effort to create
- May be seen as niche: people won't understand observability and productivity are just being used as a working example
All of the material is available under an open license, and contributions through our repository are welcome. All participants are required to respect our Code of Conduct.
Learner Persona
- Dav, 32, has been working in mobile application development for ten years. Originally a front-end developer, they now split their time between managing a team of three and building out test infrastructure for that team and others.
- The last two projects that Dav worked on shipped late despite late hours from their team, and had an embarrassing number of bugs. As a result, senior management wants more insight into progress and productivity, but Dav is worried that simple metrics like "issues closed per week" will be both misleading and abused.
- Dav wants to learn more about what makes programmers and programming teams productive (or unproductive) in general, and how to identify problems and bottlenecks without intrusive surveillance.
- Another release cycle is just about to start, so Dav's time is limited: they are able to take a day for a workshop, but have learned the hard way that they are unlikely to complete books or self-paced online courses.
Lessons
Appendices
Acknowledgments
- Greg Wilson is a programmer, author, and educator based in Toronto. He was the co-founder and first Executive Director of Software Carpentry and received ACM SIGSOFT's Influential Educator Award in 2020.
start where you are · use what you have · help who you can