7 Lessons I learned from more experienced data science colleagues

Jan 27, 2025 1:05 pm

If there’s one thing I’ve learned on my journey as a data scientist, it’s that experience is the best teacher.


Coming from a software engineering background, I had a lot of technical knowledge, and my experience of a freelancer taught me how to communicate effectively and use that to reach goals.


But nothing prepared me for the expertise I’ll get on my first job.


Along the way, I’ve worked with some incredibly talented experts who have shaped my thinking and approach to problem-solving.


Here are 7 lessons from other data science and AI experts that made me a better data scientist—and they might resonate with you too:


1. If something is confusing, ask early.

We’ve all been there—hesitating to ask a question because we’re afraid it will make us look inexperienced. But the reality is, clarity saves time and prevents errors.


Example: During a project, I didn’t ask how a feature was engineered. Weeks later, I found out it was miscalculated, and the entire pipeline had to be redone. Asking sooner would’ve saved hours of rework.


There’s no shame in asking for clarification, even multiple times. It shows you care about accuracy and getting things right.



2. Pair programming teaches you more than you think.

Collaboration isn’t just about task delegation and micromanagement—it’s about learning from others’ thought processes. Pairing with someone more experienced can reveal better coding patterns, debugging tips, and ways to think critically about problems.


Example: While working on a production pipeline, I learned shortcuts for debugging and strategies to optimize performance—all things I wouldn’t have discovered on my own.


Pair programming isn’t just for beginners. Even seasoned professionals use it to refine their skills and stay sharp.



3. There are no silver bullets.

Everyone wants to build the “ultimate solution”—a one-size-fits-all system that solves everything perfectly. But experienced mentors taught me that trying to solve everything often leads to solving nothing well.


Example: A one-size-fits-all recommendation engine I worked on ignored user-specific behaviors. In the end, it was so generalized that it didn’t add value.

Focus on solving a single, specific problem first. Generalization can come later, if it’s even necessary.



4. Start small with a Minimum Viable Product (MVP).

You don’t need a perfect product to start—just a functional one. Getting something working, even if it’s basic, can reveal hidden challenges and guide your next steps.


Example: On one project, we built an MVP that only cleaned data without automating the downstream tasks. This helped us identify bottlenecks and refine the process before scaling.


Build, test, and iterate. Perfection is the enemy of progress.



5. Reproducibility is non-negotiable.

Reproducibility isn’t just a technical requirement; it’s a professional responsibility. Without it, you’re gambling on luck instead of building reliable systems.

Example: I joined a project where experiments weren’t version-controlled. We couldn’t replicate the model’s performance, leading to endless confusion. Versioning everything—from datasets to hyperparameters—changed everything.


Always assume someone else will take over your project (even if that “someone” is future you). Build systems that can be easily understood and replicated.



6. Understand the business problem before diving into data.

It’s easy to get lost in technical details and forget why you’re solving the problem in the first place. Great data science starts with asking, “What does the business need?”


Example: On a churn prediction project, I dove into modeling without knowing which customers mattered most. My model worked but didn’t drive impact until I realigned with business priorities.

Before opening a dataset, talk to stakeholders. Learn their pain points and what success looks like to them.



7. Document everything—code, decisions, and experiments.

Documentation is like a roadmap—it guides others (and your future self) through your project. Good documentation isn’t optional; it’s essential.


Example: On a large team project, the lack of documentation caused weeks of delay when onboarding new team members. Writing clear docs became my top priority afterward.

Think of documentation as part of the deliverable. The more thorough you are, the more valuable your work becomes.



For me, these tips transformed the way I work, and they extended far more than just technical tips.


My more experienced peers taught me how to think the right way. They taught me how to approach teamwork - me, who absolutely hated working in a team.

What’s the best lesson you’ve learned in your career? Hit reply - I’d love to hear it!


P.S. All my learning resources are 50% off until the end of the month! Use this unique time to upskill, because the sales are limited!


Upskill here!




To better future!

Danica

Comments