A scientist among engineers: how far are the two sides apart?
By: Serhat Kaya
Tags: New Opportunities, Career Advice, Science, Career Change, Engineering

There are things known and there are things unknown, and in between are the doors of perception. — Aldous Huxley, The Doors of Perception (1954)

People make decisions to have an influence, achieve their goals, make their lives easier especially when it comes to decisions about their careers. When I look at my very own decision history, I don’t see any of these reasons. In contrast, I see a bunch of irrational choices that could only be made by a crazy man. However, the consequences weren’t scary at all. I believe we can only see the world within our thoughts and the only way to make great changes is by changing our point of view. The picture you see in the aftermath could be outstanding. Perchance, you may even step into a whole new world.

You might think that this is a text about philosophy after reading the intro. Well, every topic can have a philosophical side yet this has a different goal. It has been almost two years since I have made one of my sharpest choices ever. I quit my Ph.D. in physics and joined Armut as a frontend developer which is one of the fastest-growing startups in Turkey. Since then, I was looking forward to talking about the differences between the methods of a scientific study and an engineering project for actual production. As I grow from a beginner to an experienced developer I think it might be the perfect time to enlarge the tiny slit and remove the curtains between the two disciplines.

The motivation of working: A tale of two cities

One of the cornerstones of my life as a physicist was seeing how science actually works under the cover. I had the chance to experience that in my first study. I was accepted to the Very High Energy Astrophysics Lab at Boğaziçi University as a student researcher when I was just a sophomore. Don’t let the term “Very High Energy” scare you. It just a statement to say that only the most massive objects (black holes, pulsars, etc.) and most energetic photons (gamma-rays) were in our interest. The project I was given there was about (fasten your seatbelts) the dark matter! The topic looks extremely impressive for a newbie. I was really excited about the project, but in fact, I couldn’t finish it on time because some other group published a coinciding study while we were struggling with the huge amount of data that we couldn’t figure out how to process. That was inexplicably frustrating. However, in spite of the failure my supervisors never showed negative reactions. At first, I couldn’t really understand their behavior, but I saw the underlying reason when I started to supervise undergrad students. They were rarely able to finish their projects successfully, but I never cared about the results. Most of those students went to the best institutions for their PhDs. I always knew they were going to be successful as I witnessed what they acquired. My supervisors stood calm and comfortable with my failure because they saw the experience I gained. I learned how to write code, analyze data, create a report, make a decent presentation, write scientific papers, and organize a whole project step by step. They knew they trained a new scientist who would make pioneering studies in the future. Failures are indeed the science that doesn’t get published whose real outcomes are the experience we gained.

Photo by Guillermo Ferla on Unsplash

Armut is my first work experience outside of academia. I was, of course, interested in programming before and I had some freelance jobs even when I was a student but being a part of a product and development team was never the case for me. Thus, my first challenge as a frontend developer was to understand the workflow rather than writing a complex component. The first task I was given was to develop a banner that would advertise our mobile apps because we wanted our users to use the apps more rather than the website. If I had a similar task now, it would probably take just a couple of hours to finish but back then I have spent a whole week. I was very welcome to fail of course, but I insisted to finish. I had a hard time placing the items correctly for different screen sizes. I always knew it was doable, there were plenty of people in the team who can do that, and somebody will answer my questions if I dare to ask. I had the feeling there was always somebody to save me when I stuck. In the end, my manager showed up and solved the problem in just a couple of minutes and told me that I shouldn’t spend too much time on such problems while she was always ready to help. That was the moment when I learned how the business supposed to flow: the tasks are doable and they were needed to be done in the shortest time. This is the main difference between science and engineering. When you are given an engineering problem you inherently know that it is possible to be solved and your main job is actually to find the easiest, the shortest, and the most suitable solution that gets the work done while keeping everything else unaffected. If you are about to fail then there is always somebody or something to cover your back. However, if that is a science project that you work on you have to understand every aspect of it no matter how hard it is and how long it takes. If there is no light at the end of the tunnel, you are on your own to open a new way. Other people can only provide you proper tools and suggestions that can make your job easier, but they can never solve your problems as if it is their own. Sometimes the solution is impossible by nature. In that case, the perfect action is to stop and go back all the way to the foundations and start over cause you might have made wrong assumptions at the beginning. This is what makes a scientific activity precious: to understand every piece of a problem is much more important than having a solution.

Photo by Florian Olivo on Unsplash

Problem-solving: confessions of a dangerous mind

