Hope you enjoy the read, let me know what you think about it in the comment below or get in touch on Twitter,

Tom

Optimal configuration for a coding editor is a tricky thing. On the one hand, you want your main working tool to stay lean and fast; on the other hand, there are many cool things out there you might want to try. Have too little, and you are missing out on an opportunity to enhance your workflow. Add too much, and you end up with slow startup times, lower performance, and random things ruining your focus. All of which leads to miserable development experience. When you reach this point, you know that Plugin Creep already set in.

What is Plugin Creep?

Plugin Creep occurs when you keep adding new plugins/extensions to your editor. It’s a gradual process that turns your editor into a resource-hungry, hard-to-work-with, and difficult-to-maintain mess. Plugin Creep can affect any software. When writing this post, I noticed the term used in one of the WordPress communities. WordPress is known for the millions of plugins you can use to handle anything you need. It’s also known for getting extremely slow—surprisingly fast. The regression is proportional to the number of plugins you install.

Why does it happen?

Here are the most common reasons why Plugin Creep happens:

• Resource Consumption: Each plugin, regardless of size, requires some amount of memory and processing power to function. As the number of plugins increases, this cumulative demand strains your system.

• Code Overhead: Plugins are essentially extra code that your editor needs to load and execute. This introduces overhead, especially with poorly optimized plugins, leading to slower startup times and potential lag during editing.

• Compatibility Conflicts: Plugins aren't always designed to work perfectly together. They might interfere with each other's code or compete for the same resources, leading to unexpected errors, crashes, or strange behavior within your editor.

• Dependency Issues: Some plugins rely on specific versions of other libraries or software components. Over time, as plugins and dependencies update, maintaining a compatible and functional setup becomes a complex juggling act.

As you can see, Plugin Creep is mainly a problem of accumulation. A single plugin will have negligible impact, but the combined effect of multiple plugins adds up. Each plugin brings its own resource demands and potential conflicts.

Why Plugin Creep is Dangerous

Plugin Creep can quickly snowball into a serious issue. If you keep it unchecked, it can seriously hinder your productivity. Here’s how:

• Performance Degradation: Each plugin adds to the overall resource consumption of your editor. Over time, this can lead to slow startup times, lag during editing, and even crashes, especially on machines with limited resources.

• Stability Issues: Compatibility problems between plugins can lead to unexpected crashes, errors, or strange behavior in your editor. Debugging these issues can be time-consuming and derail your daily work.

• Feature Fatigue: With a plethora of features at your fingertips, it's easy to fall into the trap of "feature fatigue." You might spend more time configuring than actually coding.

• Maintenance Burden: Keeping plugins updated becomes a chore. New features might break compatibility with your current setup, and conflicts arise as plugins evolve independently.

You need your editor to be fast and sharp. Somebody might say that you won’t even notice a few milliseconds of difference in startup time, but it adds up. The slower your editor is, the easier it gets to get out of flow and lose your focus.

What can you do to avoid it

Here is a set of things you can do to avoid Plugin Creep.

Use built-in tools

Most modern editors come packed with powerful features under the hood. Before reaching for a plugin, you should at least try working with built-ins. Invest time into learning built-in features, reading documentation, and learning keybindings. The best way to avoid Plugin Creep is to eliminate the need to install new plugins.

You might be using the wrong editor

Sometimes it might be better to look for another editor. If you notice that your tool of choice wasn’t made with your workflow in mind, maybe there is something out there that will suit you better. A lot of problems people encounter when over-configuring software come from the fact that they try to make it what they would like it to be, and it might have never been designed to support their way of working in the first place.

Take your time to find tools that suit you and easily integrate into your workflow. Don’t use something only because everybody is doing it. Find your own way. You will be using those things daily - invest time into building your toolbox.

Audit things you install

Before hitting install, take a closer look at the plugin.

Review the opened issues. Are those being addressed? You don’t want to step on an issue that won’t ever be solved. It doesn’t mean that the plugin needs to be actively developed. Some of the best plugins I used had no new commits in the last 4–5 years. They just do the job, and there is no need to change them. You can rely on their stability.

What’s the development and user experience philosophy behind it? If you build the core of your workflow around a plugin that changes often, your workflow will be subject to frequent changes as well.

See what the community thinks about it. If there are no opinions about it, there is a high chance you are a beta tester, and as any pioneer, you will pay the price for it.

Focus on the problem

Before rushing to install plugins, step back and truly analyze the problem you're facing. Is there a gap in your editor's native functionality? Maybe you are missing something in your workflow. What if you wrote a simple function to do the job?

Clearly defining the core problem will help you determine if a plugin is truly the right answer, and it can guide you toward selecting the best solution rather than just piling on more features.

Don’t fix what’s not broken

If you have a mature workflow and tinkering around with your editor config isn’t your thing, it’s completely fine to just leave it alone. Don’t fix what is not broken. Even after I moved from Vim to Neovim, I used my old Vimscript-based config for years before rewriting it to Lua. It did the job fine and worked well.

Load plugins when they are needed

Many editors offer the ability to selectively load plugins. I don’t load most of my Neovim plugins on startup and only load them when I first use them. You can also load plugins per file type, or on certain events. This significantly reduces background overhead and can make a huge difference in your editor’s performance.

Prune your config

Your editor is a piece of software, and you should treat it as any other tool in your stack. When you notice it’s slowing down, don’t ignore it. Spend some time to see why and whether you can eliminate the problem. The sooner you do this, the better. Sometimes it will be as simple as updating plugins or removing the ones you no longer use.

If you let it accumulate, it will become this terrifying piece of mud you don’t really want to touch, and in extreme situations, you might need to declare editor config bankruptcy and start over.

Learn to debug your editor

