I have no plans of publishing them or making the open source, so it will not be a part of this metric. I believe others are doing this too.

The show had former detectives and police folks failing miserably. It just boils down to evidence.

The design overhead involved in determining the correct URL and HTTP method adds a layer of subjectivity to the design and bike shedding arguments.

I’m not a huge fan of Protobuf/GRPC either, if there’s a better alternative I believe RPC is the right approach for exposing APIs.

I also feel the tragedy behind its beauty. From what I've read, Gaudí dedicated later part of his life completely to it and he died poor and unrecognised, hit by a tram and mistaken for a beggar.

I also find them very developer-centric — testers get forced into upfront design work that doesn’t fit how they naturally test, and many struggle with it. I’ve had better results by expressing behavior directly and keeping UI concerns thin, instead of using a wrapper around page structure.

Switching to a standalone app helps me avoid that — fewer distractions, less wasted time. I’ve tried breaking the habit, but this is one reason I still prefer desktop version of the website.

What actually works is trunk-based deployments — keep main always deployable, and ship from there. Simple.

PRs, are underrated. They’re great for sharing context. You get inline comments, CI runs, you can test stuff in isolation by spinning up infra, and teammates actually see what’s changing.

Stacked diffs make juggling multiple PRs manageable. And yeah, PR reviews can slow you down, but honestly, I think that's a plus. Slowing down just enough to have another human look at the code pays off more often than not.

I think a lot of serious bird enthusiasts use this in the UK.

Here’s what worked for me:

Start with a solid project page – Focus on making your plugin polished easy to install and use via a project page. Good docs and instructions also drives search to your plugin organically.

Create useful content – Blog posts, guides, or even short articles that explain how and why you built the plugin something like behind the scenes. People read this stuff.

Use GitHub topics – Tag your repo well. People browse topics and trending pages. This is actually how one of our projects started getting noticed.

Submit to awesome lists – there are “awesome” lists related to IntelliJ plugins Java dev tools, AI tools send a PR to add your project. It’s a great way to get visibility among the right audience.

Be genuinely helpful in your niche – If your plugin helps with a common pain (e.g. repetitive Java boilerplate), hang out in relevant forums or threads (like here, Reddit, etc.). When you help someone, they’ll often check out your work.

See how it all goes and know when to move on, Good luck with your plugin.

Same here—I missed it the first time around and found it pretty weird when I finally watched it.

But on a recent trip to the Lake District, we ended up visiting a bunch of the filming spots, including the infamous telephone box in Bampton (still around and in good condition).

That kind of changed how I saw the movie—it started to feel more like a bunch of odd little vignettes, each with its own strange charm. My partner and her family are big fans and talk about it all the time, so it’s slowly grown on me. Definitely not a “one sitting” kind of film.

Honestly, that’s part of the fun for some of us, even early on. I’ve been playing guitar for a while now, and while I enjoy it, the repetitive nature can sometimes get dull. Exploring new gear and chasing different tones has been my way of breaking through those ruts.

Yes, it’s expensive and it eats into practice time — no doubt. But some of us are just wired to enjoy the experimentation. I eventually found a setup I really like, but I don’t regret going through the gear phase. It kept things exciting and helped me stay connected to the hobby.