I never assumed that PhD students can’t code. They can and they are pretty good at that. My point is that their incentives are in writing papers and running experiments that support claims in their papers, not produce reliable software. It might be reliable, but mostly it’s not. When we use tools build by PhD students, it’s usually when there are companies/startups built around it, and that is what I refer to as having skin in the game.
I’ve known people with PhDs in computer science (from a top tier school) that couldn’t code. Their research was all done in Matlab for simulations, modeling a biological process. It was a very specific set of skills required. And at the time, this person couldn’t have written a web front end to a database to save their lives.
Just because one is good at the theory behind CS doesn’t mean they understand software engineering. Similarly, because one is good at the theory doesn’t mean they can’t code.
They are two related, but different, skill sets.
and many graduates in freaking computer science can't read or write proofs, either
> They are two related, but different, skill sets.
exactly.
I think it would be valuable to enforce more crossover in our educational institutions, though. We should have clearer boundaries between computer science and software engineering, and then also require students (at every level) in each to do some study in the other.
Researchers should be in touch with the concerns and needs of ordinary programmers, and ordinary programmers should be capable of looking at the output of researchers to take good ideas and make them practicable and polished.
Sometimes the disconnect means research effort gets wasted and practical technology lingers on designs that serve it relatively poorly.
But of course software engineering and computer science are distinct and deep specializations.
Average programmer here. PhDs in computer science can't code.
Ok, it's an overgeneralization. And it's probably based on a flawed sample of job applicants that make it past HR screening to get to me. The base rate of applicants who can't code is disturbingly high, probably around 20%. (Not that high numerically, but given that they've passed pre-screening and have something impressive-sounding on their resume, it's too high.) The rate of applicants with a PhD in CS who can't code is way higher, probably around 60%.
Note that these tend to be fresh graduates. And it even makes sense -- most theses require just enough coding to prove a point or test a hypothesis. In fact, the people who like to code tend to get sucked into the coding and have trouble finishing the rest of their thesis work, which may start out interesting but soon gets way less fun than the coding part. Often such people bail out with an MS instead of a PhD.
(Source: personal experience, plus talking to people I've worked with, plus pulling stuff out of my butt.)
At the same time, many of the best coders I know have PhDs.
> Implementation and edge cases are the easy part, the hard part is design and algorithms.
Hahahaha. <Snarky comment suppressed, with difficulty.>
I agree that design and algorithms can be hard. (Though they usually aren't; the vast majority of things being built don't require a whole lot.) But the entire history of our field shows that even a working implementation Just Isn't Good Enough. Especially when what you're writing is exposed in a way that security vulnerabilities matter.
Though it's a bit of a false dichotomy. Handling the edge cases and the interaction with the rest of the system requires design, generally much more so than people give it credit for. Algorithms sometimes too, to avoid spending half your memory or code size on the 1% of edge cases.
Developing queueing theory doesn't make you a great coder for Kafka environments.
Working on file system design and new innovative data structures (a persistence and retrieval environment) has nothing to do with writing kernel drivers.
On the other hand, a lot of SE graduates dont want to code, because they think there should be code writing tools and frameworks and infrastructure and process.
They'll spend endless hours talking about those things and focusing on their own needs instead of the actual purpose of the code they're supposed to be developing.
Most production software (esp low level stuff like Kernel, filesystem) today is written and maintained by people having that work as jobs. I wish it was any other way. Also, what users expect from production software is way different than situation 30-40 years ago. An Operating sytem must work for different CPU, GPU. A bare-bones OS is basically a non-starter. I mean look at Haiku-OS or any of other operating system projects, for most part they have gone nowhere.
A filesystem is also fairly complicated piece and what we expect from a filesystem is different. Speed is good but that is not the only criteria and I am afraid it does take serious engineering effort (edge cases and all) to get it usable on today's hardware.
That doesn’t really apply here obviously. The BetrFS team has experienced members.