I always find it mesmerizing how different the mind of an engineer and a scientist operates. It was actually really surprising for me to realize the ignorance of the people against each others’ fields. An engineer does not really know how their scientist friends think and vice versa. They are aware of each others’ existence but they have no idea about the others’ driving dynamics. If you get a physicist and an engineer (any engineer will do) there is one way to see the difference: asking them how many stars there are in the universe. The engineer is probably going to find it very difficult and unreasonable but in the end, s/he can come up with an answer like “If the universe is infinite, the number of stars it contains should also be infinite”. This is an acceptable answer because as long as the number is extremely large, it won’t have any effect on how we develop things. On the other hand, the physicist can easily see what the problem requires and starts to solve (if you are interested, the mass density of the universe d x the volume of the universe V / the mass of the sun M gives a close approximation which is 10 to the power of 22). As a single physicist inside a group of engineers, I experienced these different mind states from the inside. In research groups, we used to have everlasting discussions about almost anything. Everyone was willing to find the correct answers regardless of their everyday benefits. From the possibility of building a planet accelerator to the probability of a fly dropping in a glass of water every topic was worth discussing for us. Being able to have discussions about almost everything was our duty and joy. However, I discovered this ability is so uncommon and strange for most engineers when I questioned the shape of a teaspoon during a lunch break. For them, it does its job very well so we don’t need to question. But for me the picture was different (Seriously, why did we make a tool for mixing the sugar in the shape of a spoon instead of a stick?). This contrast in thoughts makes science mysterious and fantastic in most cases while keeping engineers on safe grounds. Scientists can choose any topic to work on and publish, but it is an engineer's job to make them available for everyday use.

Collaborations: individuals vs teams

How a project is structured and carried on is where the real difference lies. In a company, the main goal of the work is always conducting projects that increase the profit in the shortest time and with the least amount of effort. This leads projects to be more concise, less complex and much more efficiently planned. That is why teams are organized autonomously in a way that they can survive on their own. If one of the product teams fails to serve their features on due time other teams are not affected and can keep their own projects going as planned. Product development methodologies like SCRUM and KANBAN bring about this aforementioned agility. However, it is impossible to keep track without proper meetings because each individual should integrate the work of others into his/her task and that requires decent communication. Although having a lot of meetings can be a waste of time cause some topics might not at every developers’ interest, the requirement of gathering is inevitable because the individuals are not the owner of the problems, teams are. On the other hand, in the academy, every member of the team conducts his/her own research which rarely coincides with others’ jobs. Instead of giving autonomy to the teams, individuals have their own responsibilities so if a project fails at some step which happens very often it constitutes a problem only for the responsible person. The only blocker that may occur is about the usage of common types of equipment like a microscope or supercomputer which there can only be one at each institution or university. Meetings are only necessary to keep every member of the group updated about each others’ works. Other than that, it is the name of the researcher which will be written to the journal at the end rather than the name of the company.

Photo by Hannah Busing on Unsplash

Communication: the curse of the fame

At first glimpse, the communication within groups looks better on the engineering side but if we talk about communication as a community you can’t find any better environment than the academy. One of the best things I love as a physicist is how easy it was to reach some other scientist in the world. My emails were rarely left unreplied when I requested a data set or asked questions about their researches even if the person I contracted was a so-called celebrity. Just during my undergraduate years (keep in mind that I got my basic science training in Turkey) I have met Joselyn Bell, Alexander Filippenko, and Charles Lineweaver in person. Either they or their supervisors were awarded with the Nobel Prize (I also attended a talk given by James Dewey Watson but I am not very proud of this because like everybody else I also think what him and his friend did to Rosalind Franklin was completely unacceptable). On the other hand, meeting with celebrity figures are not that easy in software development. Would Dan Abromov accept our invitation if we want to make an event in Istanbul? Well, maybe, but the odds here are very unlikely.

Knowledge sharing

By its nature, a scientific study needs to get published. There are methods developed to do that for centuries in which there is a requirement for the work to be noble enough. In the most common scenario, your work should be peer-reviewed by other scientists before it can be published in a journal. That is how we achieved for each work to contribute something new to the area. By this way, studies trying to copy each other get eliminated. Moreover, every study is required to be repeatable by anyone who reads that paper as long as s/he follows the same procedure. That is why every paper should show their references explicitly. On the other hand, sharing knowledge in the development community is not that easy. Stackoverflow or issues on GitHub usually works fine but finding articles about problems and digging down to its source are mostly impossible. I always find myself while creating a new application with “ng new” command although what I actually want to find is how to deliver environment variables through dependency injection. Also, I haven’t seen an article whereby I can find references. Questions like “What problems did you have?”, “How did you try to solve?”, “What didn’t work for you and why?”, and the most significant one “Where did you get that information?” are usually left unanswered. This aspect is usually ignored by most of the developers. There is clearly a necessity for a better methodology to write and publish. There might be numerous possible solutions for a better experience sharing in development, but that topic is beyond the scope of this article.

To sum up

Understanding a constitution from the inside out and having hands-on experience is not even comparable with the rumors we hear. If I have never been in a laboratory, never tried to observe the behavior of a microparticle under optical tweezers, never covered my eyes from the high energy laser I would not be able to understand how hard it is to be a scientist. It is similar to Tardis in that sense cause science is always bigger on the inside. Making a shift in my career and being an engineer was not a simple decision after all cause being a physicist was my childhood dream. It felt like I was going to erase all of my past experiences and start over from the very beginning. It looks scary but it is also the way how we can change our point of views in order to change our lives as long as we have enough courage to try. In the end, I realized working as an engineer is much more different than I thought because it’s smaller on the outside. Even though I had hard times while understanding the environmental dynamics, I knew I was going to be happy and successful in my job. The former is accomplished, the latter is in progress. Learning never ends.