TIY WEEK 3: A taste of the good life.
It’s Tuesday night and I just pulled some scones out of the oven. They taste delicious; hopefully my classmates tomorrow agree. But these scones don’t hold a candle to what Week 3 left me with: a taste of the good life.
Sure, Ruby was amazingly fun this week — I created a command-line version of the card game war, messed around some more with modules and classes, created a functional Blackjack game complete with splitting, and a hand advisor (don’t get me started on enormous amount of time it took to get the edge case logic for splitting just right). If you’re interested, you can check out my github repos here. But really it wasn’t the code (delightful as it was) that highlighted the week, it was the exposure to my future life as a developer.
On Wednesday, we had a guest lecture from Ryan Osborne, formerly of One View and PERQ, on the guiding principles of Agile software development, it’s contrasts with Waterfall, and the Agile Scrum framework in particular. He painted a beautiful picture for us. Scrum is both flexible and structured, driven by team capabilities (I think the technical term is “velocity”), and yet responsive to the business side needs. Agile Scrum just makes sense. To break it down a bit, Scrum hands out different roles within the company. There’s a “product owner” who’s job it is to represent the needs of the customer and push from the business side. He works with the development team to break down the needed product into a series of digestible chunks or “items” that need to be accomplished to complete the product. Then, a planning meeting is held during which the product owner and the development team hash out together what items they think that they can realistically accomplish within a set amount of time, known as a “sprint” (usually around two weeks). When agreement is reached, the development team commences work and the development team leader, known as the “Scrum Master” facilitates the sprint, guiding work assignment, removing blockers, and helping make key allocation decisions along the way. Each day during the sprint begins with a “daily scrum” meeting where people pretty much each share where they are at, how the work is going, and any blockers that are impeding progress. At the end of that set time, a sprint retrospective meeting is held to chart the progress made and to help reflect and refine the process moving forward.
I can’t tell you how wonderful that sounds. Having worked on many a team in previous jobs, the one thing that they (mostly) had in common was inefficiency. I’ve attended countless meetings that had no need for 85% of the people in the room. I’ve been on countless action committees which were hamstrung by an ill-defined workflow, vague communication, and constantly moving time-tables. The teams I’ve been on that were most productive usually consisted of me, and a few other like-minded individuals who knew that we could trust each other to come-through and communicate bluntly and clearly. Scrum allows for scaleable, coordinated efficiency. Agile scrum sounds to me like beautiful code. Each part has a particular purpose, each thing is broken down into its minimally viable parts (haha “minimally viable product” is actually a Scrum thing), and each of those parts locks perfectly in step with the others to create a coherent whole.
Anyhow, sorry to come off a bit overexcited. But let’s just say I’m excited to work in a place that values systems for efficiency and communication, whether Agile or some other framework.
I’m running out of time to sleep tonight, so I’ll keep my thoughts on Angie’s list brief. Beautiful campus, cool product, awesome vision and great people. There… Done!
Ok, well maybe not quite. All of the above are true to my impressions of the place from our field trip there this past Friday. We got to meet 6 awesome senior members of their tech team, from the VP level on down. What made the biggest impression on me, however, was the true culture of learning that I sensed in the place from the aforementioned senior leaders on down. I really got the feeling that the company was invested in each of their employees’ professional growth, and willing to invest significant resources to ensure that their employees could learn, try new things, and move forward in a career path within Angie’s list that best fit their individual skills and interests. I could tell that the employees I talked to at Angie’s list loved their job, and felt fulfilled doing it.
In contrast to the team structures I mentioned above, I did have a generally positive experience with professional development as a teacher. I was given a lot of flexibility to go to trainings and try out different stuff within the classroom and with my caseload of students. And I really appreciated that and really hope to find a place that has a similar (or greater) emphasis on growth. The downside of teaching for me though, was that no matter how good and skilled you get, your core responsibilities never fundamentally change. At the end of the day, you’re still just a teacher, in the same subject area, with the same material to cover, in same blocks of time as always, etc. As someone who loves new challenges, I hope (and believe) that working as a developer will fulfill this craving. I’ll constantly have new sprints to complete, new teams to be a part of, new languages to learn, and (if I add great value to a company) new roles to take. This week was a taste of something good… a taste of the future.