Zoom-out, zoom-in

When I was a kid, I had many dreams, programming was just one of them. Another relevant one was drawing. It was the activity I did the most to fight boredom in high-school. I was not specially good at it, but neither that bad. At certain point, when I wanted to create a full illustration, I curated my own technique to properly place all elements in the sheet. Some of you maybe faced the same problem before. You start drawing an object for one of its parts then continue, continue, and finally realize that the scale you choose to start the drawing just does not fit in the sheet. So you need to start again. After many trial and error drawings, I started approaching the whole project differently. First, I tried to imagine the full picture so I can predict which elements must fill in the limited canvas. Then superfast, using a pencil, starting to outlining and shape all those elements in a very skeleton approach. In this phase, I was never focusing on the details. Just putting all the elements in the sheet as subtle lines, so I can validate the composition looks ok in the sheet pretty fast. Once I got happy with it, it was the time to start zooming in and create a few details here and there. Then zoom-out, does such details look ok in the full picture? Great! Zoom-in again into the next detail, repeat until I got the illustration I was looking for. This approach also used to help to have a good balance between all parts of the creation. I'm sure you're all familiar with the half done horse meme. Zoom-out, zoom-in approach helped me to prevent these kinds of situations. Hopefully I didn't end up being a professional illustrator, but I'm a software engineer instead. But I see myself practicing the same approach as with drawing when I code. When I take a new project or task, I usually start by challenging the idea and trying to figure out all elements that eventually want to place in the canvas. Once I know how the final picture should look like, I start shaping very simple modules and how they are connected. Once I have most of the important core ones in place, I start zooming-in and implement more important details. At this stage, I prioritize having full user journeys so I can validate the app, as soon as possible. Then once I have something working I often zoom out and check how those details fit in the bigger picture, then decide if I need to adjust things, so I can have harmony in the whole application. Oftentimes, this process involves refactoring and cleaning, you know, remove all the cruft and reorganizing modules. This approach is obviously not a silver bullet. It works better in the exploratory process of having an idea and figuring out its architecture by doing it. Obviously this not replace proper analysis and design phases, but it’s a powerful shortcut for exploratory work such as vine-coded side projects. For me, this approach is just another tool that can help in the hard process of designing software. It’s not my default way of working, but for certain unexplored projects is great.