"I don't use PhpStorm", said the newcomer. "Vim is way better!".

Everything began with a banal event: a new PHP developer was just hired in the startup I was working with. I was curious, so I began to look what tools and IDE he was using, expecting of course the good old PhpStorm.

His answer surprised me. Vim?

For the next months, this sentence became my mantra:

"I will NEVER use Vim!"

Vim! This dinosaur! This boring terminal editor! It's so complex, nobody knows how to use it, except the ultimate nerd without life, girlfriend, or whatever real things!
How can he compares the wonderful PhpStorm with this relic of the past?

This was the beginning of my personal crusade against Vim. I tried to show my new colleague how a good IDE with tons of features could suit his needs even better than this... Vim thing.

It went on for months. The conflict was politely raging, showing to each other why our respective way was THE way. Then, something terrible happened.

A new Devops was hired.

He was using Vim.

They were now two against me. I needed more powerful arguments. I couldn't continue to fight against something I didn't really know. To prove the superiority of a full-fledged IDE, I had to try Vim seriously; I had to learn it, finding all its flaw, and bury it deep into the ground.

It was a big challenge for me. After all, the common wisdom agrees that Vim's learning curve was as steep as the Mount Everest. But I didn't have the choice. New weapons were needed to continue the struggle.

I began to edit config files with Vim, from time to time. I felt proficient in two weeks, while improving my typing technique.

Then, I used it for coding.

Then, I tried i3.

Then, I tried to use the terminal even more.

Then, I tried Arch Linux.

It was 5 years ago. I never used an IDE like PhpStorm again. I never reinstalled Ubuntu. I kept using everything I tried.

I never looked back.

The Dark Side of Habits

Nowadays, we see an awful lot of books about habits, routine, and self-discipline. These are powerful concepts for sure, which can change your life if you manage them carefully.

After all, with a good set of habits, you can move forwards to your goals. It can help to go after your strongest aspirations.

I try to follow a well established routine for years. It makes me productive and happy. I feel more deeply accomplished.

But habits are not always all good. We should avoid psychological dependencies, for example. I think about any form of drugs from cigarette, alcohol, sugar, to social media, or gambling.

Bad habits are not the only dark side. A habit is hard to build, and can be even harder to dump. We are so used to follow them, day after weeks after months, that we sometimes miss opportunities to experiment. We forget that a different solution could be more effective, more efficient, and more fun.

"If It's Working, Don't Change"

To avoid this, we should never forget that experimenting is the key for improving. If we don't explore, if we never try to learn new ways, we stagnate.

We all know the mantra "if it's working, don't change". Or "if it ain't broken, don't fix it". It's suitable when the cost of failure is too high. Experimenting on a production server, for example, is too dangerous.

But trying new approaches in a safer context can be beneficial. You can try a new tool or a new approach when you're bored at work, or when you think it can bring value. Prototyping is a good example of exploring new solutions.

It's difficult to have the knowledge necessary to succeed the first time in any creative task. That's why many professionals in many fields sketch their solution before implementing it; developers are no exceptions. To find this knowledge, experimenting is key. It helps you build incremental solutions.

Unique Development Environment

Everybody has the right not to like Vim, or not to use it. We're all different.

Writing, or coding, is an expansion of our thinking. Difference is a power in this context, because it increases our collective intelligence. Thanks to unique point of views, we create unique solutions.

It means that our way to get things done (our workflows) can be different, too.

However, it's not wise to criticize something when you never seriously tried it. In my case, I was blind by my habits when I went in my crusade against Vim. My eyes opened when I simply tried to understand how it works, and why Vim users were so passionate.

It showed me a better way for my needs.

Building Your Mouseless Development Environment

I was lucky to have such great colleagues who showed me a different workflow. For others to learn this way of working, I decided to write a book.

The goal is, for anybody interested, to:

• Learn a great deal about Linux.
• Learn about the shell, even if you never really used it.
• Trying and compose powerful tools to improve your workflow.
• Experience a different way of working.

I will never oblige anybody to use Vim. Or Arch Linux. But I encourage anybody to try these tools.

Maybe you'll fall in love with a Mouseless workflow, as I did. Maybe you won't. What I can promise you: it will be a journey where you'll learn a great deal.

If you want to follow the development of my book, you can subscribe to the newsletter on my landing page.