Day 4-5 of hr-analytics-project

Last night I finally finished designing dashboard of this hr analytics project. It had four pages. At that time I genuinely thought it looked pretty decent. It had charts, KPIs, slicers- everything I had learned over the last couple of days. I was happy with it. Then I searched "IBM HR Analytics Dashboard" on Google. I saw them and got humbled😊. Mine looked like a college assignment. Those dashboards looked like something you'd actually hand to a manager. Clean. Minimal. Everything important was visible immediately, in a single page. No unnecessary clicking. No jumping between pages. That was probably the biggest lesson of these two days.I had been thinking about building more charts. The people who designed those dashboards were thinking about making information easier to understand. So I scrapped my four-page dashboard. Not because it was wrong (well it kinda was ig), but because I knew I could do better. The rest of today was spent redesigning almost everything. Instead of separating insights into multiple pages, I rebuilt the dashboard around a single question:

Why are employees leaving?

Every chart had to earn its place. If a visual wasn't helping answer that question, it didn't belong. The final dashboard now shows the overall picture first- attrition rate, employees who left, average age, average income- and then breaks attrition down by age group, business travel, environment satisfaction, work-life balance, income and tenure.

One thing I realized today is that dashboard building has very little to do with Power BI itself. Power BI is just the tool. The difficult part is deciding what deserves to be shown and how to tell a story with data. Anyone can create twenty charts. Not everyone can remove fifteen of them.

And because apparently one challenge wasn't enough...

Git also decided to teach me a lesson today. I somehow managed to create another branch, spent hours wondering where my commits had gone, convinced myself I'd ruined the repository I'd been building for six days, and then slowly untangled the whole mess. Everything's sorted now.

 Looking back, these two days weren't really about Power BI. They were about iteration. Build something. Compare it with work that's better than yours. Accept that yours isn't there yet. Figure out why. Then rebuild it.That cycle probably taught me more than any tutorial could.

On to the next project.

Emp-Attrition-Analysis - Day 3

Got humbled today in the nicest and the busiest way. I thought writing SQL would be the difficult part of this project. Turns out, SQL is probably the easiest part. Most of my time wasn't spent typing queries- it was spent questioning them. I'd group values into ranges, run a query, get a result, then immediately wonder, "Wait...does this grouping even make sense?" 

One example was YearsAtCompany. At first, I grouped employees into broad buckets like 0–10 years, 11–20 years, and so on. The results suggested that employees in the 0–10 year bracket had high attrition. It looked like a reasonable conclusion. But something felt off. Ten years is a huge range. Someone who joined last month and someone who has spent nine years at the company shouldn't really be treated the same way. So I broke the bucket into smaller parts. That's when I realized the story was completely different. Most of the attrition wasn't spread across the entire 0–10 year range. It was concentrated in the first few years (0-4 years). That tiny change in grouping completely changed my interpretation. 

The same thing happened while analyzing YearsInCurrentRole and YearsSinceLastPromotion. I kept creating buckets, merging them, splitting them again, and checking whether the sample sizes were large enough before trusting the percentages. 

One funny moment today was finding a group with 0% attrition. For a second, it looked like I had discovered something interesting. Then I checked the sample size. There were only 8 employees in that entire group. Lesson learned: percentages without context can be misleading. 

I also realized something important today. Earlier, I'd write a query, get a result, and immediately write an insight. Now my workflow looks more like this:

• Ask a business question.
• Write the SQL.
• Look at the output.
• Question the output.
• Verify it with another query.
• Check whether the sample size is large enough.
• Only then write the conclusion.

It takes much longer than I expected, I thought 1 day I'll spend doing the EDA and data cleaning, another one writing the sql queries and then will finish off by creating dashboard on day 3, haha, clown emojis loading. I spent hours today and, honestly, didn't write that much SQL. But I think I learned something more valuable than SQL syntax. I'm slowly learning how to think like an analyst instead of someone who just knows SQL.

Doc of Day 4-5

Day 2 - SQL wasn't the hardest part

 {I posted Day 1 and Day 2 on the same day bcz i wrote about Day 1 yesterday but had the idea of posting it here today only, so...here it is}

