Stop hiring "data help." Permanent hires own the vision. Contractors scale your speed. Consultants design the roadmap. Don't buy a permanent solution for a temporary gap. Pick the model that fits the problem. The link to the complete piece is in the thread.

Stop buying software for simple problems. AI makes the "build versus buy" decision easy by turning logic into tools. I replaced years of messy spreadsheets with a custom app for Bulgarian ham radio frequencies in one afternoon. Stop adapting your workflow to a rigid vendor UI.

I turn 37 today. Here are 37 lessons from 16 years in tech: 1. Tools change every three years. 2. Stakeholders do not care about your tech stack. 3. A simple SQL script beats a complex framework. 4. Excel is the most popular BI tool in the world. 5. Most requests need a conversation.

Tenure is not impact. Sitting in a chair for years does not earn you a promotion. Senior engineers hit a ceiling because they wait for permission. Stop fixing pipelines. Start fixing business risk. Solve next-level problems today to get the title tomorrow.

"I am busy" is a weak defense. It invites people to negotiate your time until you break. Use a priority shield. List your top 3 projects. When a new request arrives, ask: "Which of these should we stop to do this?" Shifts the burden of choice. You stay sane.

"Nobody will pay you to sit in front of a computer all day." My dad said this when I told him I wanted to study Informatics. We were broke. Exam fees felt impossible. Today, I’m doing the work no one understands. But it matters. Skill matters. Confidence sells. Build both.

Seniority is a trap. The better you debug, the more bugs you get to fix. Staff engineers do not win by shipping more code. They win by saying no to low-value requests. The shift: - Junior: I can build that. - Senior: I will build that. - Leader: We should not build that.

Living in post-Modern Data Stack times is nice. The hype is over. The hangover is here. We spent $150k on tools to move CSVs. Complexity was a status symbol. Now, we focus on basics: - Use Postgres until it breaks. - Write clean SQL. - Delete the diagram. Back to engineering.

Data folks write terrible code. Here's what I mean I sometimes see folks using: - linters - formatters - tests But I rarely see them measuring: - test coverage - cycomatic complexity - code maintainability Either start writing good code. Or stop complaining about AI slop.

When you act like a service desk, everybody treats you like a service desk. Nobody asks for your opinion. You might be essential for strategic projects, but nobody mentions your name and you have nothing for your CV.

AI replying to comments written by AI under an AI generated posts. What a time to be alive!

Talented engineers leave when the process stops them from finishing work. They move to companies where the system handles the friction. A senior engineer spending 20% of their time on deployments costs the company one full day of salary every week. www.datagibberish.com/p/deployment...

I have no skills. Not a single one. Should I feel left behind for not using OpenClaw?

Podcasts are FREE Blogs are FREE YouTube is FREE Learning is FREE. What's stops you then?

The best way to train a senior DE isn’t a code review. It’s letting them ship a design you know will break. Technical intuition is forged in the cleanup, not the doc. Let them fail safely on internal stakes. No blame. Just scar tissue. Stop protecting them from growth.

Most data engineers fail the whiteboard interview before they write a line of code. How you think you pass a whiteboard interview: - Memorize LeetCode solutions - Suggest tech stacks - Draw diagrams immediately - Work in silence

Ideas come from reading. Clarity comes from writing. I read this somewhere and I deeply believe it.

5 luxiuries in data - Fun technical projects - Clear requirements - Well structured data - Realistic expectations - Budget for people and tools What else?

Anyone else feeling app fatigue lately? New apps, new logins, new password. I thought the Internet was suppose to make things easier.

AI engineering is basically data engineering with a new badge. "AI support” is a big part of the data eng job, but you can build the actual solutions. Same concepts, new labels: ETL, tasks, DAGs. You’re closer than you think. Full mapping in comments

If tools like Snowflake feel too expensive, you probably don’t need them. Instead, go with a more straightforward solution like PostgreSQL. It’s much cheaper to manage.

The best data engineering work is invisible. No outages. No angry PMs. No broken dashboards. Which means… No credit. No praise. No promotion. You prevented the fire. So no one believes it was ever real.

Modern data career path: - Pay $300 to memorize a vendor brochure - Pass a test with 4 answer choices - Add “Certified Engineer” to LinkedIn - Get billed out at $300/hour - Get paid the same as last week

