The most common mistake developers make when facing a complex development

Developing is simple.

At least, developers conclude that it’s simple most of the time. We do not face new challenges daily but repeat already-known programs and structures. However, there are specific situations when we encounter a complex development that takes us off autopilot and makes our jobs more exciting.

Of course, that excitement doesn’t come without a good portion of preceding frustration.

Developers’ objectives for creating a good program

We have 3 main objectives as software developers when creating a program:

1. It should work
2. The code should be easy to understand by others
3. It should perform well in terms of process and memory costs

The above premises are mandatory (regardless of their subjectivity).

If our program lacks any of them, we can say it lacks quality. The reason has nothing to do with programmers’ pride or empty methodology. It is that missing any of them will cause issues in the future.

Experienced developers achieve the three objectives at once.

They create a piece of code that works, is clear, and saves resources. However, that efficiency becomes an obstacle when the problem is exceptionally complex.

The developer freezes, gets stuck, or accidentally overlooks some premises.

Developing in one vs multiple steps

Unlike other activities (like writing) where I begin with a draft and revise it until I am comfortable with it, I prefer developing on a single step.

What does it mean? I try to write a clean code that works and performs well at once. The benefits:

• Less time writing and rewriting
• Less chances of introducing errors in the multiple iterations
• I train my mind to create well-performing, clear, working pieces of code effortlessly.

That approach satisfies the 99% of my developments.

However, once in a while (very unfrequent while), I face exceptionally complex problems, which don’t come out naturally from my head.

I found myself fighting not only with the problem but also with creating the most clean, reusable, performing logic to solve that problem. The result is clear, and I saw it happen multiple times (to many colleagues, as well):

We get stuck and think hard about all the possibilities without making any progress. The blinking cursor on the empty screen reminds us how frustrating our day has been.

In such situations, the best strategy is to switch the approach and develop the solution in multiple steps:

1. Diagram and write a logic that makes the program work. It doesn’t matter whether I have multiple nested ifs, lots of useless variables, or do the same actions multiple times. My only goal is to make the logic work.
2. Once it’s working, I make it more readable by restructuring it, reducing the number of variables, and removing or merging extra logic.
3. Only after it’s clean, I tweak the performance and take care of the excessive lookups, select statements, extra fields, and logic iterations.

Performing this step-by-step process will give me some material to work on.

When the problem is complex, It’s easier to adjust something than to take care of every detail before starting to write.

Conclusion

Although most experienced developers prefer to create working, clean, and well-performing programs at once, that approach is a nightmare when facing an exceptionally complex development.

In such cases, starting with a working logic without considering its readability or performance is the best way to avoid freezing due to being overwhelmed.

Once the program works, you can improve it by focusing on readability and performance to deliver an excellent product.