Today I realized something. SQL isn't actually the difficult part. Thinking is. I spent hours writing queries, but the challenging part wasn't remembering GROUP BY or CASE. It was figuring out what question was actually worth asking. Before writing a single query, I had to stop and think, "If I were the HR manager, what would I want to know from this data?" That changed the entire way I approached the project. At first, I was mostly counting things. How many people left? How many employees travel frequently? But then I realized that counts don't really tell the full story. If one department has more employees than another, of course it'll have more people leaving. What actually matters is the attrition rate. From today onwards, almost every query I wrote included:

Attrition Rate = Employees Left / Total Employees × 100

That one metric made my analysis much more meaningful.

One thing that surprised me was how often my assumptions turned out to be wrong. I noticed that the Sales department had the highest attrition rate. My immediate thought was, "Maybe they work the most overtime." Sounds reasonable, right? So I tested it. Turns out, the overtime rates across departments were pretty similar. My explanation didn't hold up. That was a good reminder that data analysis isn't about proving your assumptions correct. It's about testing them, even if the result isn't what you expected. 

I also learned that one answer usually leads to another question. For example: Employees who travel frequently have higher attrition.

Does that mean one department travels more?

Does overtime explain the department with the highest attrition?

Does work-life balance change things?

What if I combine work-life balance with marital status?

Every query naturally led to the next one. I stopped writing random SQL and started following a trail of questions. 

Another lesson was about percentages. At one point I found that divorced female employees with certain work-life balance ratings had 0% attrition. For a second, I thought I'd discovered something interesting. Then I checked the sample size. There were only a handful of employees in that category. Lesson learned: percentages without context can be misleading. Whenever I see 0% or 100% now, the first thing I want to know is, "How many people does this actually represent?"

I also finally understood why MySQL kept throwing ONLY_FULL_GROUP_BY errors at me. Earlier, I was just fixing the errors somehow and moving on. Today, it clicked. If I'm grouping by one column but trying to display another, MySQL has no idea which value I want it to show. Once I started thinking from MySQL's perspective instead of just memorizing rules, those errors became much easier to understand.

Another small realization: not every variable should stay as it is. For things like distance from home or age, looking at every individual value wasn't very useful. Grouping them into broader categories made the results easier to understand. I even changed my distance groups midway because the smaller groups were showing almost identical attrition rates. Sometimes simpler is actually better.

One thing I'm consciously trying not to do is let Chat GPT think for me. There were plenty of moments where I wanted to ask, "Give me business questions for this dataset." But i was like nah ima not do that. The goal of this project isn't to finish it as quickly as possible. The goal is to become someone who can look at a dataset and naturally start asking good questions. If I outsource that thinking, I'm only cheating myself.

Finally, I realized that this project isn't really about SQL anymore. SQL is just the tool. The real skill is asking good questions, testing ideas, accepting when they're wrong, and slowly building a story from the data. That's what I'm trying to practice.

Doc of Day 3

Employee-Attrition-Analysis - Day 1

{I'm sharing this here to document this journey of finishing this project from the scratch, oky not exactly coz i downloaded the dataset from kaggle, but yeah whatever you get it, right. Writing all of this here so whnever i wanna revisit the project ive everything documented, whatever i had learned. Here's the linkk to the dataset in case you wanna explore- IBM HR Analytics...dataset }

 So I'm learning Data Analytics right now, and I thought instead of finishing each and every tutorial, let's start a project. I'll learn through that. I searched on YouTube for "beginner data analytics projects," came across one, and decided to follow whatever he does. But I thought of going with a different dataset than him, so I picked a dataset from Kaggle (the IBM HR Analytics one) and started. Firstly, I analyzed it through my eyes in Excel, then did EDA and data cleaning. Then I was like, now it's time to do SQlllll. But then I realized that while connecting MySQL with Jupyter Notebook, my MySQL password was very much visible on GitHub. So I had to spend a good 1–2 hours learning how to undo that. Okay, did that anyway. Learned my lesson. Now that it's finally time to perform SQL queries to get some really good insights, I was like, lemme just ChatGPT the bUsIneSs QuEsTiOnS. But then I realized, no babygirl, I'm doing this project to learn, not to just copy-paste it, push it onto GitHub, or show it off on LinkedIn. So I sat with the data and wrote some questions by myself. Now I'll perform SQL queries, answering these questions one by one. This made me realize that learning is slow and sometimes invisible. Learning keywords and syntax is hard... or maybe easy for some people. But thinking... getting yourself smudged into the mud of the data to come up with questions that are actually worth answering... that's the skill. And that skill will come through practice and repetition, not by copy-pasting SQL queries from ChatGPT. AI is amazing. Use it. I use it as well. But you've still gotta do the thinking yourself. Just don't cheat your own self.

