Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It takes a PhD to develop that

blog.royalsloth.eu

Post reply on HN
Print view View original

61–70 of 429 posts

Re: It takes a PhD to develop that

#61

Post by strogonoff »

eloisant wrote: post #46
cornel_io wrote: post #31

Earlier quoted context omitted.

That sounds like you've never seen performance of a heavily worked-on subsystem increase by 10x because one guy who was good at that kind of stuff spent a day or two focused on the problem. I've seen that happen at least 10 times over my career, including at very big companies with very bright people writing the code. I've been that guy. There are always these sorts of opportunities in all but the most heavily optimi…

More generally, in my experience performance isn't looked at because it's "good enough" from a product point of view. "Yes it's kinda slow, but not enough so customers leave so who cares." Performance only becomes a priority when it's so bad customers complain loudly about it and churn because of it.

There’s a bit of incentive misalignment when commercial software performance is concerned. If we presume customers with tighter budgets tend to be more vocal and require more support, and customers on slower machines are often customers on tighter budgets, the business as a whole might actually not mind those customers leaving as it’d require less support resources spent on customers who are more difficult to upsell to.

Meanwhile, the majority of customers with faster machines are not sensitive enough to feel or bother about the avoidable lag.

Re: It takes a PhD to develop that

#62

Post by dmitriid »

lstamour wrote: post #28
onion2k wrote: post #7

A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking. I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove'…

Reading the thread itself, it’s a bit of both. Windows Terminal is complex, ClearType is complex and Unicode rendering is complex. That said… https://github.com/cmuratori/refterm does exist, does not support ClearType, but does claim to fully support Unicode. Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2 and (b) it sounds like the Windows Terminal project is indeed a bit more complicated than can…

> Unfortunately, Microsoft can’t use the code

I commented on a separate issue re: refterm

--- start quote ---

Something tells me that the half-a-dozen to a dozen of Microsoft developers working on Windows terminal:

- could go ahead an do the same "doctoral research" that Casey Muratori did and retrace his steps

- could pool together their not insignificant salaries and hire Casey as a consultant

- ask their managers and let Microsoft spend some of those 15.5 billion dollars of net income on hiring someone like Casey who knows what they are doing

--- end quote ---

Re: It takes a PhD to develop that

#63

Post by masswerk »

CogitoCogito wrote: post #29
cryptica wrote: post #11

PhDs often make the worst possible developers. People with PhDs (especially in Mathematics) are often lacking the most critical characteristic of a good developer; they don't know why they do things. Being good at math requires being able to solve problems whose solutions often do not have any practical uses or whose practical uses may not be clear. This is very different from how software problems should be approach…

> Being good at math requires being able to solve problems whose solutions often do not have any practical uses or whose practical uses may not be clear to you. This is very different from how software problems should be approached. I don't really agree. Being good at mathematical research requires recognizing the "core organization structure of a system" and solving the "core problem at hand". I'd argue that it's es…

However, there are probably infinite organization structures describing a complex system and there isn't any ontological reality to Occam's razor. Programming is really much about deciding where and at what level to allocate partial structure, which again informs the broader picture of the core organization – and some of this may be even intuitive.

Re: It takes a PhD to develop that

#65

Post by AndrewThrowaway »

holoduke wrote: post #60
AndrewThrowaway wrote: post #52

Earlier quoted context omitted.

A bit out of topic but has anybody followed performance issues of Microsoft Flight Simulator 2020? For more than half a year it was struggling with performance because it was CPU heavy, only loading one core and etc. Barely ran on my i5 6500. Fast forward half a year, they want to release it on XBox. MS/Asobo moves a lot of computation on GPU, game starts running smoothly on the very same i5 with maximized quality se…

Because a rule of thumb is to not focus too much on performance in the beginning of a project. Better a completed project with some performance issues, than a half product with hyper speed. The key thing with development is to find somekind of balance within all these attributes (stability, performance, loo, reusability etc) In case of FS simulator. Not sure what the motives were. Sure that they had some serious time…

Completely agree on rule of thumb and can't doubt they had their motives. It is no way that simple.

Then again isn't it like 101 of game development?

Imagine releasing a game that looks stunning, industry agrees that it pushes the limits of modern gaming PC (hence runs poorly on old machines). Fast forward some time - "oh BTW we did it incorrectly (we had our motives), now you can run it on old machine just fine, no need of buying i9 or anything".

Re: It takes a PhD to develop that

#66

Post by jiggawatts »

AndrewThrowaway wrote: post #52
jiggawatts wrote: post #20

Earlier quoted context omitted.

This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all. The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] an…

A bit out of topic but has anybody followed performance issues of Microsoft Flight Simulator 2020? For more than half a year it was struggling with performance because it was CPU heavy, only loading one core and etc. Barely ran on my i5 6500. Fast forward half a year, they want to release it on XBox. MS/Asobo moves a lot of computation on GPU, game starts running smoothly on the very same i5 with maximized quality se…

I'll reiterate a rant about Flight Simulator 2020 here because it's on-topic.

It was called "download simulator" by some, because even the initial installation phase was poorly optimised.

But merely calling it "poorly optimised" isn't really sufficient to get the point across.

It wasn't "poor", or "suboptimal". It was literally as bad as possible without deliberately trying to add useless slowdown code.

