How to be Productive

Table of Contents

How to be Productive

I have recently come across a beautiful infographic by Anna Vital.

I have been a productivity enthusiast for ages, but my approach has evolved over time, so it’s time to make some kind of summary here. When I look at the elements in this great mind map, I recognize almost all of them. Most of them I have tried, and many I still use. But now, I view such things differently than I did ten years ago. Back then, they were just a bundle of handy hints that I read from time to time, and they didn’t mean much to me — just like all those fancy “good practices” that everyone knows but very few apply. It was a time when I was hungry for fast solutions — easy ten points that would change my life. But they didn’t, of course.

Because important changes require time. They require patience and perseverance, which are increasingly uncommon these days.

It took me almost a year to figure out how to manage my anxiety through workouts, such as running, with all the nuances needed to do it effectively. And believe me, I’m a smart guy, so the delay wasn’t due to stupidity.

I spent almost a year to REALLY experience what it means to focus on important things and suppress the urgent. Most organizations don’t do this, even if they claim to. It’s not easy to tell your customer, with courage in your heart, “We will not do this under these conditions, within that timeframe.”

It took me a couple of months to start making conscious decisions about healthy eating, to understand and feel the consequences.

I tried at least ten times before I gave up staying connected with the news.

It took me TEN years before I really understood and experienced that lack of sleep is disastrous and contrary to any productivity goals.

And so on and so forth. All that stuff because unpracticed knowledge is just noise.

After those ten years, I realized that the most important thing is to slow down and give yourself time. Important changes require time, and you cannot accomplish them in fast-track mode. Many books and trainers promise us quick results, but remember, it’s just marketing.

I recall that ten years ago, I loved such lists because, as a tech guy, I liked having short lists with the most important information. So I read them, but nothing lasted in my head.

They are great as reminders if you practice all this stuff, but not particularly helpful for incorporating into a daily routine when you’re starting. You need at least a book on each subject, or better yet, attend training, and after that, practice it for months. Then you’ll succeed.

There is one revelation when you have a deep understanding of a rule after long practice: you don’t need that rule at all. You have it built-in and know exactly when to apply it and when to break it. But that comes with time. No shortcuts.

Finally, there’s an obsession with productivity, but we must remember that productivity is the opposite of creativity. As a knowledge worker, you cannot be productive 100% of the time; otherwise, you just become a reflectionless robot.

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

Related Posts

Systematic Approach to Automated Software Testing with Vertex Testing

Systematic Approach to Automated Software Testing with Vertex Testing

Many automated test suites suffer from complexity and maintainability issues. In this article, we examine common testing pitfalls and introduce Vertex Testing—a structured approach that enhances software testing practices by focusing on domain behavior.

Read More

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

  • You focus on the features of your IDE instead of the features your client/user needs.
  • You consider typing at the keyboard as thinking.
  • You waste countless hours manually testing your code.
  • You spend more time struggling with frameworks than delivering value to end users.
  • You code for hours without asking yourself, “What am I really doing?”
  • You naively believe that technologies and tools will solve your problems.
  • You naively believe that a good algorithm is more important than a good understanding of requirements.
  • You naively believe that your intuition is enough for writing good code.
  • You naively believe that you can manage the complexity of the system piece you’re working on.
  • You agree to unrealistic deadlines.
  • You write poor code and rationalize it with various excuses (because there is no time).
  • In your head, you create code snippets without really knowing what needs to be done.
  • You guess what needs to be done rather than clarifying.
  • You mindlessly follow the technology you use.
  • You don’t understand the tools and technologies you use.
  • You isolate yourself in your piece of code, breaking contact with the world.
  • You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Read More

Trust in the Team

The Importance of Trust in Agile Methodologies

One of the main values of agile methodologies is trust. However, it is not always clear what this means.

Read More