“See, Saw.”

During the early stages of Flatiron School’s Software Engineering program, students learn an effective problem-solving technique, called the ‘see-saw’ approach.

“The idea is that Ruby is your partner on the see-saw: you get a step closer to the solution, it gets a step away from the solution toward you — back-and-forth until you meet in the middle.”

Though introduced in the context of constructing ‘helper methods’ that make it easier for us to understand and navigate through nested data structures, it’s an approach that can be applied to many different types of coding scenarios, and beyond. Having just completed another group project with two of my classmates, I observed the approach applied over and over again all throughout our four-day building process. In this blog post, I’ll describe how this simple observation is refining the way I learn.

Most of our project was built during long stretches of time when we would take turns either coding (as the driver) or thinking out loud (as one of the navigators). Although guided by a common vision of what our finished project would look like and what it would allow our users to do, it was interesting to see the various paths we took to arrive at the same set of project milestones. In a way, we were each other’s partners on the ‘see-saw’, working together to solve the same problems (how might we debug this error?) or build the same solutions (how can we add this new feature?) but from more angles than we’d possibly be able to alone.

Simply put, there is always value in collaboration. That’s because, if nothing else, it gives us the opportunity to more closely examine — and potentially improve — the way we currently do certain things. For only when we become aware of a better way, can we begin to act (or code, or learn) in that better way. But perhaps the great Maya Angelou put it best:

“Do the best you can until you know better.
Then when you know better,
you do better.”

Cheers (and many thanks) to my team for this growth experience.