Last week I wrote about starting a retooling adventure. I’ve gone back to school. The school calls itself “Learners Guild” and gathers statistically improbable apprentices in software development. They learn from experts, from each other, and from deadline-driven projects. The financial model is a study-now, pay-later “income sharing agreement”.
I’ve just finished week 2. I partnered with another week-2 learner. Together we wrote programs to reproduce the behavior of about 40 already-existing programs in a popular software library named Lodash. By doing that we fulfilled the requirements of one goal in the Guild’s Goal Library.
For me the week also demonstrated the complexity of the dance called software development in teams. Even a team of 2 makes use of an elaborate protocol, named “Git”, to manage their contributions to the code they are writing. That would not be true if they did everything together, agreeing on each line before entering it. But it is true if they split the work into parts and work individually on distinct parts. There are other competing collaboration-management protocols, but Git has emerged as the most successful competitor.
Sorry, I can’t report any teamwork drama. We split up the work, discussed solution strategies, and reviewed and revised each other’s code. Differences in style and tactics? Sure. But they were easy to work through. By week’s end, we thought we had done everything required by the specifications, but our first reviewers found a few deficiencies in our compliance with rules we didn’t know existed. So we learned more about not only how to satisfy the explicit specifications, but also how to infer expectations that the specs don’t expressly state.
When we tell a reviewer that we are surprised by such a tacit expectation, the reviewer urges us to propose (using that same Git protocol) a proposal for a modification of the specs to mitigate the misunderstanding. Yesterday I submitted such a proposal. Git will notify me of any actions taken on the proposal.