Art of programming- the power of time
Time management is one of the most used phrases in leadership, productivity, self-care, etc. We have this valuable resource in our hands, and we should have an idea — or better, a philosophy — on how to use it. In this article, I want to explore what time means for a programmer. How we see time and our approach towards it changes once we identify ourselves as an artist programmer. This article is the second part of the series on the art of programming. You can find the first part here:
Because of the work environment, a programmer’s approach is deadline-based, while for an artist (in general situations), time is a collection of inspirational moments. These two approaches to time could be one of the most fundamental differences between an artist and a programmer. It is not that an artist does not have a deadline, and neither does a programmer have inspirational moments (the flow, you may say). But if we see it as a spectrum from no deadline to a strict deadline, a programmer would end up closer to a strict deadline, and an artist would be closer to no deadline.
Before we go into more details, let’s look at how we do software development now and how much it has changed in the past decade. We came from the traditional waterfall process to agile methodology. The engineers’ behaviors, work environments, and many other aspects have changed dramatically. As we look at these changes, we can see that we are moving away from a strict deadline. What has changed? Requirements? I don’t think so. If we need an application by a specific deadline, we need it by that time. What has changed is the way we see the problem concerning time. All of the methods we have right now are about defining the problem concerning time, Lean startups, MVPs, prototyping, etc. Not the other way around. Time is like an unknown creature; we are trying to find a language to communicate with it through these approaches without compromising quality.
For a programmer, time management and deadlines are undeniable. We cannot change the job’s nature. Every requirement has a deadline and needs to be delivered by that. But we can see that time has become a quality factor rather than simply a resource.
We talked about how an artisan programmer cannot write bad code. If we see time as a quality factor, then an artisan programmer cannot write a code that won’t meet the deadlines (I am not talking about small misses). It may be the most straightforward yet abstract way to describe the time concerning programming. Our time estimations, task descriptions, and solutions will have time and time management in mind by default. We are not trying to manage time but changing how we define the problem and provide solutions concerning time. Breaking down the problem into small steps and estimating based on those steps is not the only solution. The solution itself should be smart enough and high in quality that it saves time.
Time management, time resources, and all those general disciplines towards time are valid principles. But I see time as something more than a simple timeline. We should have a philosophy on how we use it concerning the requirements. By having this philosophy, we can have better estimation, better work environments, and higher quality.
