This article is the first part of a series. Here I will be sharing my experience and challenges. In another post, I'll share the tools I have been using and more technical insight.

I realize how broad the question is and every developer probably has a different definition and experience. Still, after 10 years of making scientific software for different organizations, I'll try to share my version.

What's even a developer?

Like the first question isn't broad enough, I feel like going down the rabbit hole just a bit more; for once, it does not hurt.

To put it simply, a developer is a person who writes code to create pieces of software or applications. The debate may be heated on some points and the gate is sometimes well kept, but in my opinion, the following does not matter:

• whether you have a degree in computer science or are self-taught
• whether you write code using a web-oriented stack or lower-level desktop tech
• whether you prefer functional or object-oriented programming
• whether you've been doing it for decades or you are just starting
• whether you are passionate about code or it's just a job
• whether you are being paid for it or do it as a hobby
• whether you follow all the standards or do it your way
• whether you share your code or keep it secret

What matters is only that you write code regularly, that at some point is giving instructions to a machine.

Aren't we all doing "science"?

In a way, yes. We all play with numbers, bytes, perform some operations, and basic arithmetics are part of our everyday routine. There is always some logical thinking involved, we read documentation written by people who are more expert than us in the field, we are trying to tackle and this looks like what a scientist would do.

But now is the moment to scope it a little more. What I mean by scientific developer is not about developers also being scientists, but it's about the daily life of a developer who is making applications for scientists, researchers, and research engineers. This can be in the industry (public or private) or academia. Being a scientific developer is not about being better than other developers, it's about focusing on specific topics.

So what's the process?

Usually, a scientific dev knows less than his client about the specific field of study, so the dev will have to learn quite a bit about the science, the good practices, the standards, and the jargon before even starting to think about the software architecture. There is no rush for coding here, we first have to learn!

Staying humble

I'm not a big fan of the term "senior developer", I think it's vague. Is it after 5 years? 10 years? What about 10 years that include breaks and other career paths? And if it's 10 years, how to differentiate them from the dev who has been doing that for 35 years?

As a scientific dev, it does not matter how old and experienced you are, you always have to tackle a scientific problem with humility and a fresh mind. The scientists who are experts in their field may be younger than you, yet, it's their knowledge that you need to build the piece that solves the problem.

I am not saying it's an easy task as we (dev in general) sometimes feel super-powered because we can make a machine do stuff. Then the path is short to be thinking that we can solve problems without any help! And that's where the risk is. If the solution provided to a scientific team does not follow the standards in place or does not make good use of the jargon, this app is simply not going to be used (no matter how polite they are with you).

Don't take me wrong, we can do mistakes. We will do mistakes, and that's fine. Using a word instead of another, because we misunderstood the jargon, etc. All that is fine. What is not, is to code like a lone wolf, focus on what we thought was the goal, not asking for any information or feedback in the process.

This is the difference between a good dev and a ok dev, not the seniority. And in my opinion, it's a mandatory asset for a scientific developer.

To make sure this is clear, in a team that needs a scientific dev, the scientific dev will never be the star. The scientists are, the researchers are. They are the ones publishing scientific papers and sending satellites to orbit. That notion should be agreed before stepping into the institution, otherwise, go back to school, get a PhD, enroll in a postdoc, then another, and then be the scientist who needs a scientific dev.

Is it about science then?

Yes, and no. It's about being interested in science, getting familiar with the field of your colleagues, and understand some parts of it so that you speak the same language, whether it's about neuroscience, satellite imaging, or geology. Sometimes, this means attending to scientific conferences, reading scientific papers, knowing the big names, and more or less what they have achieved.

For this particular step, going to the university and having a degree in at least one scientific field helps a lot. I know this is very obvious and also very unfair. At the uni, no need to dig everything by yourself, no need to know what to know, it's all served to you. I sometimes think of it as the lazy way and I am in awe about people who are going back to studies late in their career doing all this curation and learning work by themselves. Yet, if you have enough curiosity, courage, and time, you can learn about many different scientific topics deep enough for little money. The resource for that is not lacking (Wikipedia, online classes, Youtube)

