Learning data analytics in public has taught me something deeper than Excel or SQL. 📊 You can start from somewhere completely different and still build something meaningful. I studied Animal Science. I taught in classrooms. I worked in customer service and sales. Now, I'm learning data analytics. And honestly, starting over isn't always easy. There are days when you feel behind. Days when you wonder if you're learning fast enough. Days when the people around you seem miles ahead. But I'm learning that progress doesn't require you to have everything figured out. It starts with asking better questions. 1. Start with the question, not the tool. Before opening Excel, ask: What decision will this analysis help someone make? 2. Understand your data. Where did it come from? What does it leave out? Can you trust it? 3. Learn the fundamentals. Tools will change. AI will get better. But the ability to think clearly will always matter. 4. Learn to communicate. Finding an insight is one thing. Explaining it clearly enough for someone to act on it is another. 5. Build by solving real problems. Don't just learn formulas. Don't just watch tutorials. Take a messy problem. Work through it. Make mistakes. Figure it out. Share what you learned. AI can write a formula or SQL query in seconds. But knowing what to ask, what to investigate, and what the answer actually means is the skill I'm building. I'm Obinna. I'm learning data analytics in public, one real problem at a time. If you're learning a new skill, changing careers, or starting over too, you're not alone. We're building from where we are. What are you currently learning that could change your career?

The size of the joined table is not the cost, the join key is. If it is not indexed on the big table, each of those 100 rows triggers a lookup pass over the large one. The other thing I would check first is row count: if those 100 rows repeat keys, the join multiplies rows and you are doing 30 times the work downstream. COUNT(*) before and after tells you straight away.

Governance sounds like a big company word until you run a small business. In mine, sizes got written as M, medium and Med depending on who took the order, so no count of anything was reliable. Fixing it did not need software, just one agreed list of values and everyone using it. Tool subscriptions cannot repair that, and they are expensive on top of the problem.

XLOOKUP, without thinking. I ran a small online fashion business and prices changed constantly, so every order row had to pull the current price from a separate price list. =XLOOKUP(A2,$E$2:$E$13,$F$2:$F$13,\"Not found\") and no more typing prices by hand. The habit that came from it: never keep the same number in two sheets.

XLOOKUP answers one question: what goes with this? You give it a value to find, the column to search, and the column to return. Product ID in, price out. Unlike VLOOKUP it can look to the left, and you build it in one step instead of three.

A business gets plenty of enquiries and few sales. What would you check first: - The price - Whether the item is in stock - How fast they reply - Whether people wanted that product at all Pick one and say why.

A funnel is just the stages between someone hearing about you and someone paying. 500 see the post. 200 enquire. 20 buy. Two out of five people who see it come to you. One in ten of those pays. The leak is after the enquiry, where interest has to become a decision. Better posts will not fix that. They were already interested. Something between the question and the payment is losing them. Find the stage where you lose the most people before you fix anything.

A tool gives you a faster answer to the wrong question. I ran a small online fashion business and the number that mattered was conversion, but the reason orders stopped was never in the data: customers asked about size or delivery, then went quiet, and nothing recorded why. No model finds that. You find it by reading the messages and asking a person. The job moved up a level, it did not disappear.

Useful as a reference. The trap for beginners is reading it as three options to choose from. SQL is the one you can be productive in first, and most of these operations are the same idea in a different syntax. I would learn SQL, get the concepts solid, then map them onto Python later. The comparison makes far more sense once you already know one of the three.

C. The thing that made it click for me: EXISTS is asking a yes or no question, so the database can stop the moment it finds one row. COUNT(*) is asking how many, so it has to read all 10 million. Same result if all you needed was true or false. The habit worth building is stopping to ask which of those two questions you are actually asking.

200 people enquire. 20 buy. 20 ÷ 200 = a 10% conversion rate. Excel gets you that number in one cell. It cannot tell you why the other 180 walked. That is the actual job.

First option. Worth knowing why: 45223 is not random, it counts days from 1 January 1900, which makes it 24 October 2023. Useful test is to change the format to General and back, the number survives, the date appears. If you see those five digits in an exported CSV it is the same thing, the format got stripped on the way out.

Still early in SQL so I had to think this one through: the index finds the rows, but it cannot give you the order, so the sort still touches all 2 million. Put created_at into the index alongside customer_id and the newest 20 come out first without a sort. Is that right, or does the sort still show up in the plan?

I couldn't agree more. The test I use: hand it to someone who did not build it and watch them run one cycle without asking you a question. I ran a small online fashion business and every size or delivery query came back to me, because the answers lived in my head. Once I wrote the common questions and answers down, anyone could handle a customer. Same idea at the school I taught at, where I wrote the morning routine down so it kept running on days I was not there. Before trusting someone with our reporting, I would want to see the same file they built running on a month I already know the answer to.

The WHERE runs before the window function, so MAX(Salary) is the highest salary in the department among employees under 50,000, not the department's real max. Anyone above the cut is already gone before the OVER() computes. If the question wanted the true department max, filtering has to happen after the window.

The one that got me was sizes typed three ways in the same column. "M", "medium" and "Med" split one product into three lines in a group-by, and the totals were quietly wrong. Standardising the text before any analysis would have saved me two hours and one embarrassing answer. Worth adding: count the duplicates before you delete them. The number tells you whether it is a typing habit or a broken order form.

Exactly, and the one I keep hitting is that the data does not contain the reason. A lot of my fashion orders died right after a buyer asked about size or delivery and then stopped replying. Nothing in my sheet records why they went quiet. No model can find a cause that was never written down, and that gap is closed by asking people, not by querying.

For mine, the first question is where the money stopped. I run a small fashion accessories business, and the only dashboard I actually need answers which products and which customers stopped ordering, and when it happened. Everything after that is detail.

The roles are shifting more than disappearing. As someone learning and applying this to a real small business, what I notice is that the work is less about building dashboards and more about answering a question the owner cannot phrase precisely. That skill is not going anywhere, and it is the part most courses skip.

Writing order and execution order are two different things. Most people type FROM and JOIN first and write the SELECT last, because that is the order the tables come into their head. The list in the post is closer to execution order, and that is why WHERE cannot filter on an aggregate while HAVING can. One distinction, and half of beginner SQL confusion disappears.