“Progress isn’t made by early risers. It’s made by lazy men trying to find easier ways to do something.” — Robert Heinlein

Okay but how much of this applies to real world and practical day to day life of a programmer where he is supposed to make progress on particular tasks? What is the worth of the progress that we make? Is it worth making progress if the progress made itself is not efficient or long-term reusable for the team?

These are some of the questions that arose while I was writing a simple program to generate all the Armstrong Numbers (Narcissistic Numbers) in a range. Being a lazy programmer, I started writing off the solution without thinking much, without making any algorithm or drawing charts for the logical representation.

def is_armstrong(val, degree):
    sum = 0
    for i in val:
        sum += pow(int(i), degree)
    val = int(("").join(val))
    if val == sum:
        return True
    return False

n = int(input("Enter Limit: "))

for i in range(n):
    if is_armstrong(list(str(i)), len(list(str(i)))):
        print(i)

Like I expected, it was a very inefficient and slow solution to the problem. But the thoughts I had after writing it were bothering me such as is it time-worthy to make brute-force, easy-to-go solution approaches towards a problem? Or should we not begin until we have a hypothesis of an efficient solution?

“Laziness is the first step towards efficiency.” — Patrick Bennett

Later on I realized that if I had never written lazy solutions to each problem I faced in the past, I would not have started at all at least 80% of the time. This led me to realize that perfection always grows in parallel with imperfection.

There are so many times I don’t write any code or any practical working solution just because I couldn’t think of the best way to approach the problem. But I believe there is no better way of writing perfect code without writing imperfect code first because then you know the pros and cons of the solution you’ve created, and there’s always room for making it better.

The problem is not starting with a dumb approach and then gradually making it better. The problem is not starting at all.