We’re now a few weeks into our Website Security Research Project capstone project, and just completed our first Standup.
In this standup, my research partner used the phrase “the long pole in the tent” to describe their perspective on the most important portion of the project. (Aside: if you’d like to read a fascinating and anecdote-rich article on this phrase, the NYT has you covered).
The reasons this particular phrase stuck out to me is:
- I had never heard this phrase before
- We have different ideas about what the “long pole” is in this project
- It is a great visual/engineering metaphor
During this project, my project partner and I are going to quickly learn a lot about each other. We’ll have to, if we want to stay on track with our deliverables, which are largely self-defined in this project.
To get there, we’ve got to address all three points above: We have to learn to communicate effectively, we have to learn to agree on critical infrastructure decisions, and we have to find ways to make our own voice and experience present in our work.
So what is the “long pole in the tent” in this project?
I tend to start projects by working on the least functional parts of the project first: interfaces, data definitions, API decisions, and routing. I like having the stuff that doesn’t “do” anything, done first. To me, I feel like I have to get this done before I can focus on individual coding problems.
I admire engineers who do the reverse – people who want to dive in to the individual problems in a project right away, discussing, deriving and demonstrating solutions.
I am going to argue that my partner, who is in the 2nd group, is more “right” about this being our bigger problem to tackle in this project. Without working proofs of concept, we won’t really have anything to stand on for the mid-project presentation of our work. We can always shuffle those demonstrations around in a different interface or implementation later in the project.
Writing this makes me realize I need to put aside my own work biases and dig in to what is best for the team. Can I shift my priorities, try new ways of working, and develop outside of my comfort zone? The answer to all these is: yes! One of the best parts of working as a team is learning how your perspective compares to others. To be an adaptable, modern software engineer I feel there is no other way of working.
Once we’re working this way, we’ll be on our way to building something with a great foundation that can go to spectacular heights.
Safire, William, “A hot metaphor emerges”, The New York Times, Jan 6, 2020, https://www.nytimes.com/2008/01/06/opinion/06iht-edsafire.1.9037962.html
