What I’m Doing Differently Than 90% of Data Engineers Right Now
A while back, I hit a wall. Not a bug. Not a broken pipeline. A mental wall. And I was thinking, “Why do I feel stuck, even though I’m shipping things every day?” I had good pipelines, neat and clean code, and decent reviews. But something felt off. I wasn’t growing. I wasn’t standing out. And frankly, I was tired of babysitting DAGs that broke at 3 AM because a vendor had added a new column without notifying anyone. And at the same time, been noticing that the world around me was changing:
- AI was suddenly everywhere.
- Data tools were evolving at breakneck speed.
- Everyone was talking about “data products”, “semantic layers”, and “generative pipelines.”
That’s when I realized: Doing what I’ve always done wasn’t going to cut it anymore. So I did something most engineers don’t do. I paused. I zoomed out. I redesigned my approach. And today, I want to show you what I’ve been doing differently — and why it’s made all the difference.
1. I Stopped Being a Tool-Chaser and Became a Systems Thinker
Let’s be honest: it’s exhausting trying to keep up. You start learning Airflow, and someone says “Dagster is better.” You finally understand Spark partitions, and now it’s “just use DuckDB.” You get comfy with dbt, then someone throws in “LakeFS + Iceberg + GitOps” like it’s a weekend project and so on.
Most data engineers are stuck in what I call “tech FOMO mode.” I used to be one of them — collecting tutorials, saving posts, feeling overwhelmed and a bit confused. Then I flipped the game. Instead of chasing tools, I started chasing problems:
- Why do pipelines fail during schema drift?
- Why does cost explode with poor partitioning?
- Why do stakeholders lose trust in data?
I went deep into core principles:
- How modern query engines optimize execution
- Why columnar formats matter
- How caching, lineage, and compute separation really work
Now? I pick tools like an architect picks materials — intentionally. If 90% of engineers are tool collectors, I became a problem-first builder.
2. I Made AI My Intern, Assistant, and Debugging Partner
At first, I used ChatGPT like most devs: “Hey, write this UDF for me.” Cool. It was helpful. Time-saving. But then I started going further:
- Summarizing messy code I inherited from someone who no longer worked there
- Generating pipeline documentation based on SQL models
- Creating synthetic test data with specific edge cases
- Reviewing my logic for bias or inefficiency
- Acting as a brainstorming partner for better schema design
Now, it’s like having a junior engineer on-call 24/7, the one who is always ready to assist. Except it never takes a sick day or forgets to comment its code. And after that, I didn’t stop there. I began exploring how AI fits into the actual architecture:
- LLM agents that triage alerts from pipeline failures
- Vector-embedded metadata search to help analysts self-serve
- Conversational UIs on top of our warehouse for non-technical teams
AI didn’t take my job. It made me 10x better at it. Most engineers wait to be told how to use AI. I built AI into my toolbox before it was even mandatory.
3. I Treat My Pipelines Like User-Facing Products
Let me tell you something that shifted my mindset permanently: “The data you move is not the value. The experience you create around it is.” So many engineers still treat their jobs like:
- Build DAG
- Load data
- Shrug when it fails
But I started treating each pipeline like a mini-product:
- Who are the users?
- What are their frustrations?
- Can they trust this pipeline?
- Can they understand what it does without a 2-hour walkthrough?
I built:
- Slack alerts with context, not cryptic error codes
- Data documentation that reads like a story, not an index
- Onboarding flows for analysts to explore the data on their own
- Metric layers that abstract business logic in plain English
This mindset didn’t just make my work better — it made me visible. Now people from other teams ask me to review their data designs. I get invited into product discussions because they know I think beyond tables and columns, which makes me feel really happy.
4. I Built Communication into My Stack — Like It’s Code
Here’s something no tutorial will tell you: Your career won’t stall because of your code. It’ll stall because people don’t understand your value. I used to be allergic to meetings, reluctant to explain things, and bad at documenting. Now?
- I write internal blog posts to explain architectural decisions
- I teach juniors during retros
- I give clear TL;DRs in PR reviews
- I speak up in stakeholder reviews — not to flex, but to clarify
These “soft” skills aren’t soft. They’re amplifiers. They help your work land in the right rooms, with the right people, at the right time. And here’s the unexpected bonus: Once I got better at explaining things, I got better at building them too.
5. I Designed a Career Feedback Loop (No Manager Needed)
Most engineers wait for yearly reviews or ad hoc feedback. Not me. I built a career feedback loop that runs on autopilot:
- Monthly retros on what went wrong and what went right
- Quarterly goals (tech + communication + leadership)
- Reflection docs for every project shipped
- A “brag doc” that I update every time something cool happens
Here’s why this matters: 🧭 You stop drifting 🚀 You accelerate your growth 💼 You build leverage — for promotions, freelance gigs, interviews, you name it 90% of engineers just… exist. I run my career like a product in alpha — always improving, always testing, always learning.
Bonus: What This Actually Got Me
Let’s talk about results, not just vibes. Since making these changes:
- I’ve been tapped for high-impact projects that cross departments
- Got invited to contribute to internal data platform discussions
- Landed freelance offers through my content (yep, this kind of stuff)
- Finally stopped feeling stuck and started feeling in control
And most importantly? I actually enjoy what I do again. No more “just move this data and log off.” I’m building systems, solving real problems, and designing things people rely on, and I enjoy that.
Final Thoughts: You Don’t Need to Be a Unicorn
This isn’t about being a 10x engineer. I’m not perfect. I still break things. I still get lost in new tech sometimes. But I think differently now. I build differently. I show up differently. Most engineers wait to be told what to learn and how to learn, and they are still chasing some trendy skills. I look at the future and build toward it — brick by brick.
📣 Want to Join the 10% Who Build What Matters?
If you’re done chasing hype and want to:
- Build AI-integrated data systems
- Improve your mindset (not just your stack)
- Design pipelines people actually understand and use
Read the full article here: https://medium.com/@sauravkumarrajjoli/what-im-doing-differently-than-90-of-data-engineers-right-now-9141b2b08f73