Well, five of the six made it through the immersion phase of this year's academy.
Even though the immersion phase is roughly the same in length as many "Programming Bootcamps", and has some similarities, it is still very different as it is part of a much bigger picture. Recently, Liz Eggleston of The Course Report invited me to write this article about the differences between software craftsmanship development and programming bootcamps.
I'll write more later about the apprenticeship phase that the Academy participants are in the middle of now, but I want to first summarize the immersion phase.
On the last day of the immersion phase, I asked them to describe what they could do before and after the immersion phase. This is what we ended up writing on the whiteboard:
Perhaps you can't read my writing. Well, here's the stuff on the left which they say summed up what they knew before the immersion phase:
And here is the middle, where they described the architecture of what they built during the immersion phase and what they know how to build now:
Using these tools:
(I understand you still might not be able to read my writing.) Well, I'll let one of our participants, Greg Tarsa, describe his experience:
Back in December, 14+ weeks ago, I entered an Immersion Training program in the Craftsmanship Academy of RoleModel Software in order to refresh my programming skills and get a leg-up working in the world of Web application programming.
It has been quite a ride.
I came into the program after losing my job as an Operating System Software Development Manager. Twice! While I loved building teams, I missed being hands-on. I wanted to re-boot with some new skills and get acquainted with a whole new field of software development. RoleModel's Academy looked like an outstanding way to do this. I applied and was accepted. The class included two of us "re-booters" and 4 younger high school graduates from various parts of the country.
This will be a looooong article if I try to describe play-by-play all that we covered. There are a lot of moving pieces in web application development. But a short laundry list of things we learned is in order. Besides basic HTML and CSS, there are also implementation languages (Ruby, Objective C, JavaScript), templating languages (Slim, ERB, SCSS), domain-specific languages, server frameworks (Sinatra, Rails), and development methodologies (TDD, OOP, R-G-R). Oh, and databases (SQL, Postgresql), let's not forget databases. Or git. Or–nevermind. The list is too long.
After completing the course, I have a solid exposure to a wide variety of these tools and concepts, but more importantly, I have come to understand many of the key relationships between and among them along with solid development approaches that help keep things simple while also creating running code early in the process.
First the development principles.
At the core of the process would be Test Driven Development and Red-Green-Refactor. R-G-R puts a priority on writing tests that fail (i.e., Red) before writing code that works (Green) before writing code that is clean or even straightforward. "Make it run, make it right, make it good." was a mantra here.
Test-Driven Development works hand in hand with this. TDD in its best form, has you writing tests before the writing of code. Using tools, like rspec, capybara and spinach we essentially learned to write specifications incrementally. Write a test, watch it fail. Write the code to make it pass. Write another test, etc. Very quickly we had three useful things:
Coming from an OS development background it was challenging to let go of the long practice of not writing code until the specifications are completed and completely understood. But I learned…
In the area of Object Oriented Programming, we learned three languages: Ruby, Objective C, and Javascript. Each had its sweet and bitter features. All of them allowed for basic practices of encapsulation and provided objects and the ability to send messages to them. Ruby seemed the most comfortable with its object-ness, but Objective-C brought more clarity to the message passing involved with good object orientation. Javascript was trickier to use, but shed light into the "guts" of an object system via its "prototype" orientation towards objects (i.e., instead of using explicit classes).
All these concepts, languages and tools came together in the week we started to learn Rails. This exposure to Rails came via the Ruby On Rails Tutorial by Michael Hartl. Ruby, Slim, client-server, database, rspec, capybara, spinach, SASSy CSS, Model-View-Controller. Everything we had learned, experimented with and wrote code for came together here.
Carefully meshed into all the classroom instruction, project assignments, daily reviews, etc. was the growing application of Agile development principles. We learned the value of moving forward without knowing all of what we were doing at any given point in time. We saw first-hand how plans never go as written and so investing in their core elements and pushing the details off to later works well in creating a cadence for for development. We were doing weekly reviews of what we had been learning and experiencing in our class projects from the start, this turned into weekly iteration meetings for our final project.
The core beauty of this training was how the techniques and practices taught preclude a great deal of the heartache and grief that comes from learning a tool, technique, or framework out of context and then learning how to use it wisely. Ken Auer was our guide through a Labyrinth filled with pits, snares, and energy-sucking death traps; any number of which would have greatly delayed our learning the critical mass of skills needed for web programming. However, through careful leadership, we never had any real scares, much of what we know as the only way to do things are industy Best Practices. We were not simply guided through the course, we were molded into into apprentices with principles that will make the path ahead more productive, more fun and a great learning experience.
Now these folks are ready to be apprentices, sitting with our Craftsmen to learn and help. They don't have to ask why we're writing tests first, how to use Git, or many of the basics of the way we do things. They'll be taking all the things they learned and working on real projects, observing the craftsmen as they expertly work through a myriad of challenges, and contributing as they can on their journey to become craftsmen in their own right. It may seem like a long way to go, but they've taken some great first steps.
Photo by Green Chameleon on Unsplash