Doc of Day 2

Abundant mindset for happiness and success. Cool. But what about pain?

Hey yaaa, after so long im writing. So much has been going on in my mind lately. I was walkimg on my terrace and this random thought hit me. So, like, we are always told to have an abundance mindset, right? Like, believe that there is enough happiness, enough success, enough love for everyone. And that’s how you attract more of it. But then I was thinking, why don’t we apply the same logic to negative emotions?

Like, why don’t we have a scarcity mindset when it comes to sadness, or grief, or failure? Like, if abundance means there’s plenty to go around, then scarcity would mean, like, ‘Hey, there’s only so much pain, so maybe I don’t have to go through it.’ But no one ever says that. No one says, ‘Have a scarcity mindset for your pain.’

And it kind of makes me wonder, are we, like, unconsciously accepting that pain is abundant? That it’s always going to be there, and we just have to deal with it? Whereas with happiness, we are constantly told to believe it’s unlimited.

I don’t know, maybe I’m overthinking, but it feels like a weird double standard. Like, if the universe is abundant, shouldn’t that apply to everything? Or is it just easier to sell the idea of abundance when it comes to good things, because no one wants to hear ‘there’s only a little bit of sadness, so hope you’re not the one who gets it’?

That sounds kind of evil, actually. But yeah, just something I’ve been thinking about. What do ya think?

Unpredictability: breaking free from perceptions

Have you ever found yourself stuck in a situation where someone's façade crumbles, revealing a side of them that completely contradicts their usual demeanor? One moment they're the epitome of kindness and excellence, and the next, they're gossiping about others or speaking poorly of someone. This dichotomy can be jarring, leaving you wondering what their true nature is.

This got me thinking – what if we could avoid being typecast or judged based on our actions? What if we could keep people guessing, making it impossible for them to pin us down? The key lies in embracing unpredictability.

Imagine if you wore different attire every day, mixing and matching styles to keep people guessing. One day, you'd show up in casual jeans and a T-shirt, and the next, you'd don a kurta, defying expectations. Similarly, in your interactions, you'd balance kindness with assertiveness, making it difficult for others to anticipate your reactions.

By being unpredictable, you'd make it challenging for others to form a fixed perception of you. They wouldn't know what to expect, and their attempts to gossip or judge you would be met with confusion. You'd ace one exam and struggle in the next, or surprise everyone with a different hairstyle or attitude.

The question remains: is this approach to life effective, or would it lead to mistrust and confusion? Perhaps the answer lies in finding a balance between being authentic and being unpredictable. By embracing this mindset, you might just discover a new way to navigate the complexities of human relationships and perceptions.

What do you think? Should we strive to be more unpredictable, or is it better to stick with what we know?

So...this is 🤯 moment?

I was studying for college exams, trying to wrap my head around this 'call by value' concept in functions. We'd done the usual examples - passing copies of documents, not the originals. After done studying , I was having my dinner, I had a striking thought, how kids inherit traits from their parents. And then it hit me - genetics is basically call-by-value IRL! Think about it. When a kid gets their parents' genes, they're not getting the actual original genetic code. They're getting a copy. Just like how a function gets a copy of the original value, not the value itself. The parents' genetic code stays unchanged, just like the original value in the caller function. And the kid's genetic code is its own separate thing, like the local copy of the value in the called function.

Mind. Blown.🙋