The fastest way to lose trust after a pipeline failure is naming the tool first. Explain impact, not libraries. Flow stopped. Signal broke. Decision worsened it. Guardrail fixed it. Systems > syntax.

Agile was supposed to make teams faster. Instead, it made managers feel busier. "Agile" often just means "we don't have a plan, so you'll have to work weekends." If you’re shipping broken pipelines under the banner of velocity, you are not agile.

Data folks often ask "How can I give more value to my stakeholders?" A better question is: "How am I helping the business?" You already do a lot. Know your value.

Do you type or dictate when you interact with the AI? Dictation weird initially, you know, like I'm talking to myself. Now It reminds to the times when when I'd sit with a junior and how to write code. PS: Don't do it in public unless you want to make people feel awkward.

I just rebuild my personal website and vibecoed the shit out of it. → Design: Google AI Studio → CMS: Pages CMS → Hosting: Cloudflare Pages → Backend: Cloudflare Workers 0 cost. Check the the full write-up: https://www.ivanovyordan.com/blog/building-my-personal-website-with-ai-write-up

Data folks often ask "How can I give more value to my stakeholders?" A better question is: "How am I helping the business?" You already do a lot. Know your value.

Want to grow beyond a senior data engineer? Move beyond code own business problems. https://www.datagibberish.com/p/how-to-stop-waiting-for-permission-to-lead-data-engineering

Stop nodding in meetings. Demand clear logic. Don't be a human middleware. Be an engineer. https://www.datagibberish.com/p/the-presumption-debt-in-data-engineering-projects

Stop chaos in data projects. Turn vague requests into clear commitments before you start. https://www.datagibberish.com/p/the-data-project-entry-manual

Stop chaos in data projects. Clarify intent early. Freeze scope. Ship with trust. https://www.datagibberish.com/p/the-data-project-entry-manual

Meeting before the meeting? Then another meeting after the meeting? This is madness! Fix your process. Seriously.

Your stack is a confession. Buying a $50k platform to move 100MB shows mediocrity. Seniority is the courage to stay boring: » DuckDB over Spark » Cron over K8s » SQL over lock-in Stop building resume-driven graveyards. PS: Read the full article in my latest newsletter issues.

Resolutions are bugs. A wish is not a strategy. You don't need motivation. You need a priority queue. Saying yes to X means saying no to Y. Remove the choice. Build the gate.

Where your data team sits isn’t an org-chart detail. It’s a strategic decision about influence, incentives, and authority. And once you see it that way, the tradeoffs become obvious. https://links.ivanovyordan.com/meGY

Most data teams don’t have tech issues. They have standards issues. ETLs break and migrations drag because everyone solves the same problem differently. Singer isn’t perfect, but it forces structure and clarity. Tools change. Standards scale. Watch here: https://youtu.be/k0Y_9YCN25E

You don't need fancy tools to build a trusted data platform. Start with: 1. One KPI everyone agrees on 2. A simple process people can see 3. Clear communication about issues That's it. The hardest part is showing the messy parts. Yes, it’s scary. But it’s worth it.

There are thousands of data engineers. There’s only one you. Lean on what makes you unique.

Me: What problem are we trying to solve with this? Them: The feature doesn’t use AI.

Use RACI in the trenches. When a request lands, map it to a deliverable, ping the A, loop in C, update I. You cut meetings, speed decisions, reduce risk, and stop duplicate work. That saves time and budget. PS: Full playbook is here https://links.ivanovyordan.com/kn-K

Stop being a ticket taker. Own the system. Name one A per deliverable, pin it, and route every ask there. Meetings drop, trust rises, scope finds you. PS: https://links.ivanovyordan.com/kTOB

Stop being a ticket taker. Own the system. Name one A per deliverable, pin it, and route every ask there. Meetings drop, trust rises, scope finds you. PS: https://links.ivanovyordan.com/kTNs

Shared ownership is fake safety. Pin a RACI and name humans. One A per deliverable. Route every ask to the A. You cut meetings and duplicate work, saving budget and risk. PS: https://links.ivanovyordan.com/kTNs

Stop being a ticket taker. Own the system. Name one A per deliverable, pin it, and route every ask there. Meetings drop, trust rises, scope finds you. PS: https://links.ivanovyordan.com/kTLN

Shared ownership is fake safety. Pin a RACI and name humans. One A per deliverable. Route every ask to the A. You cut meetings and duplicate work, saving budget and risk. PS: https://links.ivanovyordan.com/kTLN