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 approached. Software development is more about finding the right problems than it is about solving problems; to find the right problems, you need to understand the 'why' in as much detail as possible. Every line of code should be easily justified by how it brings the system closer to achieve its purpose. 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. Detatchment from practicality is the worst attribute someone can have as a developer.
It takes a PhD to develop that
11–20 of 429 posts
Re: It takes a PhD to develop that
#12A 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 understand the scepticism about such claims, but Casey's renderer is not a toy, and handles a number of quite dificult test-cases correctly. He solicited feedback from a sizeable community to try and break his implementation. The code is vailable here: https://github.com/cmuratori/refterm
Re: It takes a PhD to develop that
#13> 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 read through the Github issue and can't find the prototype mentioned here. Can anyone link the PR/code if they know it please?
Here you go: https://github.com/cmuratori/refterm
Re: It takes a PhD to develop that
#14This would be a nice thesis. Unfortunately we have software like memcached, redis, nginx, Envoy, Kafka, Zookeeper, and more that come straight from professional programmers which makes this thesis more complicated than this post makes it sound. Perhaps Occam's Razor should apply here.
Re: It takes a PhD to develop that
#15It's a shame that engineers commit their time for free for the benefit of multi billion corporation. Why do they do it?
These corporations are not your friends.
Re: It takes a PhD to develop that
#16> 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 read through the Github issue and can't find the prototype mentioned here. Can anyone link the PR/code if they know it please?
FWIW he wrote it on the same day @Microsoft locked the issue to prevent further posts by non-Microsoft people.
Re: It takes a PhD to develop that
#17A 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.
My time library is so much faster and smaller than yours. Timezones? Nah, didn't implement it.
My font rendering is so much simpler and faster than yours. Nah, only 8 bit encodings. Also no RTL. Ligatures? Come on.
The list goes on.
Re: It takes a PhD to develop that
#18If you read the article, the author is discussing a conversation on Github and developer experience. The article isn't an indictment about academia (it doesn't even really come up at all).
Re the author's competence argument, given how complex software development is as a field, a better approach should be to always assume that there's a person out there who can solve a problem quicker and more competently than your guesstimate. Of course, you should also assume that they're not going to, and that you - with all of your issues, lack of experience, and general :/ 'iness - is the one who's either going to have to fix it or find someone who can.
Re: It takes a PhD to develop that
#19This would be a nice thesis. Unfortunately we have software like memcached, redis, nginx, Envoy, Kafka, Zookeeper, and more that come straight from professional programmers which makes this thesis more complicated than this post makes it sound. Perhaps Occam's Razor should apply here.
That software from a pool of millions of SWE across the world. And importantly this software created outside of corporate structures! I think these exceptions prove the rule.
Most SWE are working for companies that don’t make money reinventing architecture. Leading a bunch of people to use existing tools to sell something to customers is probably where most of the value comes from in SME world and probably most of the big company world too.
Everywhere I have worked the very experienced people are probably doing the “the same year repeated many times” rather than a pyramid of experience taking on more complex engineering challenges.
There is a lot of money in glue code.
Re: It takes a PhD to develop that
#20A 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] and was more correct than the Windows Terminal!
RefTerm 2 vs Windows Terminal in action: https://www.youtube.com/watch?v=99dKzubvpKE
Refterm 2 source: https://github.com/cmuratori/refterm
One of the previous discussions: https://news.ycombinator.com/item?id=27775268
[1] Features relevant to the debate at any rate, which was that it is possible to write a high-performance terminal renderer that also correctly renders Unicode. He didn't implement a lot of non-rendering features, but those are beside the point.