[Topolomancer]

Author here---I agree with the silliness of these categories, but I found no better way of phrasing this in an abstract manner. In the teams I mentioned in the article, it was super helpful to have that one colleague who knew a bit about software development, about running code in an HPC environment, about automated testing etc. Yes, these skills might be commonplace somewhere else, but in academia, they are typically not. Moreover, there are no incentives around for people to improve their knowledge in these tangential or broader areas. They might even be 'punished' for it later on since their research output ostensibly suffers.

[TheOtherHobbes]

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.

[Topolomancer]

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

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.