At one of my previous companies they hired two engineers specifically for performance. They were sharp guys. Problem was, they were put on their own team/silo and basically no one involved them in any of the work. Their PRs were considered more of an unpleasant intrusion into other peoples sprints. They became useless because of the terrible organization! Total wasted talent because "performance" was an afterthought in every respect.
It takes a PhD to develop that
281–290 of 429 posts
Re: It takes a PhD to develop that
#282Earlier 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'm not an experienced programmer but if I took all these maxims seriously...
If I don't think about performance and other critical things before committing to a design I know that in the end I will have to rewrite everything or deliver awful software. Being lazy and perfectionist those are two things I really want to avoid.
Re: It takes a PhD to develop that
#283I feel this is missing the elephant in the room, which is that experts are not interchangeable. They have typically specialized in whatever they have spent lots on time doing, and so developers in different sectors develop a lot of different skills that are typically not very useful for developers in different sectors. A result from that is that what may be trivial for people in one sector is hard for people in a dif…
[deleted]
Re: It takes a PhD to develop that
#284Earlier quoted context omitted.
> 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.
The hiring machine merely ensures that they can leetcode their way out of an interview and into the job. It doesn't care about what they're supposed to know :)
Re: It takes a PhD to develop that
#285Earlier quoted context omitted.
And he had a condescending tone from the beginning (as he always does). Maybe if he was more respectful / likable, the developers would have responded better.
Where? He started completely neutral here: https://github.com/microsoft/terminal/issues/10362 We live in a time where every competent developer is slandered in public if he isn't fully submissive to the great corporate powers.
I think the comment below in the github thread sums up the attitude of the developer. It's definitely not a "neutral" attitude. It's somewhat chip-on-shoulder and somewhat aggressive.
> Setting the technical merits of your suggestion aside though: peppering your comments with clauses like “it’s that simple” or “extremely simple” and, somewhat unexpectedly “am I missing something?” can be read as impugning the reader. Some folks may be a little put off by your style here. I certainly am, but I am still trying to process exactly why that is.
Re: It takes a PhD to develop that
#286Would 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 th…
If that's the case, they should really link those developments/retractions/apologies in the comments of that issue. The way the comments end in that issue is a really bad look, and there's no hint to the reader that there was any further developments, either in the code or the dev team.
Maybe, yeah. I don't have everything ready at hand but maybe take a look at:
https://github.com/microsoft/terminal/releases/tag/v1.11.242... (Latest release, check the PRs linked under performance)
https://github.com/microsoft/terminal/issues/10461 (Issue discussing rendering from a glyph atlas)
https://github.com/microsoft/terminal/issues/10462 (This is where one of the contributors quit)
https://github.com/microsoft/terminal/issues/10623 (Bullying example)
Re: It takes a PhD to develop that
#287I 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.
As the guy responsible for that comment (and the dev lead for the team! Hi!) I can say it haunts me pretty much weekly. My parenthetical-laden snarky sense of humor, my use of italics to indicate speech-like emphasis and pretty much everything else about that comment has been dissected to parts as small as possible.
In the end, though? Yeah, I was completely wrong. I don’t know much about graphics engineering and I’m glad(^) that we were shown up by somebody who does.
I’ve been working in software for nearly 20 years, and I’m firmly in the “knows enough to be dangerous; doesn’t know everything” category the article is missing. It’s not, as some have characterized in this comment section, because I moved into leadership; rather, it is because there is not a single axis on which to measure all engineers. I’m inexperienced in graphics and text layout, and my critical mistake was not respecting the experience somebody else brought to the table. In other fields, perhaps I fall higher on the experienced/wet-behind-the-ears scale.
(^) I may flatly disagree with his presentation and his group of fans taking every opportunity to slander us, but I’m happy that it’s generally possible for us to improve performance and engineering efficiency using the technique he described. :)
Re: It takes a PhD to develop that
#288Yup, 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.…
This is well-said and resonates with me quite a bit. How do we build expertise in an engineering organization where the best engineers are incentivized not to engineer?
Re: It takes a PhD to develop that
#289Earlier quoted context omitted.
I was more responding to the article, which used that specific example as a jumping off point to talk about management structure in software development generally. I don't use Windows, but I do use Kitty terminal ( https://sw.kovidgoyal.net/kitty/ ) and from my interactions with that project and trying to get code ligatures working in my setup I've learned that terminals are really complex, both for technical and leg…
The ticket discussion brought to light that it is a rendering problem. The other person wrote a terminal renderer that has none of the performance problems and all of the required features. I would say the MS developers have been proven wrong.
Possibly the thread has been edited, but I see the original poster claiming that, and it seems a popular view around here, but I don't actually see the evidence that it actually happened in the thread itself. Are we talking about this thread?
Re: It takes a PhD to develop that
#290This reflects a lot of what goes on in Academia as well. Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career. "Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch.…
Some professors are humble though.
I had a Physics 101 professor who gave a test that had a problem involving blowing a fan into a sailboat sail. The answer to the question was supposed to be that the sailboat doesn't move anywhere because of Newton's 3rd law, but one guy in the class spent close to the entire exam on that one problem showing that it would slowly move forward using a conservation-of-momentum-based approach instead of a Newton's 3rd law approach. The TAs marked it wrong and he got a low score on the test because he spent so much time on that one problem. He tried to argue about it to the professor in lecture but the professor shut him down saying to come discuss it during office hours. So he made a demo using a pinewood derby car with a hand fan glued to it and brought it to office hours and proved that it would move forward. The professor was super humble about it and brought the demo to lecture the next day and publicly gave kudos to the student for challenging the status quo.