Hacker News Reader

I would argue that the majority of developers are juggling half a dozen tasks that need to be done ASAP and a simple quadratic solution was fast enough for the use case they had in mind and there definitely was no time to optimize for the case of invisible icons.

From the perspective of an individual developer that may be the case, but it's inexcusable for Microsoft as an organization.

There are still a lot of bugs, features not working at all in windows. So a feature that works but slowly in extraordinary (for most users) conditions is not prioritized.

If you want a bug-free os, you'll pay an extreme price in features or in dollars.

> There are still a lot of bugs, features not working at all in windows. So a feature that works but slowly in extraordinary (for most users) conditions is not prioritized.

Please don't pretend like Microsoft has rationally prioritized the feature/bug work on Windows. Microsoft is spending resources pushing ridiculously niche use cases like "3D Objects". Microsoft is also doing a bunch of duplicate work, for example, maintaining 2 different UIs for Control Panel even though the old one was fine. Maybe it's time for Microsoft to stop the endless re-designs just for the sake of "new is better", and maybe focus on fixing bugs?

You may be correct in the larger sense, but there will be multiple teams working on Windows, with non-interchangeable staff. Assuming anybody found this bug before, somebody on the Explorer team almost certainly will have rationally prioritized it.

Why? Would someone rationally get a bonus for fixing this instead of whatever quarterly promise they made to their boss? What's rational about fixing a bug that isn't threatening revenue?

They wouldn't. The person rationally prioritizing this bug will have put it somewhere down the bottom of the list. And that's how we find ourselves here, with the issue unfixed.

> If you want a bug-free os, you'll pay an extreme price in features or in dollars.

It isn't like Windows division doesn't make billions of dollars every year. Lack of resources is hardly an excuse.

I suspect in both features & dollars!

I've never really understood this mentality. It's probably a privilege thing, but I always argue for doing things the right way. I got fired for it once, but I live below my means just in case that happens anyways. I don't need much, and don't take on debt.

IMO, the kind of devs who do this shit are like union scabs: they make things worse for everyone else because they don't have the ability to stand up for themselves.

I can think of two reasons why this happened in the first place.

- Either it was good enough in low resolution screens, and algorithm just considered mature and nobody think about it after that.

- Or, it was implemented with "first commit which meets requirements wins" competition, and it just didn't get the attention it needed.

I'm like you, a big fan of "do it once, do it right", but not everyone understands how well-polishing something presumably small affects everything like a butterfly effect.

Some people just want to tick all the boxes and go home. There's no inherent wrong with this, but when combined with wrong constraints and incentives, these things happen.

This affects visible icons as well; the icons being invisible in the original report is just the icing on the cake.

I would argue that the majority of developers are juggling half a dozen tasks that need to be done ASAP , so they skim a bug report and mark it as irrelevant to the use case they had in mind, and there definitely was no time to read the bug report carefully and understand the core issue it was describing.

This attitude is why 98% of software is absolute dogshit. Have some pride.

I applied for a job at Microsoft recently. I had to take an online test which consisted of two medium and one hard leetcode problems. In one hour.

It took nearly 15 minutes to just read the problems and make a game plan. That left 15 minutes solve and code all of them up. Have you ever done a hard leetcode problem? In 15 minutes? If that’s the bar at Microsoft, I doubt their developers are computer science illiterate. That test was harder than any of the other FAANG tests I’ve done, online or in person. Clearly the icon code was delegated to some intern or perhaps a child of one of the developers, because the bar is stupid high there just to have a conversation with a hiring manager. And they don’t even pay that well.

Check out some of Dan Luu's writing. https://danluu.com/algorithms-interviews/ comes to mind:

> At the start of this post, we noted that people at big tech companies commonly claim that they have to do algorithms interviews since it's so costly to have inefficiencies at scale. My experience is that these examples are legion at every company I've worked for that does algorithms interviews. Trying to get people to solve algorithms problems on the job by asking algorithms questions in interviews doesn't work.

He goes on to talk about why this happens.

