Week 2 at an unbootcamp

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.

Why in the world would we spend a week making something that others have already made? It’s not an unrealistic thing to do, actually. Like any actively used programming language, JavaScript is evolving. One standard (ES5) was published in 2009 and another (ES2015) in 2015. Lodash was created to add features to ES5, but many of those features, or parts thereof, got incorporated into ES2015. So a new Lodash-like library based on ES2015 would be simpler. Some of its functions could merely call ES2015 functions. Others would need to perform additional operations, but would be more compact and efficient, relying on more powerful features of ES2015. Projects like this exist in the real world. This one also focused our attention on, and gave us practice with, some of the newest features of JavaScript, those introduced into the language in 2015.

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.

A couple of these discrepancies related to a spec requiring us to write the code in the ES2015 version of JavaScript. ES2015 introduced new syntax not previously valid, such as a more compact way to define functions, with arrow symbols, and more restrictive types of variables, declared with new keywords (“let” and “const”). It doesn’t mandate the use of the new syntax but only permits it. We didn’t use these new syntactic features at first but were advised by reviewers that we should. So, now we know that, if we’re told to use a new version of a language, that brings (or at least may bring) with it an expectation that features introduced in that version will be used as much as is practically possible.

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.

 

 

Leave a Reply