Impossible Day at the Recurse Center

Yesterday was “Impossible Day” at the Recurse Center. Impossible Day starts in the morning with a good number of the people currently in batch gathering in one of the conference rooms and sharing projects they would like to work on for the day. Projects can be solo, pair, or open to a group. The spirit of the day is to work on something that is beyond what you currently imagine to be even possible. To really push yourself to imagine something that feels entirely impossible and then just focus on that for the rest of the day.

People went around the room sharing if they already had an idea in mind or if they are looking to join a team. Then we either paired up, joined a group, or went off to work on a solo project. We would meet again at 4pm to reflect on our progress.

Impossible Day connects with but intentionally goes a bit beyond the first self-directive at the Recurse Center to “work at the edge of your abilities”. Normally, Recursers are working in that “zone of proximal development” and actually writing code on projects they find interesting. The spirit of Impossible Day is to commit to and experience working on something that is actually beyond the zone of proximal development. If you’ve been getting to know the edge of your abilities from the side of what is already possible, Impossible Day is an opportunity to see the edge of your abilities from the other side, the side you may have never actually experienced.

Conceptually, I find the idea of Impossible Day to be very appealing. It is exciting to think about setting aside time to purposefully push myself meaningfully beyond what I know is already possible. I’ve noticed over the past few months as I work on a project that is in production most of my work consists of making minor, gradual improvements. I’ve grown unfamiliar with that feeling of being totally out of my depth. This makes sense. This is reasonable. Performing work ought to consist of some measurable progress, right?

It would be absurd if a weight lifter went to the gym and just tried to pick up weights that were impossible to budge. But software development is not weight lifting. Unlike the athlete who is bound by the physical limitations of their muscular strength, there is always some possibility that we could have a total breakthrough or complete reorganization of our mental models when taking on a massive challenge. Yet we rarely do this. We tend to write software as though we are like the athlete who is bound by an obligation to be practical. Impossible Day is an invitation to remind us that we are very much not weight-lifters, and this is something to celebrate.

Yet, this is not at all what I actually experienced during Impossible Day.

I had linked up with another developer a few days prior and indicated that I was interested in working with him on his project. I didn’t overthink this. I was just happy for the opportunity to work with this developer. We paired off after the morning meeting and got to work. He explained the scope of his project and how it involved doing a bit of web scraping and then spinning up a RAG pipeline to feed this scraped content into an LLM. As we discussed the project scope, I expressed my concern that even if we were successful with the web scraping portion of this project, we would not have enough data to actually benefit from a RAG pipeline. Our total amount of data would still fit comfortably within a standard context window. I had some prior experience implementing the first steps of a RAG pipeline and this developer seemed genuinely open to my input. Within about the first half-hour of Impossible Day we had decided that we were going to pivot entirely to something else.

The last aspect of his project was to work with an LLM. We talked a bit more about what was interesting to him about LLMs and settled on an idea to spin up a CLI tool called “roast my repo.” A developer could open up a terminal and simply type roast_my_repo and the contents of their current repo would be sent to an LLM with a prompt asking for critical feedback about whether there are any anti-patterns apparent in the project.

This would be an opportunity to engage with the code review capabilities of LLMs beyond the copy-paste pattern or the line-by-line pattern. So we got to work and quickly spun up a CLI tool that recursively gathered the contents of the current working directory, sent these to an LLM, and successfully received meaningful feedback about anti-patterns on both small and very large repos.

Next, we implemented a feature where users could specify that instead of just receiving narrative feedback we would like the LLM to implement the actual code changes. By specifying that we wanted these changes in structured format, we were then able to parse this response and then overwrite the actual problematic files with the code corrections from the LLM. roast_my_repo --review provides a comprehensive overview of anti-patterns throughout the repo. roast_my_repo --fix triggers a process where the updates are immediately merged into the codebase and the reasoning for the updates is provided with inline comments.

We had ample time for lunch and finished the project prior to the 4pm deadline. At no point did it feel like either of us were working in the realm of the impossible. In fact, working together felt totally fluid and easy-going.

During the 4pm presentations, a good number of people presenting shared that they hadn’t written one line of code. Most people were not able to accomplish even a portion of their impossible task. We were the only group that completed their task and shipped a useable product. To this extent, we were the only group that failed Impossible Day.

While I’m somewhat disappointed that I didn’t get to see the edge of my abilities from the other side, I realized later that evening that something remarkable did happen. I linked up with a developer who had been holding an idea for several days. Without any defensiveness or reactivity, this developer listened to some feedback about the idea and we pivoted together to an entirely different project. We scoped the project and got to work immediately. Came up with a tone for the project, shipped the MVP feature, and then immediately got to work on a second feature that made the project far more interesting.

Within the context of the Recurse Center, none of this is impossible or even exceptional. However, within the context of the typical professional environment, something like this would be drawn out, overly complicated, and never shipped. People hold on to their initial ideas for too long, feedback is taken too personally, and project scope keeps growing to the extent that what was once exciting quickly just becomes daunting or tedious.

While I am in agreement with the general idea that it is worthwhile to set aside time to take on an impossible task, my honest experience is that I found it far more satisfying to work effectively with another engineer, iterate through ideas, and actually ship something useful.

Still, I keep thinking about Impossible Day in relation to that scene in Fight Club where Tyler Durden gives the first homework assignment: “Pick a fight with a complete stranger and lose.” Impossible Day rolls around at the Recurse Center every six weeks. Next time, appreciating that the time at Recurse is an opportunity to step beyond your comfort zone, I’m going to see what it feels like to actually pick a fight and lose.