In my own experience [edit to clarify: not at Microsoft], if you lay out a piece of code as an algorithm problem that needs to be optimized, most folks will make short work of it. But it's quite common for folks to not realize something will be slow enough that they need to apply that kind of thinking. That's especially true if part of the algorithm is hidden behind some indirection: whether just a function call, a call into a library that feels "far away" in the codebase / is owned by a different team, or dependency injection.

Good article. I liked this quote:

"though big companies try to make sure that the people they hire can solve algorithms puzzles they also incentivize many or most developers to avoid deploying that kind of reasoning to make money."

Great blog, thanks for sharing.

It’s true that leetcode is a unfortunate fad of the times, and a lazy way to select candidates. I also know a number of people at Microsoft that couldn’t answer any of the leetcode problems I was given, yet extremely talented developers nonetheless. Fortunately because the system is automated, you can just reapply and take another test. Seems the questions are plucked randomly so with some luck you’ll pull a triple easy set.

That interview process doesn’t just select for people who truly understand algorithms at a fundamental level. It also admits people who are good at memorizing the solutions to hundreds of leetcode-style problems. It is likely better at selecting more of the latter than the former.

When I ask algo questions during interviews they’re always based on real problems that have arisen in our code. Making the question actually relevant to the job is both a better interview process overall and has the added benefit of instantly filtering out the memorizers.

> Have you ever done a hard leetcode problem?

Yes. I used to compete on CodeForces regularly.

> Clearly the icon code was delegated to some intern or perhaps a child of one of the developers, because the bar is stupid high there just to have a conversation with a hiring manager.

You're implying that the developers of Microsoft can't be computer science illiterate, because a computer science illiterate couldn't possibly pass through the recruitment funnel that you experienced. But we know this code exists. Somebody wrote it. Somebody reviewed it. Somebody tested it. Everybody involved in this process thought "yeah, this is good enough", when it's clearly not good enough. Anyone with as little as CS101 experience would not write crap like this in the first place, so it's really hard to argue that the developers at Microsoft are computer science literate.

The code was likely written in the early 90s when the barrier to entry was much lower. It was a time when thousands of icons on your desktop wasn’t a use case worth considering, much less testable. That seems more plausible than all the developers being illiterate.

That's not true at all.

Many many people save everything they touch to Desktop, so it builds up cruft over time. There are ancient jokes about it. And computers were slower then brute-forcing big-O complexity was less feasible.

And the "barrier to entry" gets lower as an org gross and needs to higher thousands of people and get less picky.

I'm sure that MS doesn't require people to ace the hard leetcode problem to get an offer. It's just there to provide a broad picture of algorithm memory and coding speed (which is a stupid metric, not a "high" metric).

> The code was likely written in the early 90s when the barrier to entry was much lower.

You're probably right about that.

> That seems more plausible than all the developers being illiterate.

I'm not saying all developers are CS illiterate, but most are.

>The code was likely written in the early 90s

This is easily falsifiable by running a test case (create 1000 icons on desktop) in windows 7, 2000, XP and 98.

It is of course good that MS has a interview process that favors really smart people. But it doesn't mean that automatically all the work at MS will be flawless. There is much more then that.

And people are even joking recently about this: https://i.redd.it/jhr5tv5ls2e61.jpg

Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're actively at odds with each other quite often.

> Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're actively at odds with each other quite often.

Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons.

It's the leetcoder who would have written the O(n^2) algorithm and figured it's OK because it passes all the cases thrown at it. A leetcoder doesn't optimize everything, just the thing for the problem they're facing today.

It's the person used to writing production code who would have stopped to think about the fact that the cases we tested with today may not be representative of the entire problem space.

Leetcode is throwaway code. Writing tons and tons of throwaway code is, like I said, not completely unrelated to writing good production code. To get good at coding, as with anything, it is necessary but not sufficient to code a lot. But this is the sort of thing that I'd expect a leetcoder to do in practice; to miss the real problems, probably because they were off hyperoptimizing something else that was irrelevant.

I don't understand why you're trying to make this argument.

You said:

> being good at writing good production algorithms certainly have some overlap... but it's not very large

I agreed with you, and noted that this specific case is an exception:

> Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons.

