- Asking for help
We often get stuck in development and ask Google, where we should ask one another. As an end result, we have more cleanup work later. We could avoid cleanup by having more brains on the work.
- Reuse and rework
We could learn to use our technical assets (reuse existing code) in addition to working actively against adding technical debt. We have technical assets we don't use, but recreate as information of what there is isn't shared.
- Continuous learningWe could learn from one another and have the learning show up right away in what we’re delivering. In particular, we could even out our individual skill differences in technical excellence we’ve already been working on. No course teaches how to work with our code and application specifically, we need to share examples by doing things together.
We could get away from feeling alone and isolated. There’s very few other practical ways than pairing or mobbing to expose the practical level knowledge from developer to developer. It’s in the doing we learn.
We could be more focused on an item we’re delivering, making the throughput times shorter without having to consider merge conflicts or additional work in splitting up into something manageable for several people. We could reduce procrastination and waiting, making think time explicit instead of hiding it into tasks. We still control our own use of time, just as always.
- Skills outside the "developer" boxWhen working with requirements, we still often take what was asked and deliver that without questioning it enough. User interfaces in particular can be very dodgy. Exploratory testing that actually find bugs happens only when I do it or I sit quietly next to a developer testing and pretending I'm a totem or a mascot holding space for testing thoughts to happen. There's a lot of siloing to tear down on what a developer can / should do.
I learned we had 3284 lines of code in the Selenium test project. I reminded myself that we started working on this stuff with me creating opportunities to try it out and create things already two years ago. And whatever was created, had emerged in the last six months. The one developer who had taken the given chance to focus on learning to do stuff with Selenium had used what was given and created quite a nice page-object - utils - tests structure. It was time to get that to the rest of the team. So we agreed to mob with two learning goals.
- Everyone would learn to run tests / subset of tests / analyse the results when tests fail to make them a team asset
- Everyone would learn to create new tests
I noticed three things I can put my finger on that we caught in the team within the session:
- Keyboard shortcuts. People learned to use the IDE a lot faster over just short practice. It's just more efficient telling people shortcuts and then telling on a higher level with things happening faster when you don't search around with mouse. And surprising shortcuts were missing from people who do this stuff daily.
- Resharper. We've had it for ages. And many in the team did not use it. Renaming manually to three places becames visible and something we can help with changing when it is visible. And it's error prone.
- Consume-first programming. It was interesting to notice that only some were comfortable with the idea of faking what you wanted to code to have in the test, before implementing it. Most people were first navigating with the idea that you build each piece and put them together in the end. Example was very powerful in that, and I was particularly pleased on how smoothly it came in developer collaboration.