the 200ok weblog

When you come across code that's hard to delete, consider carefully why you wrote that code in the first place. Reassess the role it plays in your repository. If it has served its purpose, let it go, with gratitude.

To choose what to keep and what to throw away, take each dependency in one's manifest and ask: "Does this spark joy?" If it does, keep it. If not, remove it from your codebase.

Effective refactoring involves only two essential actions: deleting and deciding what to name things.

Gathering all of your code in one place is essential to this process, as it gives you an accurate grasp of the technical debt you have accumulated.

If you installed it because it looked cool at the meetup, then it has fulfilled its function of giving you a thrill when you downloaded it. In fact, that framework has already completed its role in your life.

To truly cherish the features that are important to your users, you must first discard those that have outlived their purpose. To throw away what they they no longer need is neither wasteful nor shameful.

There's no need to finish tutorials that you only got halfway through. Their purpose was to be built halfway. So get rid of all those incomplete repos.

We should be choosing what to .gitkeep, not what we want to .gitignore

It doesn't seem right to keep features we don't enjoy by hiding them in 'advanced options'. Break the habit of downgrading features into options if they don't thrill you.

Bundling just can't compete with deleting for saving download weight.

Imagine what it would be like to have a repo filled only with code that you really love. Isn't that image spellbinding? For someone who loves code, what greater happiness could there be?

It is not the number of dependencies but rather the amount of breaking changes that causes wrinkling.

Although it depends somewhat on the density of the code in question, you can fit from 20 to 40 pieces of gzipped code in the same amount of bandwidth required to download 10.

Reviewing dependencies after they have been upgraded is an opportunity to really notice them in all their details. Upgrading is really a form of dialogue with our libraries.

If you missed your chance to learn a particular framework, even if it was recommended to you or is one you have been intending to learn for ages, then this is your chance to let it go. Its purpose was to teach you that you didn't need it.

It is not our repositories but the coder we have become because of those past projects that we should treasure. This is the lesson these keepsakes teach us when we open source them.

Keep only those libraries that will make you happy just to see them in your configuration, the ones that you really love.

There's no need to finish blog posts that you only got halfway through. Their purpose was to be read halfway. So get rid of all those browser tabs.

As you run your cursor over the code, you pour your energy into it. The energy that flows from the cursor's caret into our code seems to heal both bug and build.

The true purpose of a pull request is to be received. Branches are not 'things' but a means for conveying someone's feelings. When viewed from this perspective, you don't need to feel guilty for throwing a branch away.

Functions that have been neatly folded have a resilience and sheen that can be discerned immediately, clearly distinguishing them from those that have been haphazardly indented.

The number of nodes should be adjusted so that the resource chart when standing on edge fits the height of your hosting plan.

Surely the person who raised the pull request doesn't want you to use it out of a sense of obligation, or to merge it without using it, only to feel guilty every time you see it. When you throw it away, you do so for the sake of the contributor too.

The first step is to visualise what the inside of your repo will look like when you finish. The goal should be to organise the codebase so that you can see where every module is at a glance, just as you can see the spines of the books on your bookshelves.

Lines that slope up to the right make people feel comfortable. By using this principle when you indent your code, you can make the contents look far more exciting.

While you are refactoring, it may seem as though your codebase has become messier than when you began. This is normal.

The refactoring process provides a unique opportunity to understand what is most important in one's code.

Refactoring lets you not just clean the surface of your codebase, but really consider how you want to code and what relationship you want to have with your PMs, your users and the things that surround you.

Pick up every item visible in your video conference background, and ask "does this spark joy?"

Before you delete an old repository, say 'thank you'. Express gratitude for holding your files, then let it go.

Cruft has only two possible causes: too much effort is required to refactor or it is unclear where things belong.

Branches that you can't even place belong in the bin. The meaning of a branch lies in the excitement and joy you feel when creating it. In many cases, the features developed afterwards have already outlived their purpose.

Why did you never ship it? Was it because it didn't suit you when you spiked it? If so, and if you no longer write code of that same style, then it has fulfilled another important function. It has taught you what doesn't suit your use case.

When you come across containers that are hard to delete, consider carefully why you deployed them in the first place. Reassess the role they play in your registry. If they have served their purpose, let them go, with gratitude.