I just had another discussion with a reviewer (by way of an editor) who insisted that I cite (presumably their) work buried behind an Elsevier paywall. How obnoxious can you be?
It is 2019 and there are still editors and reviewers who consider articles, which are not freely accessible on the web, published research? That’s so wrong. Such work has been buried behind a paywall. It yet needs to be published.
Any non-trivial university has a legal department, often several (at least one for matters of teaching and one for matters of fundraising). The legal department concerned with teaching has to protect the university from lawsuits by students. By extension, this department protects students from professors who ask too much of them. Often, there may be good reasons for this. Sometimes it gets in the way of effective teaching.
Most people believe that scientists first perform basic (“fundamental”) research and then perform applied research. Basic research delivers the fundamental insights that then get detailed and refined as they hit reality in applied research. Along with this comes the request that basic research funding should be provided by the country (because few companies would ever pay for it) before industry kicks in and supports applied research. Nothing could be further from the situation in my engineering process research.
Abstract: The aim of this project outline is to describe how universities and other higher education institutions (HEIs) can work with businesses to conduct teaching projects for and with students. Both parties stand to benefit; the projects generate recruitment, outsourcing and innovation (ROI) for businesses and provide HEIs with new partners for cooperation, a source of funds, and a boost to the attractiveness of their teaching.
Keywords: Industry university collaboration, research-to-industry transfer, business model, teaching
Reference: Dirk Riehle. “The Uni1 Project (2016).” Friedrich-Alexander-Universität Erlangen-Nürnberg, Dept. of Computer Science, Technical Report, CS-2018-05. Erlangen, Germany, 2018.
I received five somewhat random review requests this morning, from the same journal, suggesting to me that the editor finds it hard to acquire reviewers for submissions. I pity the editor and feel bad for them (but they really should stop working for Elsevier). In any case, I five times essentially provided the same response, which is:
As mentioned in a previous blog post, my Ph.D. students are often experienced software developers who take on the role of a chief programmer in the development of the software system supporting their research. In this work, at any point in time, each of my Ph.D. students is typically supported by 2-7 Bachelor and Master students who contribute to the system under development. Taking a long-term perspective, my Ph.D. students develop quality software rather than throw-away prototypes.
The chief programmer idea is key to making such work successful. While I usually conceive and direct the research, the size of my group has led me to let my Ph.D. students take care of any actual development themselves. (Usually…) In this role, as the chief programmer, they become the central point of coordination and integration of engineering work. In academia, this is a necessity, because an engineering dissertation is typically a multi-year project, while final thesis students, the main source of junior programmers supporting the chief engineer, are only around for six months. Thus, the chief programmer becomes the central technical hub and provider of sustained knowledge of the system under development.