It seems to me like you're trying to take the most extreme position that's available in this discussion: you're trying to claim that being good at optimizing algorithmic time complexity ("good at leetcode") does not help someone at optimizing algorithmic time complexity in production, because there's some kind of mythical distinction between "throwaway code" and "production code". That distinction is not relevant here. Someone who is good at optimizing algorithmic time complexity in throwaway code is certainly good at optimizing algorithmic time complexity in production code. Just like someone who is good at riding horses is also good at riding horses on a sunny day. Or someone who is good at painting with acrylic is also good at painting with watercolors, if you compare to another person who doesn't have any experience painting.

> I would argue part of the problem is that the majority of developers are computer science illiterate.

Sometimes, but it’s certainly only part of the problem. I’ve seen these kinds of bugs from people who would “know better”, who understand what O(n^2) is and are entirely willing and capable of fixing these things when you point them out…it’s just that they don’t see them when they are writing the code, or they mispredict the value of n that the code will be used under. And this seems to be prevalent no matter how “production grade” the software is; I’ve diagnosed these in my web browser, filesystem, text editor…in many of these cases I know who the developers are and they are exceptionally talented, and yet these kinds of bugs still exist. I don’t think we can solve these issues without some sort of concerted effort to uncover them, which I would argue is a strangely rare skill.

> I would argue part of the problem is that the majority of developers are computer science illiterate.

While I wouldn’t argue against that...

Sometimes people who do know what they’re doing choose slow algorithms knowingly.

I implemented a way finding algorithm that works in O(n^4) a while back. Because I knew the specific use case we needed it for had a max of around 200 for n, and that I could run a brute force of all possible routes for that in less than a minute in unoptimised Python on my laptop, so that I could then cache all the results and just do a very fast lookup from a ~40,000 row database table in production. I was very very clear to everybody concerned that this solution was not a scalable general solution, but it worked like magic for what our customer needed.

You applied global optimization, which I wish we could do more often.

Part of the type system should encode how long the fn call is allowed to take.

Couldn’t agree more. I’m saving this post to send to the next person who expresses disapproval that I ask computational complexity questions during my interviews.

How has that person not gotten in trouble for writing terribly slow software at work yet?

I've met some developers with a good intuitive understanding of fast vs slow code and who simply don't have the vocabulary (Big-O and whatnot) to perform well in that kind of an interview.

If a person really couldn't write fast code though, they could also just never have been assigned anything performance critical, the issues could have been addressed before they had any impact (e.g., in code review), or there could be a host of organizational reasons why despite pushing excessively slow code to production the consequences to any one developer are minor, especially in the short term (I've seen all of the above).

Mildly off-topic, most of the accidentally quadratic code I've seen has arisen by building on top of something that wasn't designed to support it via some kind of miscommunication or leaky abstraction (and the rest from building the algorithm never imagining N could grow large enough to matter). E.g., somebody designed a type which could be instantiated with sorted data and then passed to other places with demanding enough performance guarantees to need sorted data, and the type checker would ensure that an unsorted array wasn't accidentally being passed places it shouldn't be. Somebody else saw a sorted data type providing an Add() method and thought that was perfect -- without any exotic performance needs they just blissfully assumed any of the many well-known average-case logarithmic algorithms was used for the implementation. Fast forward a little bit, and suddenly the instantiation of a large sorted data type is taking way too long because...drumroll please...it's bubble sorting!

That isn't to say that nobody was blameless per se, but lack of comp sci knowledge wasn't the culprit; it was some combination of poor communication, ambiguous type names, leaky abstractions, not performance testing, not verifying the behavior of the components you're building on, etc....

> When people realized this problem can't be solved by throwing money at it, the next suggestion was to artificially constrain n to be small enough that the program completes... It was at this point that I optimized the algorithm so it ran in O(n log n) or something similar. Something that we should have done from the start.

I had the exact same situation at my previous job. Heck, the CEO even sold it as an advantage of our system, highlighting how few data we needed to get good results. Except our results were crap.

I fixed that problem and many others, and left the job three years ago, but they are still selling their product the same way. Some times you really need a big amount of data to get good results.

Well it's probably there since Windows 3.0 or so.

not 3.0, but 95 or ie4 active desktop easily. i experienced this slowdown back then, and learned not to store many icons or files in the desktop folder.