Having lived in one repository for a few months now, I have naturally grown more and more accustomed to it. I am currently at a stage where the challenging part of adding a new feature or fixing a bug is merely talking about the solution. It’s not that understanding the details and the impact of my work was trivial before; it’s just that the actual implementation has definitely become more approachable. With every new project, I can spend more time focusing on how it would fit in the overall system rather than how to write the bulk of the code.

This is linked to the classic advice of telling developers what they should do, not how they should do it. For example, it becomes tiresome to spend hours discussing whether the arguments to a Python script should be parsed using argparse or python-fire. Sure, you can go through the process once, but any iteration after that is repetition. The same applies to every other implementation decision in the context of one repository: most of them will be recurring.

More than that, the way I see developers is like writers: a spark of creativity has motivated them to write a story, and the main precondition for everything to follow is the plot. The characters, the scene, and the ending are all outlined based on this initial trajectory. It might indeed be the case that the choice between two words gives a specific subtlety to one paragraph. Arguably, the collection of all these decisions makes a book what it is. However, even though I’m not a writer myself, I imagine that every set of possible words contains an obvious candidate. The obviousness is only viewed as such as part of the broader framework.

Going back to programming, in a similar style to writing, it’s the narrative that the developers have to understand to start the task. For example, designing an email application is more about the high-level functions of fetching the data, displaying it, and taking input from the user. Undoubtedly meaningful, deciding how to store the data or what interface to expose takes less creative substance.

That is how I approach work at the moment. Note that I’ve reached this stage only after spending considerable time implementing projects in different ways, exploring what is possible and what is not. And so, having understood the building blocks, I transcended to the next abstraction level. I am comfortable handling generic ideas without worrying about the code behind each component. Perhaps I find clarity in higher levels because I am still a developer and not a software engineer. Maybe it’s because I am not familiar with the smaller building blocks. To each his own!