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

111–120 of 429 posts

Re: It takes a PhD to develop that

#111

Post by DrBazza »

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…

I have a PhD (physics), and I worked in a quant team with maths, physics, engineering and comp sci PhDs, and I can assure you the bell curve demographic is identical there as it is in a department of non PhDs. There are some very good developers, the odd mythical "10x" developer (in this case, someone that really just writes repeatedly same thing in every job to be honest), and some very poor developers.

> The PhD diploma itself doesn't have much practical use in financial terms; it's not a good investment to get a PhD for purely practical reasons.

I don't know if you say this because you have don't have one, or haven't worked with many (not just one) PhDs?

In the UK at least, your starting salary will be significantly higher than just a plain degree, and it also opens up a broader job market (in the City, at least, and aerospace and defense) where PhDs can be a requirement in some jobs because (junk) degrees are now ten-a-penny.

You learn writing skills, and analytical skills both of which are financially useful and practical.

I get the feel that what you're implying is that PhDs are less imaginative and perhaps less likely to be entrepreneurial. In that case, you may have a point.

Re: It takes a PhD to develop that

#112

Post by [deleted] »

jiggawatts wrote: post #73
ribit wrote: post #58

Earlier quoted context omitted.

I don't know about you, but I was really laughing out loud reading that GitHub conversation. GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time MS engineers: drawing colored text is SLOW, what do you expect P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can ren…

To be fair to the MS engineers, from their background experience with things like DirectText, they would have an ingrained rule-of-thumb that text is slow. That's because it is slow in the most general case: If you have to support arbitrary effects, transformations, ligatures, subpixel hinting, and smooth animations simultaneously, there's no quick and simple approach. The Windows Terminal is a special case that does…

[deleted]

Re: It takes a PhD to develop that

#113

Post by kevingadd »

ribit wrote: post #58
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'…

I don't know about you, but I was really laughing out loud reading that GitHub conversation. GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time MS engineers: drawing colored text is SLOW, what do you expect P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can ren…

Simply shaping text using state of the art libraries (like harfbuzz) can take an INCREDIBLE amount of time in some cases. If you're used to rendering text in western character sets you may think it can always be fast, but there are cases where it's actually quite slow! You get a sense for this if you try to write something like a web browser or a word processor and have to support people other than github posters.

Of course in this case it seems like it was possible to make it very fast, but people who think proper text rendering is naturally going to be somewhat slow aren't always wrong.

Saying that text rendering is "largely solved" is also incorrect. There are still changes and improvements being made to the state of the art and there are still unhappy users who don't get good text rendering and layout in their favorite applications when using a language other than English.

Re: It takes a PhD to develop that

#114

Post by mmis1000 »

jiggawatts wrote: post #66
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…

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

I though that it looks more like 'no one touches it at all after function part finished'. It is insane that someone still do decompress and downloading in the same thread and blocks download during unzip the resource in 2021. Even 2000's bash programmer knows you had better don't do them in order or it will be slow...

Re: It takes a PhD to develop that

#115

Post by TeMPOraL »

zurfer wrote: post #100
TeMPOraL wrote: post #67

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 really appreciate this perspective. Better tooling to enable individuals to penetrate more layers of abstraction sound great. To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever. However, I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.

> To some extend e.g. with cloud providers this is already happening. We have more powerful building blocks than ever.

This is not ideal though. Cloud services have a pretty short half-life, and trap you in business relationships that you shouldn't need just to build software.

(I know, I can't stop complaining.)

> I feel the idea of experienced vs. junior programmer is not helping this discussion much. Experience can also hurt to some extend, because you need to unlearn things.

That is true, but I still think the idea is sound - there's much more universal, transferable programming-related experience juniors gain than things they'll need to unlearn later. The problem I see here is that, just as those developers gain that experience, they get pushed out to management / faux-management. In principle, this should lead to at least some improvement in quality - as increasingly better people are tutoring the next generation and directing it - but I feel we've reached a fixed point in terms of software skill, with most software being written at a pretty low level.

Re: It takes a PhD to develop that

#116

Post by numpad0 »

> it seems to me that the software industry doesn’t value technical excellence as much as it values having warm bodies report to you

Naturally. Computers don't pay, these wet bodies pay progressively for values they perceive. Technology is merely an instrument to add amounts of currency value to products that it is to hold. Also, a business that relies on technical excellence of small groups of individuals is not a business well conceived.

Logical complexity impregnated into an artifact, logical or physical, is a completely separate phenomenon to currency values it holds within the system of human economy. Took me way too long to get it. The fact that the two are considered same is itself probably something worth discussions.

Re: It takes a PhD to develop that

#117

Post by kevingadd »

ezoe wrote: post #91

Other example of slow performance in MS is file system access and process creation.

fwiw, file system access is kind of a bad example - it's slow because the design allows people to hook into it. once you've made promises to end users that limits the kinds of optimizations you can do and how far you can go with those optimizations.

For one example, if you were to make file I/O bypass antivirus software in 'performance sensitive cases', few enterprise admins would accept that. That performance optimization would be disabled in a millisecond. You can do directory exclusions, but some of the I/O still has to go through the filter to be checked against the exclusion list.

Re: It takes a PhD to develop that

#118

Post by fellellor »

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…

I found it very funny that the Hindi sample text on display, in the YouTube refterm demo, means “You can wake up someone who is sleeping, but how do wake up someone who is hell bent on pretending to sleep?”.

Re: It takes a PhD to develop that

#119

Post by Jensson »

The worst part is that the kind of arguments he was met with is exactly the kind of arguments people use to get headcount and climb the ladder within corporations.

Spending a little time writing a well designed and fully working solution => Good job, now take the next ticket!

Spending a lot of time explaining why something can't be done with this budget => Promoted to manager!

Spending a year of time explaining why the project need a much bigger budget to deliver features => Promoted to director!

This is the main problem.

Post reply on HN