My tackle the important thing transferrable skills for those coming from academia to business data science

Preface

I’ve spent 5 years working as a researcher grinding laser physics, nonlinear optics, and solid-state laser engineering. While being fully submerged in the sector, and enthusiastic about what I’ve been doing, sooner or later I made a transition into the business data science industry.

After working in data science for extra 6 years I even have an impression that the skill set that I developed within the applied physics field has an ideal use in working on business projects that are usually not in any respect related to laser physics.

Plenty has been written about how useful academic experience may be, but I made a decision to specific my personal opinion on the topic.

To make my point I’ve decided to rate each skillset group based on how useful it’s and why.

Who’s this text for?

I feel I wrote it mostly for the people enthusiastic about the transition from the tutorial environment into the business field, but additionally for myself, to reflect on the intersection of tools, skills, and mindsets between the 2 fields.

Experience with literature review → 7/10

Why is literature review such an awesome and transferrable skill (habit) for business data science?

For my part, a literature review is a bit ignored and misunderstood in business data science. And I’m not saying that we don’t read enough about brand-new model architectures and framework designs (this part is executed exceptionally well).

But relating to getting more structured and helpful information with regards to the project quickly and effectively — that’s where the largest gap in the info science world exists for my part.

A literature review may not even be one of the best term here. I could also call it background research, or state-of-the-art evaluation.

When coping with a business problem, for my part, it is important to get at the least some theoretical base with regards to your problem. What literature review does:

• Forms a foundation for solid decisions on data strategy. Acquaint yourself with existing techniques and approaches within the domain field.
• Hastens the onboarding process. For those who are latest to the domain you might be working on, getting knowledge on the topic as quickly as possible is step one for attending to value generation.
• Improves communication quality with experts in the sector. Domain experts, also called material experts are invaluable for solving data problems. But they typically don’t program, they usually are pretty busy. Thus data scientists must acquire some understanding of the domain-specific terminology and ideas to speak effectively and collaborate seamlessly with these experts.
• Drastically improves the standard of your insights. In my experience, a literature review adds to a foundation for decision-making about data collection, preprocessing, modeling, and evaluation, ultimately improving the standard of the insights you deliver. In my experience, it really works, but not at all times.

Listening to a literature review, and investing effort and time into it, embodies a selected mindset — open-minded, humble, and inquisitive. A literature review helps with keeping you away from reinventing the wheel or the trap of confirmation bias.

I think that the strategy of a literature review will change with the expansion of enormous language models and services based on them, but we’re not there yet.

Journaling→ 9/10

Transferring journaling practices from academia to business data science has been very rewarding for me. Behind multiple practical advantages, it gives you a priceless sense of continuity when going through ups and downs within the work lifetime of a researcher. For my part, by adopting the keystone habit of maintaining a lab notebook, data scientists can easily track their experiments, jot down ideas and observations, and monitor their personal and skilled growth. I wrote an entire separate piece on why it’s such an awesome idea to achieve this, be happy to examine it out!

Knowledge of programming → 6/10

In my scientific journey, I’ve been working on experimental data processing, numerical simulations, and statistical learning on an on a regular basis basis. Programming was also essential for developing and testing latest laser designs before testing physical prototypes (numerical simulations).

I’ve used it always for typical data science stuff:

• experimental data processing (Python, Wolfram)
• numerical simulations (Wolfram, Matlab, Python)
• statistical learning (Wolfram, Matlab, Python)
• data visualization (Origin Pro, Python, R)

Wolfram (Wolfram Mathematica more specifically) was essentially the most heavily-used tool because we had a license for it within the lab. It had an awesome toolset for solving non-linear differential equations, and we were widely using it for numerical simulations.

Python was a tool of selection for me to wrangle data generated during experiments (beam shapes, oscillograms).

In the case of data visualization, Origin was the first tool since it allowed embedding of visuals into text documents while keeping them editable. Line charts, histograms (including kernel density estimators), regression evaluation — Origin was an awesome tool. Origin has a GUI, so it is just not even about coding, I just must mention it to be sure that Python and R don’t get all data viz. credit.

On the whole, I had a solid experience with each of the tools mentioned above: I do know the syntax and I can solve problems with decent efficiency. So why just 6/10? Why are programming skills gained in academia relatively low-transferrable into business data science? That may be a pretty strong statement, but I feel the downsides of educational experience may outweigh the upsides. Mainly because good software practices are completely neglected in lots of scientific environments.

Caveat: this statement relies on my personal experience of working in applied physics field, and definitely don’t apply to everyone working in academia. Take every thing from this section with a grain of salt!

