escience is about being bold enough to ask the right questions at the right time

The 2017 eScience Principal Investigator Day. Photography: Elodie Burrillon/HUCOPIX

Almost three years ago, I started working at the Netherlands eScience Center and I have gradually come to a better understanding of what the job of an eScience Research Engineer involves. The bottom line is that coding is the least time consuming part of my work. I’ll quickly list my job activities to clarify the main misconception.

The most important aspect of my work is being bold enough to ask the right questions at the right time.

Once a proposal is granted, a kick-off meeting is held and after that the actual work begins. During that first phase of the project the engineers have a first look at the code, compile it and run it. The engineers are usually confronted with a lot of aspects of the code that they cannot immediately fully comprehend, they have to work their way through it. This can be done either by trying to understand the most accessible or top level parts of the code or by producing a call graph depicting the interdependencies of the different modules comprising the software package. For an efficient-computing project the engineer will profile the code to gain insight into the main bottlenecks.

eScience Research Engineer Dafne van Kuppevelt discussing with Gijs van Dijck, Professor of Private Law at Maastricht University. Photography: Elodie Burrillon/HUCOPIX

But, guess what, during the next phase, which is the main phase of the project, the targets as described in the proposal may look only remotely achievable, obsolete, or less interesting than other research questions that came up. In other words, the project’s goals are moving targets and we continuously need to redefine our priorities. This occurs, of course, quite commonly when running any complex project. Hence, soon after a project starts, we need to evaluate, talk, discuss. Here are some examples:

• Asking the right questions at the right time: “Is this feasible within the allocated time?”, “Why do you want to do this?”, “I do not understand this.”, “I do not see how this work relates to the project goals.” and “Why do you want me to maintain this software package? Better versions of it have been developed and maintained by a large user community and are freely available”.
• Sparring with the Principal Investigator (P.I.). The P.I. has written the proposal, but it is not set in stone. It may not be recommendable to pursue every aspect of the proposal. During the course of the project, insights or flaws emerge that require measures. For example, the lateral impact of the software — the extent to which the use of the software will transcend the domain of the P.I. — may be compromised if the original proposal would be continued rigidly. In this case, meetings with the P.I. are required to guarantee the lateral impact of the software we develop.

eScience Research Engineer Arnold Kuzniar discussing with Jeroen de Ridder, Associate Professor at University Medical Center Utrecht. Photography: Elodie Burrillon/HUCOPIX

Continuous discussion with all stakeholders is essential

For eScience (or software) projects there is another aspect that involves a lot of communication: software design. We cannot define a software architecture without numerous discussions with all stakeholders. We need to know about the software requirements, the users, the interactions between the users and the software, its maintainability and interoperability. We need to keep a record of the outcome of all these discussions; they will turn out to be indispensable.

Of course, eScience Research Engineers are also programmers. One part of that is the coding of algorithms; this is mostly an individual activity. More time-consuming parts, however, are tasks related to programming, but at a meta-level. It involves taking care of software portability and sustainability, writing unit tests and documentation and implementing version control and continuous integration. These are tasks that we mostly not perform invidually, but in collaboration with other project team members, such as the P.I.

Now that you have worked your way through this blog, look at all of the above. It is a lot about talking, right? About clear communication, difficult conversations and being open about the problems that you are facing, the doubts you have: is this going to work, is this feasible? For me, being an eScience Research Engineer, the most important aspect of my work is being bold enough to ask the right questions at the right time.