It takes a PhD to develop that • Hacker News Board

Re: It takes a PhD to develop that

#41

Post by yetihehe » Mon, Oct 04, 2021, 7:53 AM UTC

cornel_io wrote: post #31

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'…

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…

I've made such optimizations and others made them in my code, so:

c) slow code happens to everyone, sometimes you need fresh pair of eyes.

Re: It takes a PhD to develop that

#42

Post by csande17 » Mon, Oct 04, 2021, 7:54 AM UTC

choeger wrote: post #10

Counter argument: If the experienced programmers stay where they are, software development will forever remain craftsmanship. A single developer can only tutor so many juniors. In fact, I think that teaching and encouraging to learn is the most important thing in SE. And that has to begin with leadership figures that don't believe their own knowledge gets obsolete after one year just because the latest framework got…

> SE should not be an art form. It should be founded in solid science and abstraction should allow us to keep our knowledge applicable.

Software engineering can never be anything but an art form!

A lot of fields of endeavor have both mechanical "science-based" components and creative "art form" ones. An inexperienced chef can get some productive cooking done by mechanically following the steps of a recipe someone else wrote--cutting up vegetables, operating the stove, and so on--without making culinary decisions of their own. Experienced chefs, though, come up with ideas for things to cook, which you can't effectively do just by following some procedure. You need to have some creative je-ne-sais-quoi.

In software engineering, we have no long-term need for the first category of people. Any programming task that doesn't require human creativity can be automated. (When's the last time you decided which CPU registers corresponded to which variable names in your program?) An effective programmer uses abstraction for precisely this purpose. They spend all day, every day on making the hard decisions, and they let the computer handle the rest.

This is why Enterprise Software Architecture techniques have always been and will always be doomed to fail. You can't have senior engineers come up with rules that junior engineers can just mechanically follow to write good code. If you could, you wouldn't need the junior engineers, since you could just tell a compiler or code generator or something to follow the rules instead. Everyone who works on a codebase needs to be capable of making good decisions about code, in a way you can't boil down to science and checklists, or the best they can ever do is waste their own time producing repetitive boilerplate.

Re: It takes a PhD to develop that

#43

Post by mwcampbell » Mon, Oct 04, 2021, 7:57 AM UTC

galkk wrote: post #37

cmuratori is great software engineer, for sure, but, god, this bug report poisons the well right from the start (see below). Also the report is actually quite bad, because 40x performance drop, that is stated, could be actually nothing. If something takes 1 millisecond instead of 25 microseconds (numbers from the head, to illustrate the point), it might be an issue, but also might mean nothing. This is the thing that…

> 40x performance drop that is stated could be actually nothing.

It isn't though. The performance difference between Windows Terminal and refterm is dramatic enough that he could demonstrate it in a video.

Re: It takes a PhD to develop that

#44

Post by mytailorisrich » Mon, Oct 04, 2021, 7:58 AM UTC

The github issue is a gem.

The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions.

The tone gets quite condescending towards him.

He gets out of all this with flying colours. He should consider adding that Github issue to his resume.

Re: It takes a PhD to develop that

#45

Post by willvarfar » Mon, Oct 04, 2021, 7:58 AM UTC

lmm wrote: post #2

This seems like giving up. The article is right about the problems but seems temperamentally opposed to actually fixing them. Number of people under you is a terrible metric in many ways, but it is at least objective (ish) and hard to fake; so is years of experience. If you take the position that programming skill requires years of particular kinds of learning and there is no way to assess whether someone with x year…

When you interview a line manager and he boasts that he led a team of 100 engineers, do you question that he could have done the job with 10 better-picked engineers?

You get what you measure. If you reward bloat, you get train wrecks.

Re: It takes a PhD to develop that

#46

Post by eloisant » Mon, Oct 04, 2021, 8:01 AM UTC

cornel_io wrote: post #31

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'…

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.

Re: It takes a PhD to develop that

#47

Post by thriftwy » Mon, Oct 04, 2021, 8:01 AM UTC

tasogare wrote: post #4

thriftwy wrote: post #3

Nope! It's just that in corporate world, developers rarely do what they think is relevant for them. The people who did Windows terminal probably cared a lot about COM or WinAPI or maybe CS, but I think it's fair to imagine how they were not fans of text-oriented interfaces. It just did not occur that they should be extracting last bit of performance here. People can type just that fast, after all.

Windows terminal is a shit show. The dev blogs posts are all about useless features such as image background while fundamentals like unicode input are still broken.

Like Windows Notepad. I suspect it was never designed for anything more than trivial cases, and then it never got requirements overhaul later in subsequent versions of Windows.

Re: It takes a PhD to develop that

#48

Post by joshuamorton » Mon, Oct 04, 2021, 8:02 AM UTC

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…

So have you met any good leaders? Or are you saying that good leaders are nearly impossible to find (and therefore perhaps the job is difficult?)

Re: It takes a PhD to develop that

#49

Post by tinco » Mon, Oct 04, 2021, 8:03 AM UTC

jiggawatts wrote: post #20

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'…

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…

And the experienced developer is Casey Muratori who is somewhat well known for being a very experienced developer. That makes it less likely that he doesn't know what he's talking about and is skipping over hard/slow features.

Re: It takes a PhD to develop that

#50

Post by galkk » Mon, Oct 04, 2021, 8:05 AM UTC

mwcampbell wrote: post #43

galkk wrote: post #37

cmuratori is great software engineer, for sure, but, god, this bug report poisons the well right from the start (see below). Also the report is actually quite bad, because 40x performance drop, that is stated, could be actually nothing. If something takes 1 millisecond instead of 25 microseconds (numbers from the head, to illustrate the point), it might be an issue, but also might mean nothing. This is the thing that…

> 40x performance drop that is stated could be actually nothing. It isn't though. The performance difference between Windows Terminal and refterm is dramatic enough that he could demonstrate it in a video.

And that is why I'm saying that initial bug report could be done better.

For example, out of curiosity I did the test from the last message: doing "cat big.txt" in WSL2. In Windows terminal it took 1.5s, but in Kitty terminal, that is running under wslg (same ubuntu version), it takes 0.34s. Powershell, from the other side, is awful (20-25s).