Courses and workshops are nice, and you learn a lot. But then, you get back to work, and try to translate what you have learned into your code. Whether it is writing tests for the code, refactoring it to be more testable and cleaner – it doesn’t look like the “simple” exercises you easily solved just a day ago in class.
That’s where “Work on your code” workshops come in. These workshops are intended to bridge that gap, and give you a push on how to implement the new ideas on your code, with a mentor beside you. These short workshops (2-3 hours) are intended for guided practice and learning, so you can get enough head-start to continue onward.
Workshop topics can cover practice for analyzing testability issues, writing tests, refactoring for testability and discussion on further steps. The eventual code can be merged to the development branch. Results may vary on the code itself, skills, and engagement.
Working in small groups allow input and engagement from everyone involved. The whole team should experience and learn how the ideas can be implemented on their code.
Remote and on-site options. Multiple short sessions are recommended over few long ones.
Workshop goals
Following the workshop, attendees will be able to:
- Apply development and testing principles to their work code
- Have ideas on how to continue testing and refactoring connecting areas
- Identify possible testability, maintainability and design issues, patterns, and solutions
Target Audience
- Small team of developers and/or testers (up to 5)
- The team includes people who work, or plan to work, on the code. Having the code known to them, not only make sense, but also speeds up the work – people have more confidence on “their” code.
- During the session, we will need Experts available in terms of architecture, design, quality and product. This could be a single person, or multiple people. The team will have questions about design boundaries, risks introduced by changes, impact on further testing, etc.
Workshop agenda
- The main topic of each session will be decided with the mentor beforehand
- The team can take it in different directions during the session.
Prerequisites
- The code should be familiar to the team– either through direct development or using it. Without some familiarity, we’ll lose time on explanations or engagement.
- The code should be current, either being worked on, or planned to be, soon. It is in the mind of the people, including what they can or cannot do.
- The code can be built (and hopefully run the tests) in a quick manner. The session is built on feedback from running and testing. This may require setting up a different (local) build environment than the regular one.
- The selected code needs to be challenging – not plain and clean, but also, not that require whole architecture or big design changes that cannot fit into the session.
- The code needs its own branch, to not risk the main work branch. Potentially this code will be merged later.
For more questions:
Contact Us!