Most modern editors offer amazing tools to debug their behavior and performance. It’s worth looking into it and learning how to debug yours. It’s equivalent to being able to do some small repairs around your car. You might not need it if you are a casual driver, but every professional truck driver will tell you it’s essential for their profession.

Final word

I’ve spent countless hours changing my Neovim config. When I first started to work in Vim, I learned the hard way that overloading it with plugins is a bad idea. Not only does it become slow, but you also end up not using most of it because your brain can only process a limited amount of new things at any time. I hope this article will help you avoid my mistakes.

If you'll enjoy reading this post and would like to stay in touch, please subscribe to my newsletter.

Hope you enjoy the read,

Tom

I was always fascinated by project dynamics. Whenever I have an opportunity to better understand why some projects fail and others are delivered on time and budget, I’m eager to take it.

That’s why I was very curious about “How Big Things Get Done” by Bent Flyvbjerg and Dan Gardner. Flyvbjerg is a leading expert on megaprojects. Together with his partners, he created a database of big projects and their performance. Based on this database and vast experience working with megaprojects, they try to explain why some of them fail and others are successful.

Book is packed with valuable lessons and examples. The authors effectively use case studies to illustrate both failures and unexpected successes. It does a great job of showing what sets successful projects apart from those that drag for years.

My favorite idea from the book is the importance of modularization. I always paid attention to repetitive areas of my work that can be packed into easy-to-describe procedures or even better - automated, but I wasn’t aware how big a difference modularization plays when it comes to project management. If you are able to split your project into simple repetitive blocks, delivering something huge is as simple as building many simple things. However, if you are building something huge that is unique or bespoke, you are most likely in for trouble.

What’s also great about this book is that it can help with projects we all need to manage in our lives. Kitchen renovation, building a house, planning holidays. Most ideas from the book translate well to those projects and can help you get through them smoother, on time, and on budget. This book will be a valuable read for project managers, leaders in large organizations, and anyone embarking on significant personal endeavors.

Thanks for reading!

If you enjoyed reading this post and would like to stay in touch, please subscribe to my newsletter.

Tom

I'll spare you the details, but the gist is this: after a challenging six months, my journey with the company (let's call it Company A) came to an end, and I was let go. Company A was looking for junior with some more applicable skills, and I was missing those skills. It was a simple mismatch of expectations, but for me, it felt like a small end of the world.

I was lucky enough that the other company (Company B) I previously interviewed for was still interested and wanted to hire me. Before I joined Company A, I took part in demo day at Company B where I worked on simple tasks with more senior developers. I made a good impression, they offered me a job, but I liked the Company A more and decided to go this way. After Company A let me go, Company B was happy to take me in.

I joined Company B with a completely different mindset to the one I had when joining Company A. My imposter syndrome hit the roof, I questioned my choice to change profession. I exaggerated all my mistakes and lost most confidence in my skills and choices. I was under a serious amount of stress and I could feel it.

At the same time, this challenging period, while tough, was incredibly motivating. Determined not to repeat past mistakes, I dedicated countless hours to learning and becoming self-reliant. I was fortunate to have a CTO who had a great process for training junior developers, and helpful people in my team who patiently tolerated my countless questions. Looking back, I couldn't have asked for a better environment to kick-start my programming career.

Even after gaining independence and confidence in my work, the motivation from those early struggles stuck with me. To this day, I strive to bring value quickly to new teams and make myself useful as soon as possible. I still learn after hours, and try to be better at my profession.

Reflecting on it, my experience at Company A was a wake-up call, a mix of fear and realization. I knew I never want to go through something similar again. I'm aware I don't always control everything, but I'm dedicated to do everything I can to make things work, within healthy boundaries.

This part of my programming journey, though difficult, has been valuable. I'm happy it played this way, it shaped me as a professional, and helped build good habits. It also made me more cautious when interviewing.

If you are going through something similar remember, however tough and groundbreaking it seems, it's up to you what you will do with it. With a bit of luck and a lot of grid, you can come out stronger on the other side.

• What should backend be written in? I recently picked up Rust, and it would be great to battle test it.

• Should this be API + client or monolith? I was tempted by Next.js as I wanted to try it for some time, and it offers a bit more sensible development experience than pure React.

• Where should I host it? I thought about using AWS as it would be a nice learning opportunity.

At some point, I realized that I couldn't answer these questions without understanding why I wanted to build this project. I knew that my project's features can be implemented with any tech I choose. Now I needed to set my own priorities, and realize what's in this project for me. The main thing here was understanding that I really care about getting this project to production. In the past, when I built something, it was because I wanted to learn or try new tech. This time, I cared about putting it out into the world.

Phrasing this as my highest priority simplified a lot of things. Now, having multiple options on the table I could simply ask myself "Which one will allow me to ship faster and not hate myself in the future if I need to extend it?". I still going to learn a lot from building it, but at least 80% of stack is familiar, which with limited resources I have gives me a good starting point to get where I wanna be with this.

As for decision itself I decided to go with Ruby on Rails. Why?

• Ruby <3

• it's framework I know best

• it offers great development experience

• it's made with bootstrapped projects in mind, perfect for solo/small team development

• with web views I can use it to develop mobile apps and I might need it for my product

• monolith just makes sense for solo development, I don't wanna jump between repos

• it's a good opportunity to dive deeper into Hotwire (a modern HTML-over-the-wire solution)

Of course Rails comes with some downsides but if I experience major ones it will mean that my project is at a stage where it is successful enough, and those are good problems to have. First I need to get there and Rails is the fastest way for me.

As for other tools, I'm gonna stick to Heroku for hosting to limit time I need to allocate into infrastructure management. Might move it to AWS at some point, but for now, my aim is to keep things simple and concentrate on development.

Let me know what is your decision process in similar situations.