2coffee.dev

The first one or two years after starting work are often the most energetic period in a programmer's career. I could imagine many ways to solve a problem, and even think about which approach would be the most "elegant". The reasoning was simple: if an approach was recommended and used by many people, it must be the best one. A piece of logic that initially looked simple could become as thick as a burger after passing through several layers of thought, because a function had to pass through several wrappers to be ready to "cover" many future cases.

Writing code can be an enjoyable job. Solving a problem can lift my mood for the whole day, give me stories to talk about with colleagues, and let us analyze and dissect problems that seemed unknown to everyone else. Yet most conversations eventually come back to one question: "What about performance?" Getting the code to run is one thing, but have you ever asked how to know whether your code is good enough? Many people think that simply following Best Practices will automatically make it run as fast as possible. That is true, but not enough. If everyone were certain that their code was good, perfect systems would be everywhere. Whether code runs quickly depends on many factors, not just how it is written. People do not usually rely on intuition to judge whether a piece of logic is fast or slow. To prove it, they need data, or at least need to know which part of the code is taking time to process. Only after everything is laid out in front of them can they find a way to optimize it.

Profiling is a widely used

Over the past few days, I’ve switched from VSCode to using Zed for a few reasons. Zed is a code editor written in Rust, very lightweight, and its interface is similar to VSCode in many aspects. However, Zed still has its own differences and follows its own philosophy. Personally, I’ve used Zed since its early days; my first impression was that it was very fast and smooth. That said, many features I was used to in VSCode were missing in Zed, so I only stopped at the level of experimentation.

One feature I use very frequently is debugging with breakpoints: selecting positions and observing the data flow in the system. VSCode is a popular editor, so enabling debugging is much easier. It usually takes only a few steps, and especially if you use a framework, you can easily find guides online. In general, VSCode does a very good job of simplifying things for users.

Therefore, after switching to Zed,

This may be the last post in the basic MCP series on the blog. Originally I had planned not to write any more because the documentation for Prompts & Resources in MCP is very limited, but since these two topics are interesting I decided to introduce them to readers.

I have read and studied the material about these two items on the MCP main site. After understanding the principles and use‑cases, I looked for projects that have integrated them and intended to add examples to this article, but it turned out that very few projects actually implement these two components. Why is that?

In my opinion, a few