Live data from Hacker News

It takes a PhD to develop that

blog.royalsloth.eu

251–260 of 429 posts

Re: It takes a PhD to develop that

#251
I'm not sure "It doesn't take a PhD, just years of experience" is quite the rejoinder the author thinks it is.

Aren't they both just ways of saying "It takes someone with a rare subset of highly specific knowledge to solve this problem"?

The MS person was saying "Sure, there's probably a way to make this faster but I don't have anyone on my team who knows how to do that. If I had the budget to go out and hire someone with a PhD maybe I could do it."

That then Casey Muratori could show up and do it in his spare time doesn't really refute that argument, does it? This is someeone who has spent years actually doing hardocre R&D work, and literally published techniques that advance the state of human knowledge in the field of GUI rendering[0]. His resume is kind of a living example of 'PhD, or equivalent professional experience'.

So sure, it might be nice if MS's career structure led to them having more Muratoris on staff, but I don't think the expectation that every product team should have one or two developers of that caliber on it is a reasonable one.

It IS a good argument for why MS should accept open source contributions, though.

[0] https://caseymuratori.com/blog_0001

Re: It takes a PhD to develop that

#252
From the linked article itself, I can attest to the constant push to move up into 'leadership' roles, particularly in some companies. I have stayed and worked as an engineer for 37 years. I have been 'team lead' a half dozen times, but never a full manager role. Why? Because I would be a poor manager. I have personally experienced managers that where technically brilliant, but not good at managing (or inspiring) the technical staff. They should have remained as engineers/scientists. Some corporations used to have parallel paths for technical staff that had management level pay and benefits, but the suits in the 'C suite' have eliminated that for the most part over the last twenty years. Bell Laboratories (now a shell of its former self) was once one of those places.

So in the current environment, there is constant pressure to move up or move out. Even startups are no longer immune to that. If you want to have enough shares for it to really matter in a liquidity event, you need to have a team of people below you, or at least a director level title. The startup environment in 2000 was completely different, and technically astute engineers (mechanical, electrical, software) could attract strong stock grants as engineers. That has changed. I am fortunate in that after 37 years of doing this, I am at a position where I don't even have to think about these issues any longer. I feel sorry for younger engineers breaking into the field, the management pyramid is such a PITA.

And back to the topic of strong technical engineers that are poor managers? If you get stuck into one of those situations, constant micro management, constant downward pressure of "you don't know what you are doing", get out. Find a new position elsewhere. Good managers will coach you when you need help, but will let you do your own work. Good managers will help identify your deficiencies but also guide you to work that plays to your strengths. Good managers will provide you opportunity for growth. I learned this early in my career, blessed with having an awesome manager. Since then, every job I have had, first thing I did was figure out which managers were good, and which ones were not, and made sure that I never had to work under a bad manager.

So you can make a career in engineering, but it has to be a choice, and you have to learn to manage your managers.

Also note, while I recognize that I would be a poor manager (for various reasons), mentoring is a different skill set. If you are a senior engineer, take every opportunity to mentor a starter in the field.

Re: It takes a PhD to develop that

#253

Earlier quoted context omitted.

https://i.imgur.com/WrsVwFz.png absolutely standard

well, whatever is different in your settings, mine renders normal https://imgur.com/dGI5W2S EDIT: I am sorry for the attitude, changed "wrong" to "different"

Their settings aren't wrong, just different, likely because of differing standards for digit grouping across locales. So this is a case that refterm clearly doesn't support. This case by itself doesn't invalidate refterm's approach to rendering, but I can see why the team at Microsoft, knowing that there are many such cases, would favor abstraction over the absolute best possible speed.

Re: It takes a PhD to develop that

#254

This is both annoying and understandable. For the dev team, to dive into this performance optimization would mean punting something else from their roadmap. I suspect they weighed their perceived chances of success against the projected cost and reached a certain conclusion which in retrospect seems wrong. The independent developer did not have that "hurdle" as he simply did this at the expense of whatever other fun…

I remember clearly when I first gained a real appreciation for the importance of measuring and considering your actual data.

I was trying to optimize a slow project doing some polyhedron dissection on large (~1M polyhedrons) meshes in real-time. As a first attempt I had my sights set on a function which tried to find a certain point on a surface by making an educated guess and then iteratively bumping its estimate in the right direction. I figured "I can solve this analytically instead!".

