Time is always a valuable thing for a person. In fact, everything that we do has a dangerous cost to it: time. When it comes to programming, time is a crucial factor especially when it comes to groups/companies. A programmer’s time must be spent wisely at ensuring that the code that they implemented to the team is efficient and clean. In fact, a programmer’s nightmare is an error in their programming, as it takes more time to fix then to implement.
The concept of estimating effort in a program seems straightforward, but is it worth ensuring that the time you spent working on a program is documented? To some, estimating the time it takes to write a program seems like another dull task to put in their group work. However, if you gave it another perspective to view through, estimations can be the progress to your development in not only your programming skills, but possibly in the decisions you make throughout your life.
The most efficient way that I was able to track my own time was to look at the clock, and observe when I started fixing an issue in the program to the moment I fixed the issue. After thorough observation, I would realize how much time I had taken to write a program, and consider possible other methods I could make that would allow me to code more efficiently by reducing how much time it took for me to fix an issue. While I deemed it initially to be useless, I soon came to realize that these time recordings were meant to show what areas I had the most success in fixing in the minimum time, and what areas I struggle with. This allowed me to go through the concepts of such issues that took the longest and thoroughly understand the topics in order to develop a much faster method to fix that issue. In fact, it was my assumption why quizzes were timed: to show which areas a student performed well and which areas the student otherwise didn’t.
To conclude my time in time estimations, being able to condition myself to record the time has also given me the opportunity to strive for much better decisions to take. Perhaps later on even after my time programming, I would find myself using estimations elsewhere.