Don't Be Too Quick, Start Thinking!

Table of Contents

Don’t Be Too Quick, Start Thinking!

Sometimes I feel like the world has become too fast. Everything happens so quickly that we switch to autopilot and stop thinking about why and for what purpose we are doing a task. Are we doing it in the way we imagined, or the way someone else suggested?

This is particularly dangerous in the work of a programmer, where we enter a trance-like state after just a few minutes, becoming completely thoughtless…

You might say: “This guy is talking nonsense – programming is all about constant thinking, coming up with concepts, solutions, verifying them. I have to connect ten libraries at once and consider the performance of my code. I’m always thinking!”

You’re right. However, it’s important to distinguish between a few things you need to think about to complete your tasks:

  • Why and for what purpose am I doing THIS - This is a crucial question, especially if you are working in a dynamic environment where tasks bombard you from all sides (e.g., maintenance, or in a development department that receives “loose” assignments from different departments). Is this task truly necessary? What will happen with the result of the work once I complete it, or if I set it aside with determination, will someone be upset? And if so, why? Is it just because you didn’t do this task, or because “someone’s life will be affected”? Often, even 30-40% of tasks are unnecessary. Yes! Do you know why? Because those who assign them do not have TIME to consider their sensibility. Of course, it’s not true that they don’t have time; they simply do not DEDICATE time to it.

  • How do I want to approach doing THIS SOMETHING - Often, what we need to do can be accomplished in many different ways. For instance, a particular functionality involving collecting complex information can be realized with a single form or a wizard. A service can be created using a few if statements or through the Strategy pattern. Is it worth resorting to this pattern or some other seemingly elegant (but also flexible) solution when, upon reflection, no one will ever revisit this code? Conversely, is it worthwhile inserting a few if statements if it’s known that, as the application develops, new versions of algorithms will be introduced that will operate differently? Would the Strategy pattern be more appropriate in that scenario?

  • How do I want to execute THIS - this pertains to which classes, libraries, constructions to use, and how to write it.

At best, on autopilot, we only answer the question of how we specifically want to execute THIS. This leads us into a whirlwind of problem-solving, jumping from one idea to another, considering thousands of details. It’s faster this way. But in this case, fast means thoughtless. You do a lot, and quickly, but WITHOUT MEANING (or at least without analyzing the purpose of the task itself - HA!).

Don’t be too quick, start thinking :)

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

Read More

Building Knowledge in Teams: Main Mistakes and Strategies

Building Knowledge in Teams: Main Mistakes and Strategies

The topic of knowledge management in teams is largely overlooked by IT leaders. There is a silent assumption that it happens automatically. To some extent, it does, as programmers are accustomed to constantly learning to stay ahead. However, this is not sufficient. It’s not enough for everyone (or realistically, half) to learn individually. If the team is to be effective, cohesive and up-to-date knowledge is needed. Knowledge of new technologies or solutions holds limited value compared to this.

Read More

Time for Assertiveness Training!

The Importance of Assertiveness

In my previous post, I discussed assertiveness in the context of time management. Upon reviewing various situations I’ve encountered, I can confidently assert that a lack of assertiveness (including appropriate communication) is the root cause of many other project issues.

Read More