The headline doesn't accurately represent the content of the blog post.
It should be "GitHub's New Code Search is Bad for Finding __New__ Code". GitHub's new code search is great at finding code (a vast improvement over the old one), and as it is optimized for finding code independent of temporal aspects, it's not good at finding _new_ code.
Sounds like a good tradeoff to me, as there conceptually aren't any reliable/unambigous indicators of "when" attached to a piece of code (same as for authorship). Should it count when the commit was authored? Should it count when the commit was pushed to GitHub? Should it count when the commit was merged to the default branch of the repo?
I really don't like the tone of this post, particularly calling out a named employee for, as far as I can see, a perfectly fine response. It seems to me that the OP is the one who has taken an antagonistic tone on the feedback threads, even when GitHub are showing themselves as responsive to the feedback.
Go ahead and criticise a product, but don't call out an employee or make out that they are failing to fulfil your personal requirements.
I'm sure this is only a first version of the new GitHub search, and more features will come. Give them the benefit of the doubt.
I don't really understand why we are seeing more and more of these style of antagonistic blog posts (or comments here on HN).
Colin here (I'm the "named employee"). I don't mind being called out, FWIW. I'm proud of what we built.
We would definitely have implemented sorting by recency if it was trivial to implement. But as I said before, our data shows that it is infrequently used, and to scale our search index, we designed it in a way that makes this kind of sorting tricky.
Sometimes to ship products like this, tradeoffs have to be made, and I continue to think we made the right one. Nevertheless, it's good for me and the team to hear feedback like this so we can continue to improve the product.
I dunno, I've had my fair share of "Can you elaborate on why you want to" as a blow off technique in my software career. This isn't helped by the GH engineer originally suggesting no one needs this, then another employee chiming in with "Yeah, sorry about that. We've heard this feedback a lot...".
I can perfectly understand the frustrations of the author - its kind of absurd someone working on a search feature needing the reasoning explained for why someone might want the most recent results, especially when the old search had this feature. I don't work at GH and I don't require "elaboration" for this request - I understood the OP perfectly.
Agreed, but it's not notoriously hard to understand why recent results is useful - the use case is self-evident, and the new search has regressed - the old search could do it.
Because one thing we know for sure is that a couple of people posting to an issue is definitely and completely representative of the community, no possible way that MS has analytics showing how often queries get made to back up a statement like “vast majority”.
Yeah, this post is needlessly adversarial and hard to take seriously for it.
My experience with the new code search has really been the opposite -- though I don't need to sort by date. Otherwise, it's a huge improvement over their previous version.
It often missed what should have been exact matches. You could copy and paste a variable name or a string from the repo and the search would not find it.
Complex user interfaces in applications like MS Word and Photoshop are the result of many users only using a non-overlapping 10% of the program's features.
Many UI redesigns focus on the features that the majority use and less common features get deprioritized or cut. This could lead to product erosion over time and eventually to a product that no one wants to use.
It is difficult to find a good solution to this problem. Engineering involves making trade-offs with limited resources. The author of the article is clearly frustrated by the deprioritization of the feature they use. I believe they are overstating the severity of the problem when they claim the new search is "bad" because it doesn't fit their narrow use case.
However, Photoshop and MS Word remain huge successes despite their crushing complexity. Some part of that success is likely due to ensuring that existing use cases, even those that affect a small percentage of their users, are catered for in new versions of their products.
Note that there’s no contradiction between “hardly anyone uses this feature” and “some people have an important use case that requires this feature”. (If you’re a program manager for MS Office, that situation can be pretty much a daily occurrence.)
I’ve seen a lot of misuses of telemetry where people think product design can be reduced to a popularity contest.
This feels kind of premature to me. I'm enjoying the new code search. It has its issues, but who amongst us has delivered a perfect feature on day 1? It's already a big improvement over the old code search on UI enhancements alone. A team worked hard on this project, and crapping all over their hard work will only make them feel worse about it and less likely to have desire to improve it.
I'll take the opposite stance: I think this is a good fresh start in a new direction of code search at Github, and I can't wait to see what improvements they make as time goes on.
Code search is one of the best features theyve ever added, ive been in the preview for it over a year now. The fact it takes a little bit of time to index is fine
Another pet peeve of mine is that the search suggestions are not real links, so you can't middle click them. The ones that are links, bubble the event somehow and hide the suggestions immediately.
On the other hand, I love the new search. Old search was unusable as it wouldn't return results I knew existed. New search works like a charm for exploring a codebase without cloning locally.
It should be "GitHub's New Code Search is Bad for Finding __New__ Code". GitHub's new code search is great at finding code (a vast improvement over the old one), and as it is optimized for finding code independent of temporal aspects, it's not good at finding _new_ code.
Sounds like a good tradeoff to me, as there conceptually aren't any reliable/unambigous indicators of "when" attached to a piece of code (same as for authorship). Should it count when the commit was authored? Should it count when the commit was pushed to GitHub? Should it count when the commit was merged to the default branch of the repo?