On one hand, neglecting good software principles is a natural consequence of researchers optimizing for speed of research and variety of publications, not for code quality and maintainability. Alternatively, there are almost no people coming from proper software development to academia (for financial reasons), thus there is no such thing as a real production expertise in the primary place. I also needs to mention that working on designing experiments, doing a literature review, collecting measurements, writing code to process them, and getting helpful insights — all at the identical time is exhaustive. As a consequence, you simply don’t have enough resources to check software development.

Proficiency in conducting measurements→ 9/10

This one is difficult to elucidate, so bear with me. Measuring stuff in applied laser physics is a discipline of its own. Delivering helpful measurements is a skill that takes years to coach! There are various reasons for that: you’ve to grasp the physics of the method, follow measurement protocol and have specialized knowledge and training to operate complex and expensive instrumentation.

For instance, I’ve been working with diode-pumped pulsed solid-state lasers, measuring multiple parameters of the laser beam: pulse duration, pulse energy, repetition rate, beam profile, divergence, polarization, spectral content, temporal profile, and beam waist. Doing any of those measurements is so rattling difficult. To illustrate, you ought to measure the beam profile (see the image below).

Beam profile refers back to the spatial distribution of the laser beam’s intensity across its cross-section or transverse plane.

In theory, you simply direct a laser beam to a CCD camera and get your beam shape in seconds. But doing it on the bottom is an entire different story. For those who are working with a pulsed solid-state laser with a good pulse energy, and you understand what you might be doing, you’ll direct a laser beam to the high-quality optical wedge to get most of the heartbeat energy right into a trap and work with a mirrored image of a beam that has only a fraction of the energy of the unique beam. You’ll achieve this to guard the CCD camera from a disaster. But using a wedge will probably be not enough. You’ll install an adjustable beam attenuator, lock it into the darkest mode after which steadily lower the absorption rate until you get the proper exposure in your CCD camera.

For those who are working with an infrared laser that’s invisible to the human eye, you might be faced with an issue: you’ve to steer the beam through small apertures without seeing the actual beam. This skill alone can only be acquired through training and practice. By the best way, each step of beam manipulation needs to be done with extreme care attributable to the security regulations: you’ve to wear appropriate protective goggles, use protective screens, etc.

Okay, moving on, now your beam is attenuated and sits nicely on the CCD camera. But you continue to have plenty to do: wire the CCD camera to the laser power unit to attain synchronization and produce a stable image. For those who’ve done every thing accurately — you get your images. Wait, images?

You then realize that in case your laser operates at a pulse repetition rate of fifty Hz, that implies that it produces 50 pulses a second. Each produced pulse might need a rather different beam profile. How do you produce the result? Do you have to just pick a random shot and capture the image? Or do you have to produce the common image using a certain variety of pulses? Oh, the averaging was enabled by default by the software managing the CCD camera?

Let’s wrap this “measuring beam shape” nonsense up. From all of the measurements I did in my life, I even have 2 key transferrable qualities: it’s vigilance (NEVER take anything at face value) and meticulous attention to metadata (how exactly data was measured or recorded, which tools were used, and even why it happened in the primary place). Each are golden relating to working with real-life data. Since it lets you be far more efficient in producing the actual impact without stepping into the rabbit holes. And that’s something that’s valued each in academia and in business data science.

Data Communication Proficiency → 10/10

While I used to be in academia, I didn’t consider data communication to be a very noteworthy or helpful topic to jot down about. Working on data visualizations, chatting about data and theories, and writing scientific papers were just a part of the job. But after years of doing research, you gain a solid skill set in data communication on different levels (each formal and informal).

Writing a scientific paper is one among the more difficult skills to acquire amongst formal data communication types. It takes numerous practice to find a way to compose a compelling piece that has a correct structure (abstract → intro → literature review → methodology → results → discussion → conclusion → acknowledgments). The structure of the article itself presumes that you’ve a story to jot down about. And it is just not nearly writing: you’ve to know your way around producing compelling and purposeful visual representations of information. All to get your message to the audience.

I rate this skill as a ten out of 10 transferability because business data science unsurprisingly depends upon interactions between humans, communicating your thoughts and results.

Conclusion

Overall, I think that those with a scientific background can bring unique perspectives and helpful skills to the sector of information science. To those in academia who consider that transitioning to a profession in business data science means abandoning all their labor and expertise, I offer a special perspective: you’ve a wealth of value to bring to the table. For my part, one of the best plan of action is to leverage your existing skills while picking up latest techniques and best practices of the sector you transition into (all of us realize it is a lifelong journey).