I did, and it made things approximately twice as slow. After scratching my head and outputting some data I realized my constant time solution required a number of expensive operations including sqrt and the iterative approach ran on average ~1 iteration and at most 3 iterations for just a handful of these millions of triangles.

Re: It takes a PhD to develop that

#255
post #84

Earlier quoted context omitted.

When I saw this mentioned on HN I immediately knew this kind of comment would be there because something along the lines and I am paraphrasing "its probably fast because its not enterprise enough" was repeated in every place the refterm was shared by different people even multiple times even after showing all the proof in the world that its in fact the opposite they almost refused to believe that software can be that…

Honestly, I felt like the ones to start with the condescending tones were the Microsoft devs who kept talking down to Casey about You Don't Understand How Hard This Is, when they also readily admitted they didn't understand the internals very well.

I don't think they're actually contradicting themselves there. They know enough about how hard text rendering is to conclude that they're better off delegating it to the team that specializes in that particular area, even though it means they have to settle for a good-enough abstraction rather than winning at a benchmark.

Re: It takes a PhD to develop that

#256
post #196

Earlier quoted context omitted.

Seconding. It takes doing some low-level gamedev[0] stuff, or using software written by people like Casey, to realize just how fast software can be. There's an art to it, and it hits diminishing returns with complex software, but the baseline of popular software is so low it doesn't take much more than a pinch of care to beat it by an order of magnitude. (Cue in the "but why bother, my app is IO bound anyway" counter…

I feel obliged to point out the destructive power of Knuth's statement, "Premature optimization is the root of all evil." I have encountered far too many people who interpret that to mean, "thou shall not even even consider performance until a user, PM or executive complains about it."

I feel like that quote spoke to a particular time. Nowadays I'd point at premature abstraction as the fount of evil.

Re: It takes a PhD to develop that

#257
post #145

Earlier quoted context omitted.

Seconding. It takes doing some low-level gamedev[0] stuff, or using software written by people like Casey, to realize just how fast software can be. There's an art to it, and it hits diminishing returns with complex software, but the baseline of popular software is so low it doesn't take much more than a pinch of care to beat it by an order of magnitude. (Cue in the "but why bother, my app is IO bound anyway" counter…

> There's an art to it while that's true, in this particular case with Casey's impl, it's not an art. The one thing that drastically improved performance, was caching. Literally the simplest, most obvious thing to do when you have performance problems.

That's part of the art. It's obvious to anyone who knows it and mysterious and ineffable to anyone who doesn't.

The meta-point is that corporate developers have been through the hiring machine and are supposed to know these things.

Stories like this imply that in fact they don't.

Re: It takes a PhD to develop that

#258
post #178

Earlier quoted context omitted.

The fact that Casey Muratori's proposed approach requires the terminal to reimplement the process of correctly mapping characters to glyphs - including stuff like fallbacks to other fonts - is a huge part of the argument for why it's much harder to implement and more complicated than he claims. If it really doesn't do that right for something as simple as a decimal seperator for the font some random HN commenter happ…

You can’t use a non-monospace font on a tiled space. Like that literally makes no sense. Of course it won’t look right. This is like asking why you can’t use `out` parameters on an inherent async function.

Whether the font is monospace or not isn't really the problem - that causes some aesthetically ugly spacing, but that's to be expected and it's still readable. The big issue is that the code has completely failed to find a glyph for one of the characters used in something as commonplace as a directory listing from the dir command and people expect better than this from font rendering in modern applications.

Re: It takes a PhD to develop that

#259
Would just like to say that:

1. WT is probably my favorite Microsoft product

2. Since this whole affair, the developers have apologized and corrected themselves which is usually unacknowledged in these discussions.

3. The developers have made a number of performance improvements since (most of which are in the latest preview release).

4. This episode is constantly retold and used to bully the developers even after these apologies and this has lead to one of the developers to quit (paradoxically one of the devs who after these posts made the most effort to figure out where the bottlenecks are).

Re: It takes a PhD to develop that

#260

I pity the developer (or maybe manager) at Microsoft who wrote the GitHub comment on which this article's title is based. (And no, I never met him when I was at Microsoft.) If he's in the Seattle area, he's likely not even awake yet, but when he is, I expect he's going to have a bad day. Assuming he's not already sick of the Windows Terminal versus refterm drama, it would be interesting to read his perspective.

Holy shit you sound annoying and wrong about Everything in this thread
Post reply on HN