An example, maybe?

Sure. And the simplest for me is to share my own experience. Where I've been, what I've done, and what were my motivations.

First, a precision: as a French/European, I am lucky enough to have had access to free academic education, and even though my parents where always on this thin layer between working-class and middle-class, I did not have to get a job in addition to studying. At the time, I took it very much for granted, now, I know I was very fortunate.

From highschool to Masters

In France, you choose a path when you are about 16 years old. I took the scientific path with a major in life science, but still with quite a lot of math and physics. This led to having an end-of-highschool diploma (baccalaureate) that was generic, in a good way.

During high school, we never touched programming, it was not that common back in early 2000. Yet I was coding a bit on my own, trying to learn how ActionScript (with Flash 5) was working. And I like it so I thought, why not enrolling in a Bachelor in computer science. Which I did. I had the worst time of my life, I hated it! The pedagogy was terrible, teachers were assuming we knew C++ from the first class (and some did) and I psychologically quit after only a month and a half. The next year, I enrolled in a Bachelor of a field I knew better and that I thought would disappoint me less: life science. It was more fun, more interesting with a better pedagogy, and still came with a decent amount of math and physics. In a way, it was the continuation of high school, which suited me perfectly.

After two years, and a lot of dissected animals, I met a guy who was studying bio-informatics in another university, 2 hours away. He was in a Master's specialized in biological image and signal processing. This included programming (which I had a bad experience with but still wanted to do), signal processing (which I knew nothing about), learning about the medical imaging methods (MRI, x-ray, etc.), and still have a connection with life science. I was fascinated by what he said he was doing there! One of the requirements to enroll was to have a Bachelor's degree in life-science or computer-science and then committing to 3 additional years. I applied, got in, learned many cool things about signal processing, digital image processing, 3D reconstruction, algorithmic, programming, bio-technologies, and more and it paved the way for what was going to be the beginning of my career.

Since this moment, I have really enjoyed programming. Coding was suddenly a means to an end, there was a purpose and this purpose was not that it compiles. It was about building things. Beyond that, it was most of the time about building things that build things. For instance, one of our student projects was to write a piece of software that creates a mesh from a volumetric dataset (with marching cubes). It was fun and I loved it, though at the time I didn't know being a scientific developer was a thing and I only realized years after.

Fun is good, what about an internship and a job?

