Live data from Hacker News

It takes a PhD to develop that

blog.royalsloth.eu

31–40 of 429 posts

Re: It takes a PhD to develop that

#31
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 optimized codebases, most teams either a) just don't have the right people to find them, or b) have too much other shit that's on fire to let anyone except a newbie look at stuff like performance.

Re: It takes a PhD to develop that

#33
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…

I'm somewhere in the middle. I see software development as an art form, however it's not disconnected from its solid scientific roots.

Sometimes, the art part is for fun (i.e.: your weekend project), sometimes it's for pushing systems to the limit (i.e.: scientific programming, demoscene, or where performance is really needed).

In my case, the art is exploiting the hardware or the theory in a way that it works smoothly and very performant for the cases you have.

This doesn't mean the deadlines doesn't matter, and explicit, slow, but very robust code doesn't have its place. On the contrary, it has many places. We need to make the correct trade-offs to get our job done the best way possible.

On the mentoring side, training people is hard, because of both parties. Low ego, open mindedness and being open to being wrong is very important. I try to mentor some people around me, and I encourage them to go further than I did. Lastly, I find passing the "old way" to new generations very valuable. While these old ways are inevitably lower level and less hip, they're tried, stood the test of the time, and generally performant enough (or very performant in some cases).

Re: It takes a PhD to develop that

#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, you get free time that you can use to keep coding. All of this can be extremely rewarding.

You are not serving our domain by painting this kind of picture of leadership. The truth is, you can excel as a software engineer, but you can also excel as a lead. And none is better than the other.

I dedicate this message to the "wet behind the ears" people you are referring to who would never consider the role if they were to stick to this poor vision you're delivering.

Re: It takes a PhD to develop that

#35

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…

According to the Amdahl's law: Let the smartest do the hardest. According to the Gustafson's law: Add more work if you want to keep the others busy.

Re: It takes a PhD to develop that

#36

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 find this generalization a bit hard to believe. Good academic researchers should be obsessed with knowing why they do things. After all, researching the state of the art and identifying a knowledge gap is what they do. And they should also be quite good at documenting the how since they write a lot of methods sections.

Maybe not in mathematics as I have no idea what a math PhD thesis looks like but for all other fields I know I'd expect a good researcher to be exceptionally good at giving a reasoning for why they do something and also at knowing what other approaches were tried by other people and what the pros and cons are.

But I find the comparison PhD vs. developer a bit unfair. I agree that you become a better developer if you develop for 4 years instead of doing a PhD. Even in CS, a PhD entails many things that are not developing, namely writing papers, getting grant money, teaching etc.

However, I also agree with you that if the goal is to become a better programmer, a PhD is not the way to get there (imo).

Re: It takes a PhD to develop that

#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 requires clarification, from my pov.

Regarding poisoning the well: instead of writing

" Expected Behavior

Despite the increased parsing load, modern CPUs should not have a problem parsing per-character color escape codes quickly. I would expect the performance of the terminal to be able to sustain roughly the same frame rate with per-character color codes as without, and if there was a performance drop, I wouldn't expect it to be anything close to 40x. "

he could just write

Expected behavior

Frame rate of output with per-char color codes is similar to non-colored output.

Re: It takes a PhD to develop that

#38

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…

> PhDs often make the worst possible developers.

I personally don't agree.

> 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.

This is what a software or CS PhD makes you understand. You know the why's to the lowest level possible.

> 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.

In my experience it's the opposite. After I got mine, I realized that I can answer these "Why"s faster, infer my own knowledge and can write better code easier and in less time. The whole process got much entertaining too.

So, YMMV.

Re: It takes a PhD to develop that

#40
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 completely horrible for about 6 months, but that I still would not call good, at best it is mediocre. If only most "leaders" were wet behind the ears instead of bordering on grossly incompetent.

If people's experience of leadership is that it is almost always dead-weight, then the problem is that it is almost always dead-weight, not that people call it out for being almost always dead-weight.

And by the way, I have never met one person who thought they were a good leader that was even slightly so. People who think they are good leaders are almost invariably pompous, arrogant and ignorant.

Post reply on HN