Before I get started, I want to tell you about an event I attended this past June. I participated in the first Data Science Mania event in Leipzig. DS Mania is an event for data scientists where, for once, the focus is not on the technology but on the people who develop it.

I not only had the chance to give my own talk, but also learned a lot from the other speakers and participants. I learned about organisation and leadership, communication and responsibility, about career opportunities and how to deal with stress.

Participating in Data Science Mania was an enriching experience for me - and was one of the key inspirations behind this article. Everything that you read here is based on the experiences I have gathered in the course of my own professional career - and on the many smart insights I was able to absorb in Leipzig. Many thanks for the invitation!

So here are my seven tips:

I know, this sounds a bit sobering. But I often experienced - also in my own career path - that data scientists go into their first jobs with unrealistic expectations that simply cannot be fulfilled. The stark contrast between academic teaching and practical application often leads to disappointment.

So you learned all these exciting concepts at university. You know all the coolest AI models and want to finally apply them in practice. But unfortunately, the newest and most sophisticated methods won’t always be the right ones for your project. 

Simpler models are not only easier to implement, they’re also easier to understand from the client's point of view. So you have to get used to the idea that a simple Bayesian model can be just as valuable as a neural network.

The everyday life of a data scientist contains many challenges, from a data format that drives you to absolute madness, over to outliers in a data set that distort your calculations. Sometimes, you will be at an absolute loss as to what to do.

But what are colleagues for? Make use of your team as often as possible - solve problems and uncover errors together. A little tip: Here at PLAN D, we often work with pair programming. This way, cross-checks and dual inputs are directly integrated into the development process. 

But what if you don't have a team? Even then, you don't have to go at it alone. Use meet-ups and events to exchange ideas and learn more. And if you have acute coding problems, you can usually find help in programming forums. The Python community in particular has often surprised me with its willingness to help.

A big part of working in a team is getting feedback, both positive and negative. Whatever the feedback is, be happy about it! We all make mistakes and we can always learn from them. 

However, I do admit that embracing a culture that tolerates mistakes and feedback is a learning process. When first I started as a data scientist, I spent hours thinking about every critical comment: why didn't I see that myself? Does everyone think I'm stupid now? 

And when I myself was asked to review my team members' code, I wrestled with myself: What is the best way to say this? Who is in the wrong here: my more experienced colleague, or me after all?

By now, I love this part of my work. With the Pyladies Berlin, I even gave a talk about it. The title of the talk was “How to be a good reviewer: Be honest, nice, and a badass“ (watch the talk here starting at 1:10:00) 

Sometimes, the combination of working as a team, one's own inexperience, and the awareness that mistakes are allowed can lead to a fatal conclusion: namely, the assumption that one is not responsible for the results of one's own work. 

“There must be a reason why my boss did it this way. My colleague will double-check it anyway. The back-end developer will get in touch if he needs anything.“ Hmm yes, maybe. But also, maybe not.

In our team, everyone is responsible for their part of the work. This means: Talk to your boss if a task is not clear to you. Test your code as much as possible instead of relying on your colleagues. And if you haven't heard from the backend developer in a while, ask how far he's gotten. Don't forget: the others are also only human, after all. 😉 

It has already been mentioned in the sections above, but I would like place a special emphasis on one key point: Communicating with other project participants is one of the single most important success factors for data projects. This applies to your direct colleagues as well as to your superiors and to other teams (e.g. IT architecture, back end and front end development, IT security, data protection). 

If you work in consulting like I do, it also applies to your clients. I have to admit, this surprised me at first. In my mind, data scientists were in their own little bubble without much contact with clients. But at PLAN D it's completely different.

Again and again, we attend client meetings and take part in status updates and workshops. On the one hand, this gives us the opportunity to better understand the challenges and wishes of our clients and on the other hand, it allows us to explain our work to them. In order for the employees of our client companies to be able to actually use the technologies we develop, they need to understand what AI is capable of doing - but also what it cannot do.

For me, the first years of my career were an incredibly exciting time. This is the time where you find out where your real strengths lie. This not only helps with your daily work, for example how best to distribute tasks within the team, but - importantly - it also helps you to find out in which direction you want to further develop your career. 

You might discover your enthusiasm for entrepreneurial thinking and become a sales engineer or business lead. Or you might find that you are pretty good at all the interpersonal stuff: motivating others, communication, feedback conversations.... Then you might be a born people manager.

If you want to learn more about leadership roles in tech, I recommend this video from the Tech Leaders Academy (video in German). However, I also want to emphasise that leadership is just one of many options. There are many other opportunities for professional development. 

Data science is an incredibly diverse and wide-ranging field. I personally very much enjoy the fact that I “have to“ constantly familiarise myself with new topics. From preprocessing to test automation, project management to data backup: as a data scientist at PLAN D, I have already taken on the most varied of tasks.

My last piece of advice is one that is certainly applicable to most other professions. Nevertheless, for me is an absolutely essential part of the list, because I believe that the topic of self-care is too often neglected in our industry.

The demands on us data scientists continue to grow - as you can also see from this article. At the same time, it is in the nature of our work that it takes a long time to feel a real sense of achievement. And like everyone else, we also must deal with the constant interruptions that come with everyday work in the digital world. Email, Slack, WhatsApp, you name it... 

At Data Mania, the team from extrazwei gave some great tips on how to reduce this fragmentation of your working time. For example: Turn off your notifications. Establish focus times to allow you to work without interruptions. Only check your emails three times a day!

Find whatever works  best for you. Take care of yourself and really work out what you need in order to have a relaxed and productive workday.

I hope that I was able to give you some good insights into our work and my personal advice and experience. As you can see, you certainly won’t get bored very quickly when working as a Data Scientist.

Personally, I find my job incredibly exciting. I love working with the many great people I encounter every day. And of course, I also love the code :-)