Medical imaging along with C/C++ programming along with the fact that I liked it gave me a direction of "where to look for a job". I was willing to broaden my job research but I was never willing to get rid of image processing or programming, both had to stay, that was the condition I imposed on myself. At the time, there was no way I apply for a job in a bank to code a Java backend (and it's still very true today). I wanted to remain close to the science, work hand-in-hand with scientists, learn from them, and code apps that would crunch numbers for a good cause (we all have our definition of "a good cause").

In France, a Master's degree can only be complete with a 6-months internship. I eventually found a rather big company in the city, Toulouse, to work on an open-source library for satellite image processing, and my task was related to remote sensing and hyperspectral imaging (from sensors with not only RGB channels but potentially hundreds of different wavelengths). The company I was working for was contracting for CNES and ESA which are the French and European equivalent of NASA. I was super happy to find this mission and those 6 months were super interesting. Not only I realized very quickly that coding standards at school were not the same as in an open-source project from the national space agency, but also that there were so many new concepts to learn from the scientific field that I would never be done reading documentation and picking the brain of my colleagues!

After my graduation and thanks to this experience on satellite imaging, I found a job in a startup that was more or less doing the same thing, and a year later in a big group that was doing exactly that, for CNES again.

After four years and a half of C++ in satellite image processing (and putting completely aside medical imaging), I think I can safely say that I was starting to get a grasp on it. Talking to my colleagues (scientists, engineers, and researchers) to make sure I am going to capture the right thing in order to implement what is going to solve the right problem had become a sort of second nature. With the jargon and the complexity of the discipline, if there is no discussion, it's easy to end up solving the wrong problem!

After that, my wife found a postdoc in Canada and since I was reaching a point where I needed a bit of change, I did not hesitate a second to follow her overseas! It was a big change, and the place we landed on was sort of rural and did not provide any opportunity for me to get a job I would like. That was not a big deal, I had some savings, my wife was working, and living there was not too expensive. Though, I would not call it a gap year! At this time, Javascript was getting crazier every day, developers where having JS framework fatigue while I hardly knew we could do interesting things with it!

I got into it, first the basics, then WebGL/ThreeJS. During my master's, we did quite a lot of low-level OpenGL for volumetric reconstructions and it seemed that WebGL could provide the same level of fun, but with the possibility to share it over the web! I thought it was quite fantastic and quickly looked for a job in Montreal where I could use my background as a scientific developer as well as my newly acquired skill of coding for the web tinted with computer graphics. I ended up working at McGill University, as a staff engineer in a large research lab part of the Montreal Neurological Institute. The team was composed of half researchers (including PhD students, postdocs, and staff), and half developers (interns and staff). The first group was doing research in cognitive neuroscience related to neurodegenerative diseases, aging, infant brain development, etc. where MRI and functional MRI were heavily used. The second half was developing apps to facilitate the processing of scientific datasets, whether it's about providing medical visualization apps (my case), align MRI on models, crunching numbers, launching jobs on supercomputers, organizing data, etc.

Even though medical imaging was originally my field, I had never actually worked in it before, so it was sort of new again and many things were yet to be learned! The fact that the team was composed of scientists and that their knowledge was suddenly super accessible was a great way to know about their intentions, their processes, and gain knowledge about brain science.

After two years of fun and learning, our working visa was coming to an end and we were running out of options to renew it. It was time to fly back to Europe. Once back, I was lucky enough to join a lab at Ecole Polytechnique de Lausanne, Switzerland, that aims at simulating some behaviors of the brain in order to (among other things) perform drug-screening in-silico rather than killing animals. This team, just like in Montreal, is composed of half researchers and half developers, working towards the same goal. In this very large and ambitious project, my part of the job is to work on building a brain atlas, an app where scientists and engineers from the lab can all push their data and display them in a referenced spatial context. This involves a lot of WebGL (shader code, linear algebra), data structure, data validation, getting into the format standards, implement parsers for those, get to understand what scientists want to do, etc.

One of the first things to do is to understand what scientists are doing, which is not always trivial! Then, some questions are triggered:

• What data do they need (input)?
• What data do they generate (outputs)?
• In what format?
• Are those format web-friendly or do they need some conversion?
• Among those data, which ones contain 3D coordinates?
• In other words, do we have a 3D mesh, something that is not directly a mesh but could be, with some effort be represented as such or maybe a point cloud?
• For data that does not directly have 3D coordinates but have a semantic description that is somehow space-related (ie. "thalamus"), what can we do to display it at the right place?
• Are all this spatial data projected in the same spatial reference? (Allen Mouse CCF? Talairach coordinates? MNI space?) And can we do something about it?

What did I learn?

In all my professional experiences, there was always a constant: picking the brain of scientists is mandatory! It's not always easy. Sometimes we have difficulties to understand each other and to determine the end goal. Sometimes we have different definitions for the same word, and sometimes we are using a different word for the same concept.

From my perspective, the most difficult is to explain to scientists why sometimes what they ask is not possible, generally because of performance issues or technical limitations: "I know you want to click and get that instantly, but we cannot make it realtime for the moment". It's frustrating because we all have an idealistic vision of how would the perfect app be. Then, it's also the opportunity to explain why those limitations exist and find workarounds together and by the same, share my expertise. Again, understanding each other is not just a "nice to have", it's a prerequisite.

Another aspect, more personal, is about having a will to learn new things. We all met people who consider that learning is over at the moment they get their first salary. In my opinion, it's the best way to become obsolete in less than five years. Developers, in general, must remain aware of the new tools because our world is still fairly young and things are moving quickly (which does not mean jumping on every bandwagon). In addition, scientific developers must learn about topics that are usually beyond their original scope, so it's better to be quite passionate about it, otherwise one may quickly feel overwhelmed.

— @jonathanlurie

Cover photo by Karina Kashuba

PS: This article was first published in The Post.