The best equivalent I can use is Trivial FTP (TFPT). It's used only in the most resource-constrained environments where even buffering a few kilobytes is out of the question. Embedded microcontrollers in NIC boot ROMs, that kind of thing. It's literally maximally slow. It ping-pongs for every block, and it uses small blocks by default. If you do anything to a network protocol at all, it's a step up from TFTP. (Just adding a few packets worth of buffering and windowing dramatically speeds it up, and this enhancement thankfully did make it into a recent update of the standard.)

People get bogged down in these discussions around which alternate solution is more optimal. They're typically arguing over which part of a Pareto frontier they think is most applicable. But TFTP and Microsoft FS2020 aren't on the Pareto frontier. They're in the exact corner of the diagram, where there is no curve. They're at a singularity: the maximally suboptimal point (0,0).

This line of thinking is similar to the "Toward a Science of Morality" by the famous atheist Sam Harris. He starts with a definition of "maximum badness", and defines "good" as the direction away from it in the solution space. Theists and atheists don't necessarily have to agree with the specific high-dimensional solution vector, but they have to agree that that there is an origin, otherwise there's no meaningful discussion possible.

Microsoft Terminal wasn't at (0,0) but it was close. Doing hilariously trivial "optimisations" would allow you to move very much further in the solution space towards the frontier.

The Microsoft Terminal developers (mistakenly) assumed that they were already at the Pareto frontier, and that the people that opened the Github Issue were asking them to move the frontier. That does usually require research!

Re: It takes a PhD to develop that

#67

Post by TeMPOraL »

Yup, this. Something I've been ranting about[0] for a while: there is no technical progression ladder. The Senior->Principal-> ... path seems to be a faux-management track, with all the managerial responsibilities and little of the authority. Software is shitty in big part because it's mostly written by juniors, as almost anyone who has any clue moves over (or gets pushed over) to managerial or faux-managerial roles.

I've been thinking about a more charitable interpretation of this recently. Another thing I rant about[1] is that tools we use for programming are not expressive enough. It takes too much work to say simple things, the coding feedback loop is ridiculously long. So how this connects? In a way, junior programmers can be seen as a Mechanical Turk version of a Sufficiently Smart Compiler - it lets the more experienced people skip some of the tedium with the tooling and deal with higher-level concepts, which get translated to actual code by an army of juniors and interns. Except, this doesn't work that well - the coding feedback loop is even slower.

--

[0] - https://news.ycombinator.com/item?id=27417462

[1] - https://news.ycombinator.com/item?id=28568053

Re: It takes a PhD to develop that

#68

Post by spectrumone »

holoduke wrote: post #60
AndrewThrowaway wrote: post #52

Earlier quoted context omitted.

A bit out of topic but has anybody followed performance issues of Microsoft Flight Simulator 2020? For more than half a year it was struggling with performance because it was CPU heavy, only loading one core and etc. Barely ran on my i5 6500. Fast forward half a year, they want to release it on XBox. MS/Asobo moves a lot of computation on GPU, game starts running smoothly on the very same i5 with maximized quality se…

Because a rule of thumb is to not focus too much on performance in the beginning of a project. Better a completed project with some performance issues, than a half product with hyper speed. The key thing with development is to find somekind of balance within all these attributes (stability, performance, loo, reusability etc) In case of FS simulator. Not sure what the motives were. Sure that they had some serious time…

True. Performance is not issue if no one is playing it.

Re: It takes a PhD to develop that

#69

Post by Azsy »

otheracc wrote: post #21

Hm... It's totally okay, to not be able to do it. Nobody can know everything. Doesn't mean you are in a "lower" category compared to your colleagues. Okay, it's not a global problem (ie. "needs PHD") but just a personal problem (ie. "I have no clue how to solve it"). Trying to get as much stuff done as possible, I've said similar things in the past, though. Not really thought about it before typing. Happens... Nobody…

Nobody here seems to be focused on the specifics of the case. But i think moving on would leave a great opportunity to re-evaluate corporate SE choices.

At the very least we can agree its a good thing that the dev was able to fork/re-implement the tool with the given API.

But for me it raises the larger question. How useful is this form of software engineering management?

The tool is relativity simple enough to re-implement ( Which is a good thing ), but at the same time an entire team/governance structure was put in place to act out a set of motions, without pushing what is possible.

To be blunt, it sounds miserable to have to work like that.

Re: It takes a PhD to develop that

#70

Post by oakfr »

zohch wrote: post #40
oakfr wrote: post #34

It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way. Leadership is a lot more than about "shuffling paper" in an "ivory tower". As a lead (in any decent company), you get to participate in critical design reviews; you get to read and review code; you get to shape the trajectory of others; you get to participate in discussions with the product teams. If you work smart,…

> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way. It saddens me to time and again be stuck with "leaders" who don't know what they are talking about and think they need to weigh in on everything, even though they add negative value when they do so, because they want to justify their mostly pointless job. In a 14 year career, I have had "leadership" that is not co…

Of course we have all met people who were pompous, arrogant and ignorant.

But there are some good and outstanding leaders out there. If you never had the chance to meet one (or did not recognize them when they were in front of you), I am sorry for you.

Post reply on HN