For the past few Sundays a group of me and other C5’ers came into the office to work on BridgeTroll with a few junior developers. We hoped that BridgeTroll would get a few highly requested features, but mostly we really hoped the junior developers would get practice and pick up some good practices about TDD, agile, and coding in general.
This was actually our second iteration of teaching pairing (and teaching through pairing). The first time was on a weeknight and between setup and getting everyone on the same page, not much learning was had. This incarnation of the program addressed the setup issue and having continuity over the course of several weeks seemed to work well. To be fair, there was a lot of story preparation time we sunk in before the start of the program so that most of the time could be spent on developing so that helped. It also really helped that BridgeTroll has an excellent setup script, which made starting a ton smoother.
Why would anyone put on a free program to teach industry skills? There must be something they expect in return.
During the first week, one of the juniors mentioned that they were asked “Why would anyone put on a free program to teach industry skills? There must be something they expect in return.” The answer that the junior gave was this “The [Tech] industry is different. There is a sense of wanting to help each other out and pay it forward (as well as backward to those who helped us out).”
My answer to the question posed is somewhat more complicated. It is very true that there are many people in the tech industry that pay it forwards and back. We all reap the benefits of their labor whether it is through open source software that we use, well thought out conversation on issues that we as an industry face, or the attitude that it is important to take time out of our day to answer the questions of someone less experienced.
I would like to highlight that last one for a moment: taking the time out of our day to answer the questions of someone less experienced. While I believe many people do this, I also believe that we as an industry fall short in providing mentorship. In the post about the original incarnation of Junior Jump, what I read in that post is that the industry is unwilling to train newcomers. At the same time that we’re lamenting the lack of engineers, we’re blocking new people from entering by not providing the training to turn them into good developers. Junior Jump Extended is one of our responses to this shortsightedness.
While our second iteration wasn’t perfect, there were a lot of things that we learned through a weekly reflection. We learned that having mentors and mentees there 4 weekends in a row is pretty hard on everyone’s schedule. So while our first iteration was too short an amount of time, 4 weekends was possibly too much. The group also found that it was desirable to swap pairs since it gave the juniors a different perspective on how people approach TDD/Agile/Pairing/Problem solving.
There was also a lot of positive feedback:
“I liked working on a real open source project where my work isn’t theoretical/practice.”
“I like that whenever we fixed a bug that we were able to discuss the reason for the bug and how we fixed it.
“As cool as it was to have the pull request accepted, the real value of the pull request came from getting my commit ready to be pulled into a functioning open source project.”
“I like doing TDD with my partner. Best TDD explanation I’ve gotten so far!”
The end goal of course, is that the juniors end up being more marketable. It’s still a little early to see if that plays out the way we hope, but the feedback makes us believe that they picked up a lot and we feel really optimistic on behalf of all our juniors. If you are interested in helping us jumpstart juniors send an email to email@example.com
Read one of our junior’s reactions to the program: http://thetylerbrothers.com/2015/07/Contributing-to-Bridge-Troll-Junior-Jump-Day-1/