| That person is usually called a "developer." Historically, it's a technician's job. Of course it's super useful to have someone on an experimental physics team who can personally machine metal, blow glass, and repair broken electronics, but generally you try to leave that to specialists. The people who built CERN are not the same as the people who designed CERN are not the same as the people who did the research that made something like CERN plausible. Your attitude seems to be "Well - ML, web design, graphics, original research, it's all computers so why not?" There's a reason Peter Higgs didn't operate a concrete mixer, and that's because it wasn't his job. It's the same in CS. This kind of work should be handed over to someone who can work on it full time, so researchers can get on with research full time. |
That's not what I meant at all, though. I realise that my perspective might be specific to machine learning research: here, most papers involve implementations, prototypes, etc. My point could be boiled down to the following: if you have a candidate with fewer papers but _also_ some knowledge on how to, for instance, write clean code (or at least clean_er_ code), that candidate can be an asset _just as much_ as the candidate going into a Ph.D. with 10 first-author papers already. Both candidates cover different aspects of the research area.
I am saying that it's a good idea to look beyond `$num_papers` as a metric when hiring budding Ph.D. students, being well aware of their respective responsibilities. Current hiring practice in academia, as far as I can tell, completely ignores the skills _enabling_ excellent research. Earlier in the thread, someone mentioned this nice saying, which sums it up pretty neatly:
> The astronomers thought I wasn't that great an astronomer but a great programmer, and the programmers thought I wasn't a great programmer but a great astronomer.
One last thing I want to point out:
> It's the same in CS. This kind of work should be handed over to someone who can work on it full time, so researchers can get on with research full time.
Yes, I will definitely hire full time positions for this. The biggest groups are doing this already, probably because they realise that having a software engineer on board can help. I will apply the same considerations when hiring for such a role, trading 'depth' in favour of 'breadth' when it comes to their skill set, though. That strikes me as the right way of approaching this.