I recently wrapped up at The Firehose Project! 🎉
I’ve always prided myself on being an adept and expressive communicator, but this project tested me. My team was responsive for the most part, but there were times when I needed to hear back from a team member about some app feature, yet all I got were crickets. 🦗
Sometimes, we gave each other adequate notice before an extended absence “I’ll be traveling on Monday for 10 days”; other times, it seemed like we’d vanish inexplicably. This experience revealed to me just how easily and, perhaps, arrogantly, I expected my team members to be available just because I happened to be.
“I’m up at 6am coding; surely so-and-so must be up too!”
Yup — crazy. No matter how eager I was to forge ahead with the app and push things along, I had to learn to respect the human being behind the code. We had full lives, competing responsibilities, nagging insecurities, and intrusive memories of negative past experiences. I had to learn patience and empathy or, as I’m sure my team members would say, learn to stop being so bossy! 😆
On the other hand, I believe there were standards we could’ve adopted to minimize having to guess about someone’s availability or continued interest. Something like:
“If I’m unreachable for 3 consecutive business days with no explanation, assume you can carry on without my input.”
When we first started on our app, it was smooth sailing. Generate controllers and models, design the chessboard, define the pieces’ attributes, and so on. However, once we began coding the piece-moves logic, things got hairy fast. We had to think about which methods were applicable to which piece types, avoid method duplication (e.g. I named a method 'piece_obstructed?' while my colleague chose 'obstructed_path?').
We couldn’t just type away in our proverbial silos, and our weekly stand-ups weren’t time enough to hash out all the details of our work. I learned to program while keeping others’ code in mind; it behooved me, not merely to know about, but to understand — at least on a high level — what my colleagues were working on. I learned to anticipate the app-wide impact of what I was coding, and initiate convos with my team about it.
Admittedly, I struggled with this one. Our team had different programming strengths, or similar strengths but to varying degrees. As such, there were aspects of the app that came easier to some than to others. Whenever I was having a smoother time developing some functionality, I’d be miffed that I had to “slow down” to pair-program with one of my colleagues, and I would justify my reaction with:
“This is a blocker feature — it needed to be done yesterday!”
However, I realized the importance of collaboration to the quality of our work. I saw that any time “lost” while sharing knowledge with a colleague would later be “made up” when they applied that knowledge to future problems. I learned not to impose my idea of progress on my team, simply because my timeline was faster. I kept reminding myself that these were considerations I would benefit greatly from when I’m working with developers much more experienced than I am.
My capstone project was the most rewarding of my bootcamp experience, because it challenged and stretched me the most. I am keenly aware of those traits of mine can either contribute to, or detract from, my team’s cohesiveness and camaraderie.
As I begin the equally-bootcampy process of landing my first developer job, I’m keen on finding more opportunities to #CodeTogether with developers from all skill-levels and professional experiences.3 September, 2018