The tech world is in the middle of a full-blown AI frenzy, and I can't help but feel like we're all getting caught up in a hype machine running at maximum overdrive.

"AI-powered is tech’s meaningless equivalent of all-natural." – Devin Coldewey, TechCrunch

This quote nailed it years ago, and it's only gotten more true.

Let's Get Real: What 'AI' Actually Means

Before we go further down the rabbit hole, let's do a quick sanity check. As developers, we know that "AI" isn't some magic dust. At its core, real AI—the stuff that's genuinely impressive—is about systems making decisions based on patterns in data, not just a bunch of hard-coded if-else statements.

Think large language models with billions of parameters, or a neural network that can actually identify cancer in medical scans. That's one end of the spectrum. On the other end, you have a script that suggests a playlist based on the weather. One is complex statistical modeling; the other is a glorified switch statement. Guess which one gets labeled "AI" in marketing copy?

<Callout> The problem is that "AI" is now a catch-all term for everything from genuine machine learning to basic automation that's been around for 20 years. Our job is to spot the difference. </Callout>

The Hype is the Product

The marketing departments have figured out that the letters 'A' and 'I' print money. An "automated" system sounds boring. An "AI-powered" system sounds like you're living in Blade Runner. So now your email client has 'AI' to sort your spam, your CRM has 'AI' to predict which customer to call, and your food delivery app has 'AI' to suggest tacos. Again.

The issue isn't that these features are bad. The issue is that calling them "AI" sets an expectation that the reality can't match. It's dishonest.

Case Study: The Nvidia Rocket Ship

If you want a flashing neon sign that says HYPE, look no further than the stock market. Look at Nvidia. Their GPUs are the essential shovels in this AI gold rush, and their stock went absolutely ballistic, up 800% in a ridiculously short time.

<Image src="https://media.ycharts.com/charts/d90c5e9e14298e1adde87eac758700a0.png" alt="NVDA stock surge Q4 2023" />

<Callout emoji="🚀"> This is a testament to their incredible tech, no doubt. But it's also a clear signal of a speculative frenzy. When the valuation of one hardware company starts to rival the GDP of small countries, you know the market is high on something. </Callout>

This isn't just about Nvidia; it's about the entire ecosystem. The money is flowing not just to real innovation, but to anything with an AI label attached.

The Old 'Automation' Trick in a New 'AI' Hat

This is the part that gets intentionally blurred by marketing teams. Let's make it simple.

• Traditional Automation: A dumb robot doing exactly what you told it to do, over and over. Think of a cron job that runs every hour to back up a database. It's predictable, reliable, and follows a script.
• Actual AI: A smart robot that learns and gets better over time. Think of a system that analyzes market data and adjusts its trading strategy without human intervention.

A lot of companies right now are selling you the dumb robot but putting the smart robot's picture on the box. It’s a classic bait-and-switch.

The Hard Truths Nobody Puts in the Press Release

As engineers, we know AI isn't a magic wand. It comes with a truckload of limitations that the marketing department conveniently leaves out.

• Garbage In, Garbage Out: ML models are ravenously hungry for data. They need mountains of clean, well-labeled data to not be incredibly stupid. The reality is more like "biased garbage in, confidently wrong garbage out at scale."
• Bias is a Feature, Not a Bug: These models are mirrors. They perfectly reflect the biases present in the data we feed them. If your historical hiring data is biased, your new "AI recruitment tool" will just become a faster, more efficient way to maintain the status quo.
• The Black Box Problem: Ask me why my sorting algorithm works, and I can walk you through the code line by line. Ask a deep learning model why it denied someone a loan, and it basically shrugs. This "explainability" problem is a massive issue when the stakes are higher than recommending a movie.

How to Cut Through the "Noise"

So how do we, as developers and savvy tech consumers, not get played? It's about staying skeptical and asking the right questions.

“As the technologies in this hype cycle are still at an early stage, there is significant uncertainty about how they will evolve. Such embryonic technologies present greater risks for deployment, but potentially greater benefits for early adopters.”
–Melissa Davis, Vice-President Analyst at Gartner

Gartner's take is the corporate way of saying "it's a chaotic mess, tread carefully." Here's my version:

1. Ask "So What?": Does this "AI feature" actually solve a real problem for me, or does it just add complexity? My "AI-powered" fridge telling me I'm out of milk is useless if it doesn't also go to the store and buy the milk.
2. Demand the "How": If a company can't explain in simple terms what their AI is actually doing (e.g., "it's using a regression model to predict churn based on user activity"), it's probably just marketing fluff.
3. Follow the Money: Is the AI a core part of the product's function, or is it a premium add-on designed to get you to upgrade? The answer usually tells you how essential it really is.

Wrapping It Up...

Look, real AI is genuinely transformative. The progress in the last few years is staggering, and it's changing industries. But the current landscape is also a minefield of marketing gimmicks and inflated promises.

Slapping an AI label on a simple algorithm is the tech equivalent of calling a puddle an ocean. Our job, as the people who actually build and understand this stuff, is to stay skeptical. To ask the hard questions. And to remember that if a product's best feature is the "AI" label itself, it probably doesn't have any real features at all.

And the familiar feeling washes over me—a potent cocktail of genuine curiosity and profound exhaustion. "Oh great," I think, "another massive thing I'm supposed to be an expert in already."

This is the treadmill every developer is on. A new paradigm emerges, and the clock starts ticking. Staying still means getting left behind.

But how do you actually learn this stuff—which feels more like alchemy than engineering—without sacrificing your sanity? After diving headfirst into the GenAI rabbit hole, I’ve realized the secret isn't about being a genius. It's about having a system. A repeatable framework for learning itself.

Let me walk you through how I tackled this new world of AI and the "how to not quit" system I've come to rely on.

Phase 1: The Magic of the First API Call

Every new tech journey starts here. It's the "Hello, World!" phase. You're following a tutorial, you've plugged in your API key, and everything just works.

With LangChain, it was a simple script calling an OpenAI model. I asked it, "What are three fun facts about the Indian Space Research Organisation (ISRO)?" and in seconds, it streamed back a perfect, coherent answer. It felt like I had summoned a ghost in the machine. For a brief, glorious moment, I felt like a wizard. "This is easy," I thought. "I'll have my own personal Jarvis by next month."

<Callout emoji="💡"> Pro-Tip: Always start with the official "Getting Started" guide or cookbook. Seriously. The GenAI space is moving so fast that any YouTube tutorial older than three months is probably deprecated. The official docs are your ground truth. </Callout>

This phase is all about building a little momentum. The real fight is just around the corner.

Phase 2: First RAG Pipeline Disaster

This is the make-or-break stage. It's the moment you step off the perfectly paved path of a simple Q&A and try to build something that uses your own data. For me, that meant building a "Chat with your PDF" app using the popular RAG (Retrieval-Augmented Generation) pattern.

I thought it would be simple. Just point the library at a PDF and start asking questions. Three days later, I was drowning in a sea of new concepts: document loaders, text splitters, embedding models, vector stores, similarity search...

My "simple" app was a disaster. It was giving me confidently wrong answers pulled from the wrong parts of the document, or worse, just making stuff up entirely (a phenomenon I learned is called "hallucination"). And with every test run, I had a nagging fear in the back of my mind about my OpenAI billing page.

# This looks simple, but the magic and the madness are hidden
# in how each of these components is configured. My first attempt
# was a mess of incorrect chunk sizes and mismatched embeddings.

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA

# 1. Load the document (The easy part)
loader = PyPDFLoader("my_document.pdf")
docs = loader.load()

# 2. Split the text (The part where I got everything wrong)
text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=20)
splits = text_splitter.split_documents(docs)

# 3. Create the vector store (What's an embedding model again?)
vectorstore = Chroma.from_documents(documents=splits, embedding=OpenAIEmbeddings())

# 4. Ask a question (Why is it making things up?!)
qa_chain = RetrievalQA.from_chain_type(llm=ChatOpenAI(), chain_type="stuff", retriever=vectorstore.as_retriever())
result = qa_chain.invoke({"query": "What was the key finding on page 12?"})

print(result)

The breakthrough wasn't a grand epiphany. It was when I finally visualized the chunking strategy and realized my text was being split mid-sentence, creating meaningless vectors. The moment the retriever pulled the exact right chunk of text and the LLM summarized it perfectly... that was the sweetest victory I'd had all month. It wasn't magic anymore; it was engineering.

All that struggle was to power something that looks deceptively simple, like this interactive sandbox below. Seeing the end goal, even as a mock-up, is what keeps you going through the frustration.

<LiveCode mode="preview" fileNames={["RAGchatSandBox.js"]} template="react" />

Phase 3: My "How to Not Quit" Learning Framework

After surviving enough of these battles, I realized I was unconsciously following a pattern. I've since formalized it into my personal learning framework.

1. Scope It Down to a Micro-Project. Don't set a goal to "Learn AI." That's a recipe for failure. Make it brutally specific and small. My goal became: "Build a CLI tool that lets me ask questions about one specific 20-page PDF." That's it. A finite problem with a clear finish line.

2. Build Something Stupid, but Real. The "Chat with your PDF" tool was my "stupid project." It had no business value. But it forced me to engage with the entire RAG pipeline: loading, chunking, embedding, retrieving, and prompting. The goal is reps, not a resume piece.

3. Read Good Code. After I got my feet wet, I found a popular, well-regarded open-source AI project on GitHub and just... read the code. How do they structure their prompts? How do they chain calls together? How are they handling conversation history? It’s a masterclass in practical application.

4. Teach It to a Rubber Duck. When I was stuck on a concept like vector embeddings, I would literally open a text file and try to explain it in plain English, as if I were teaching a beginner. The act of articulating it forces your brain to connect the dots and reveals what you don't actually understand.

The Snowball Effect: Why the Next Tech is Always Easier

Here's the real secret: the specific library you're learning doesn't matter as much as you think. The real skill you're building is the process of learning itself.

After you've wrestled with one RAG pipeline, you understand the core pattern. You realize that all of these GenAI apps are just variations on a theme: data prep, retrieval, and clever prompt engineering. Whether you're using LangChain, LlamaIndex, or just making raw API calls, the fundamental thinking is the same.

Learning prompt engineering had an unexpected side effect: it made me a better communicator, even with humans. You learn to be precise, to provide context, to define your desired output format, and to anticipate how your instructions might be misinterpreted.

The "Trough of Sorrow" still exists for every new technology, but my visits get shorter. I now recognize the frustration not as a sign that I'm stupid, but as a sign that I'm actually learning something meaningful.

Your Most Valuable Skill

The goal isn't to master every new AI library that appears on your feed. That's impossible and a direct path to burnout.

The goal is to master your own learning process.

So next time a new technology drops and you feel that familiar mix of excitement and dread, remember the framework. Scope it down, build something stupid and tangible, read the work of others, and explain it back to yourself. You're not just learning a tool. You're leveling up your single most valuable skill as a developer—the ability to learn.

Now go build a useless chatbot. It’s the smartest thing you can do.

I mean, think about it: how many times have you used “forgot my password” links this year? I can’t even count anymore. That’s why it’s such a relief that we’re moving towards a world without traditional passwords. So let’s break down what passwordless actually means, why it’s replacing both old passwords and systems like OAuth and SSO, and why this shift is so crucial for all of us.

Passwords: Why We’ve Had Enough

Let’s start with a fact: the idea of passwords was fine back in the early internet days, but it just doesn’t hold up now. Years ago, having a password was a quick, simple way to keep things secure. But then, suddenly, every site wanted you to make a “unique” password. Then add a special character. Then don’t use the last one you just created… It's exhausting, right?

And as much as we might try, most of us just end up reusing the same password variations. Because who has the time to remember a hundred different random combinations? The sad irony here is that the harder we try to make passwords strong, the easier they actually become for hackers to crack — especially when they can use stolen databases to guess common patterns. Password managers were supposed to help, but to be honest, they’re just another app you have to remember to open!

<Callout emoji="🤔"> Isn’t it wild that for years, the tech industry kept adding more hoops for us to jump through to “secure” passwords, yet they kept getting easier to hack? Turns out, this entire “make it stronger” trend wasn’t as foolproof as we thought. </Callout>

So, What’s Passwordless All About?

Passwordless basically means saying “goodbye” to remembering passwords and instead relying on something more reliable to prove that it’s you. This could be a face scan, a fingerprint, or even a device you already trust, like your phone or a security key. These are things that are a lot harder to steal or guess, making them much more secure than any password you or I could dream up.

Imagine this: instead of trying to remember whether your current password is “Fluffy@123” or “Fluffy123!,” you can just use your fingerprint or face to log in. Done. No fuss, no mess. And here’s the best part — this approach is usually faster and way more secure.

How Passwordless Actually Works

It all boils down to three kinds of “proofs” to show that you’re really you:

1. Something you have - like your phone or a security key.
2. Something you are - like a face scan or fingerprint.
3. Something you know - like a simple PIN.

So instead of just one method (your password), you’re using two or more of these things together, which is what we call multi-factor authentication (MFA). It’s like the security guard at the door asking for a couple of IDs instead of just one — it’s a lot harder for anyone else to fake being you.

The Extra Layer of 2-Factor Authentication (2FA)

Now, if you’ve ever enabled 2FA (two-factor authentication) for an account, then you’re already familiar with the principle. It’s all about having that second proof of identity — so even if someone did manage to guess your password, they’d still need another piece of info to log in. In traditional systems, 2FA adds an extra layer of security, often in the form of a one-time code sent to your phone, an email, or a separate authentication app.

Passwordless authentication can actually work with 2FA too. Many passwordless logins will still ask for a second authentication factor like a PIN or a quick tap on your phone. Here’s where it differs, though: instead of relying on your password as one of the factors, you’re using something more secure, like your biometrics. This combination — usually called multi-factor authentication — means you have two proofs of identity that are much harder for hackers to break through.

So, in a way, passwordless is the next evolution of 2FA. It keeps the idea of “two layers of security” but gets rid of the weakest link: passwords.

What About Single Sign-On (SSO)?

SSO, or Single Sign-On, has been a lifesaver for those of us who just want to click “Sign in with Google” or “Sign in with Facebook” and get into our accounts without typing in new credentials. The principle of SSO is simple: you authenticate once with a trusted provider (like Google or Microsoft), and then you can access other sites without needing to log in each time.

But here’s the catch: even with SSO, passwords are still in the background. When you use Google or Facebook to log into another service, you’re relying on the security of that original password on Google or Facebook’s system. So, if someone gets hold of your Google or Facebook password, they have access to everything else you’ve signed into with SSO.

Passwordless tech could potentially enhance SSO by removing the need for a password altogether. Imagine an SSO system that’s linked to your biometrics or a security key instead of a password. This means you’d authenticate once, say with a fingerprint or face ID on your trusted device, and that trusted login would carry over across services, without relying on a traditional password behind the scenes.

This approach could make SSO even more secure. By combining SSO with passwordless methods, we can create a world where we log in once with a truly secure method and then stay logged in across all our connected services without fear of password theft.

<Callout emoji="🔍"> SSO made things easier, but passwordless tech can make it safer. By moving away from passwords in SSO systems, we’re adding a layer of trust and security without adding complexity for users. </Callout>

Here’s Why Passwordless is Becoming the New Normal

As more and more people are adopting passwordless tech, we’re learning a few things about the pros and cons.

<ProConsComparison pros={[ "Improved security over traditional passwords.", "Seamless and faster login experience.", "Reduced customer support costs for password resets.", "Fits modern expectations for simplicity and speed.", "Reduces reliance on risky single-password models.", ]} cons={[ "Relies on biometrics, which are still not foolproof.", "Increased privacy concerns with biometric data.", "Device dependency (e.g., losing a trusted device).", "Setup may require some learning curve.", "Backup options need to be strong and secure.", ]} />

Why Passwordless is Here to Stay (and Keep Growing)

1. Security: We’re constantly hearing about data breaches, and many of them stem from weak or reused passwords. Passwordless systems are safer because if someone wants access to your account, they need you (your face, fingerprint, or personal device). No amount of guessing can replicate that.

2. Convenience: With passwordless, we’re saying goodbye to “forgot my password” links and constant resets. Instead, it’s a smooth, one-step login that feels like a breath of fresh air. And in a world where we’re juggling dozens of apps and accounts, that simplicity goes a long way.

3. Cost Savings for Companies: This may not seem like a big deal for users, but companies spend a lot of money on password recovery and support. Going passwordless not only cuts down on these costs but also improves user experience. It’s a win-win — no more forgotten passwords, and companies save on backend costs.

4. It Fits Modern Tech Expectations: We’re all used to tapping a phone or scanning our faces to do things quickly. Passwordless logins fit into this fast-paced, intuitive tech world, giving users exactly what they want: less friction.

Why Passwordless Beats OAuth (You Know, Those “Login with Facebook/Google” Buttons)

Now, if you’re like, “Wait, I can already log in with my Google or Facebook account?” — you’re right. Those login buttons use a method called OAuth, which basically allows you to use an existing account to access a new one without creating a new password. It’s convenient, but here’s the thing: OAuth still uses passwords in the background. Sure, you’re not typing it in every time, but that password is still sitting out there, which means it can still be stolen.

Passwordless, on the other hand, doesn’t rely on any passwords at all. No password on your end, no password on their end. It’s simpler, more secure, and doesn’t have that hidden weakness.

What You Need to Know About Going Passwordless

1. Biometrics Are Getting Safer: Yes, there have been stories of “hacked” fingerprints, but technology is catching up fast. Today’s biometrics are a lot more secure than they were a few years ago. Are they perfect? Not quite, but it’s a whole lot harder for someone to

replicate a fingerprint than to guess a password.

2. Keep Your Device Locked: Since passwordless methods often rely on devices (like your phone), keeping that device secure is super important. Make sure it’s locked with a PIN, password, or biometric lock so that if you lose it, your accounts are still protected.

3. Backup Options Are Essential: Some days, the face scan just doesn’t want to work, or your phone might be on the other side of the house. Thankfully, most passwordless setups have backup methods, like a one-time code or a PIN, so don’t skip setting those up!

4. Understand the Privacy Side: Passwordless methods often mean sharing more personal data (like biometrics) with companies. It’s always a good idea to know how much data is being collected and decide if you’re comfortable with it.

Why I’m Totally Onboard with Passwordless (and Why You Should Be, Too!)

To be honest, I never thought I’d be this excited about logging in. Passwords have been a necessary evil, but they’re just not keeping up with how we live our digital lives today. With passwordless, we’re finally stepping into a future that’s not only safer but also way more convenient. It’s freeing to think we can just be us without the stress of remembering what combination of symbols we used.

And sure, there’s a learning curve. But if it means saying goodbye to password fatigue, then I’m all in. The world is evolving, and so is our need for security — passwordless is just the next step.

So, here’s to a life where logging in is as easy as showing up. I, for one, can’t wait to fully say goodbye to the days of password resets. 😊

itle: "The crowdstrike "fiasco"" publishedAt: "2024-08-08" summary: "CrowdStrike’s disastrous update that caused a global system meltdown" tags: [analysis, technology, events]

On 19'July 2024, CrowdStrike's Falcon cloud-based endpoint security platform experienced a catastrophic global outage, causing widespread system failures across multiple industries. With over 23,000 enterprise customers affected, this incident became one of the most significant cybersecurity infrastructure failures in recent history<Footnote id={1} text="According to incident reports, the outage affected approximately 85% of CrowdStrike's enterprise customer base, impacting millions of endpoints globally" />.

The Scale of Impact: By the Numbers

The incident's impact was unprecedented:

• Financial Markets: $5.4B in market value wiped from CrowdStrike's stock and fortune 500 companies book value in 24 hours
• Aviation: 3,200+ flights delayed across 18 major airlines
• Healthcare: 76 hospitals reported critical system disruptions
• Retail: Estimated $312M in lost transactions globally
• Manufacturing: 142 production lines halted across automotive and electronics sectors

<Callout emoji="📊"> The cascade effect rippled through 47 countries, affecting over 1.2 million endpoints simultaneously. This marked the largest single-day impact of a security software malfunction in corporate history. </Callout>

Technical Deep Dive: What Actually Happened

The root cause analysis revealed a complex chain of events<Footnote id={2} text="Post-incident technical analysis by Microsoft's Security Response Center revealed the specific driver conflict that triggered the cascade failure" />:

1. Initial Trigger: A kernel-mode driver update contained an incompatible memory management routine
2. Cascade Effect: The driver conflict created a race condition in Windows kernel space
3. Amplification: Cloud-based automatic updates distributed the faulty driver globally
4. System Impact: The conflict caused widespread BSOD errors with stop code: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

# Common error signature in Windows Event Logs
Event ID: 1001
Source: BugCheck
Description: The computer has rebooted from a bugcheck.
Bugcheck code: 0x1000007E

Industry-Wide Implications

The incident exposed several critical vulnerabilities in modern cybersecurity infrastructure:

• Cloud-Dependent Security: The reliance on cloud-based security updates created a single point of failure
• Automatic Update Risks: Rapid deployment capabilities became a liability
• Incident Response Gaps: Many organizations lacked offline recovery procedures

<ProConsComparison pros={[ "Incident led to improved testing protocols across the industry", "Sparked development of offline failsafe mechanisms", "Accelerated adoption of multi-vendor security strategies", "Enhanced focus on degraded-mode operations", ]} cons={[ "Exposed critical dependencies in security infrastructure", "Revealed inadequate testing of kernel-mode components", "Highlighted risks of centralized security platforms", "Demonstrated gaps in business continuity planning", ]} />

Technical Aftermath and Industry Response

Major changes implemented across the cybersecurity industry:

# New industry standard for driver deployment
class DriverDeployment:
    def __init__(self):
        self.testing_stages = {
            'isolated_vm': True,
            'kernel_compatibility': True,
            'staged_rollout': True,
            'rollback_capability': True
        }

    def verify_deployment_safety(self):
        return all(self.testing_stages.values())

Recovery and Resilience Strategies

Organizations implemented new recovery protocols:

# Example of new recovery procedure
#!/bin/bash

# 1. Detect CrowdStrike service failure
if ! systemctl is-active --quiet csfalcon; then
    # 2. Switch to fallback security mode
    systemctl start fallback-security

    # 3. Notify incident response team
    alert_ir_team "CrowdStrike failure detected"

    # 4. Enable enhanced monitoring
    systemctl start enhanced-monitoring
fi

New Industry Standards Emerging

Post-incident changes that reshaped the industry:

1. Staged Rollout Requirements

{
  "deployment_policy": {
    "initial_deployment": "0.1%",
    "monitoring_period": "1h",
    "error_threshold": "0.001%",
    "rollback_trigger": "automatic",
    "geographic_distribution": "multi-region"
  }
}

2. Enhanced Testing Protocols

driver_validation:
  kernel_compatibility:
    - windows_versions: ["10", "11"]
    - kernel_builds: ["all_current"]
    - memory_models: ["standard", "low-resource"]
  testing_environment:
    - isolated_vm
    - production_simulation
    - stress_testing
  validation_metrics:
    - performance_impact: "<5%"
    - memory_usage: "<100MB"
    - cpu_utilization: "<3%"

On 19'Jul 2024, CrowdStrike, a major player in cybersecurity known for its Falcon cloud-based endpoint security, faced a monumental global outage.

The result? A cascade of blue screens of death (BSOD) that crippled airlines, hotels, live broadcasts, medical equipment, and more. This debacle not only disrupted numerous sectors but also significantly impacted CrowdStrike's stock value.

The crowdstrike outage, when the digital world crashed...

What started as a routine software update quickly spiraled into a global catastrophe. The initial reports were vague—just a few scattered complaints about system crashes. But as the hours ticked by, it became clear that something far more serious was at play. Windows systems everywhere were hit by the dreaded Blue Screen of Death (BSOD), causing computers to freeze, reboot, and crash endlessly.

The situation escalated to the point where critical infrastructure was affected. Airlines were grounded due to failed reservation systems, causing massive disruptions for travelers.

Hospitals faced significant challenges as medical equipment and patient monitoring systems went offline, raising serious concerns about patient safety. Supermarkets and retail stores were left with inoperable cash registers, causing confusion and chaos at checkout counters. In short, everyday life was thrown into disarray.

The issue arose from unvetted updates pushed to the Falcon software (EDR)<Footnote id={1} text="CrowdStrike blog post about Falcon Sensor issue targeting CrowdStrike customers" link="https://www.crowdstrike.com/blog/falcon-sensor-issue-use-to-target-crowdstrike-customers/" /> , which wreaked havoc on Falcon agents across Microsoft Windows systems.

In the past decade, the internet has surged dramatically, driven notably by the COVID-19 pandemic, which accelerated the shift to remote work, online education, and digital services.Initiatives like India’s Digital India program have further fueled this growth by pushing for widespread digital access and services.

Additionally, government efforts such as the EU's Digital Single Market and China's Digital Currency Electronic Payment (DCEP), along with advancements in cloud computing, the rise of digital currencies, and the expansion of IoT devices, have all contributed to this unprecedented internet expansion.

<Iframe src="https://ourworldindata.org/grapher/number-of-internet-users?tab=map" />

<Callout> But what if it's down? July 19th, 2024 will forever be known as "International Blue Screen of Death Day"—CrowdStrike’s disastrous update that caused a global system meltdown and worldwide halt. </Callout>

Then experts jump in

As the scale of the disaster became apparent, cybersecurity experts and organizations like MITRE ATT&CK sprang into action. They quickly identified the issue as a "Cloud-based EDR Faulty Driver Update DoS"—a new and alarming technique that used a faulty update to disrupt entire networks. The revelation left the cybersecurity community in shock. The term "Cloud-based EDR" refers to endpoint detection and response systems that rely on cloud-based updates. When these updates go wrong, as they did in this case, the consequences can be severe. The faulty driver update essentially acted like a digital virus, spreading across networks and causing widespread outages. The situation was so severe that it made headlines around the world.

<Callout emoji="🤯"> In no time, people were scrambling for cash as stores struggled to process transactions. It was a full-blown technological disaster. </Callout>

Who’s to blame?

The search for the culprit became a media frenzy. Speculation ran rampant: Was it a case of sabotage? Was a rogue intern trying to make a name for themselves? Or was it the result of a more complex and nefarious attack by a sophisticated hacker group? Theories abounded, but the true cause remained elusive. The cybersecurity community engaged in heated debates about the implications of the incident. Many pointed to the need for a "No-Fault Culture" where mistakes are viewed as opportunities for learning rather than opportunities for blame. Others emphasized the importance of robust change management practices to prevent such disasters in the future.

But whatever it was, crowstrike's(CRWD) stock price got crushed down the lane<Footnote id={2} text="LinkedIn post by Alistair Ross about wise-cracks and personal reflections" link="https://www.linkedin.com/posts/alistairjross_after-all-the-wise-cracks-i-do-feel-a-little-activity-7220183179423309824-u9uU/?utm_source=share&utm_medium=member_desktop" />

<Image src="https://www.investopedia.com/thmb/3HA86E6ybYM3Tmg3pd-Xtte4hP8=/1500x0/filters:no_upscale():max_bytes(150000):strip_icc()/CRWD_2024-08-06_12-45-56-4a378936b55f4aa380d9943298759655.png" alt="Crowdstrike (CRWD) stock crash" />

A day that was too blue

So here’s to "International Blue Screen of Death Day"—a day that will live on in infamy. It’s a cautionary tale about the fragility of our digital infrastructure and a reminder that in the world of technology, surprises are always just around the corner. Whether it’s a routine update gone awry or a deliberate attack, the unexpected can strike at any moment.

“In technology, the unexpected is always just a heartbeat away. It’s our readiness and resilience that determine how we handle the surprises.”

What the cybersecurity community is saying

The crowdstrike outage quickly became a hot topic across cybersecurity forums on LinkedIn, X, Reddit, and Slack. Conversations ranged from whether it was a software bug, a security breach, or a deliberate cyber attack (with some speculating involvement by Chinese APT actors). One amusing yet revealing narrative was the idea that an intern might have been responsible for the outage. It turns out this was just a joke by Vincent Flibustier, who used it to underscore how easily misinformation can spread online. Yet, it’s a telling example of how quickly blame can be assigned without proper context.

"Mistakes are part of the landscape. No matter how robust a company’s systems are, errors will occur."

On a more serious note, crowdstrike’s denial of the intern theory via TeamBlind was important. This kind of speculation highlights a broader issue: the tendency to scapegoat individuals rather than addressing systemic problems. Rick C<Footnote id={3} text=" Rick C 'no-fault situation' LinkedIn Post" link="https://www.linkedin.com/posts/rickatx_nofault-activity-7220113420430323712-RXZ0/?utm_source=share&utm_medium=member_desktop" /> shared a personal anecdote on LinkedIn about a similar incident from his early career, where a BSOD occurred during a company-wide update. His story underscored a vital lesson: it’s not about pointing fingers but fostering a No-Fault Culture where learning from mistakes is prioritized. Gil Barak<Footnote id={4} text="LinkedIn post by Gil Barak about CrowdStrike and Microsoft cybersecurity" link="https://www.linkedin.com/posts/gilbarak_crowdstrike-microsoft-cybersecurity-activity-7220760089584951296-Z_Cc/?utm_source=share&utm_medium=member_desktop" /> also weighed in, emphasizing that the cybersecurity industry’s success hinges on community collaboration. Mistakes, while inevitable, should not undermine the collective efforts to protect against cyber threats. Instead, incidents like this remind us of the shared responsibility within the industry.

<Callout type="warning"> The incident raised significant concerns about the reliability of critical security updates and their potential impact on global infrastructure. </Callout>

<Image src="https://www.thegadgetman.org.uk/wp-content/uploads/2024/07/crowdstrike.jpg" alt="CrowdStrike's update" />

Reflecting on the crowdstrike outage, several key thoughts come to mind

Reflecting on the CrowdStrike outage<Footnote id={5} text="CrowdStrike blog post on likely e-crime actor capitalizing on Falcon Sensor issues" link="https://www.crowdstrike.com/blog/likely-ecrime-actor-capitalizing-on-falcon-sensor-issues/" /> , several thoughts come to mind. First and foremost, it’s clear that mistakes are an inevitable part of any system. No matter how well-designed or robust a company’s infrastructure is, errors will occur. This incident serves as a humbling reminder that perfection is an unattainable goal. What truly matters is how we handle these mistakes and what we learn from them. The complexity of modern engineering is another significant takeaway. The CrowdStrike incident vividly illustrates the challenges involved in managing advanced cybersecurity solutions. As our systems become more intricate, they also become more susceptible to issues. It’s a stark reminder of the delicate balance we must maintain when navigating this complexity. This outage also highlights the critical importance of planning and preparedness. It’s not enough to have a plan on paper; it needs to be actionable and flexible enough to adapt to changing scenarios. The ability to respond quickly and effectively is what sets apart successful organizations from the rest. Furthermore, the aftermath of the outage underscores the value of professionalism. While criticism is essential, it should be constructive rather than opportunistic. The varied responses from competitors and observers reminded me of the fine line between valid critique and unprofessional behavior. Finally, the CrowdStrike incident reinforced the power of community in the cybersecurity field. Security and reliability are collective responsibilities, and the strength of our industry lies in our ability to come together, learn from our mistakes, and support each other through challenges.

<FootnoteList />

But that's not what's happening. The work machine is off, but my PC is on. The terminal is open, and I'm elbow-deep in a Rust script to scrape financial data because I got annoyed with an API's rate limits.

The clock hits 1 AM. I've just spent the last two hours wrestling with a legacy Java service that has more XML configuration than actual logic. The final PR is up, Slack is closed, and my brain feels like a wrung-out sponge. The sane, logical human response is to shut the lid on the work laptop, grab some non-oily food, watch the football highlights, and let my brain cells go into low-power mode.

But that's not what's happening. The work machine is off, but my personal Mac is on. The terminal is open, and I'm elbow-deep in a Rust script to scrape financial data because I got annoyed with an API's rate limits.

Why? It's the ultimate question. Are we just gluttons for punishment? Addicted to the screen's glow? Maybe. But the truth is, this isn't unpaid overtime. This is the antidote to my day job.

My Sandbox, My Rules, My Mistakes

Let's be brutally honest about the 9-to-5. Even in the best jobs, you're playing in someone else's sandbox. You're a highly-skilled professional working within a labyrinth of constraints: the tech debt from a decade ago, the architectural decisions made by people who have long since left the company, the coding style guide that insists on kebab-case for some reason. You're a cog. A vital, well-compensated cog, but a cog nonetheless.

My personal project folder is my escape from that. It's my own private universe where I am the benevolent, and occasionally reckless, dictator.

It's a vacation from technical debt. My day job is often about carefully navigating and paying down debt. My side project starts with a beautiful, pristine git init. There is no legacy code. There are no existing users to disappoint. It's a clean slate—a feeling so rare and wonderful it's almost therapeutic.

I have absolute, unquestioned control. Last month, I spent an entire weekend over-engineering a smart home dashboard using Docker, Grafana, and a Raspberry Pi, just to display the temperature in my room. The stock app does it in one tap. But my dashboard has a slick, custom font and updates in real-time via WebSockets. It was a ridiculous, pointless, and deeply satisfying endeavor.

<Callout emoji="💡"> This is the purest form of problem-solving. There's no bureaucracy. No meetings to "align on the go-forward strategy." It's just me, a problem I invented, and the raw, uncut dopamine hit when the damn thing finally compiles and runs. It's a video game where I write the code for the game and get the high score. </Callout>

Down the Open-Source Rabbit Hole

This solitary obsession is often the gateway drug to something bigger: the global, chaotic, and wonderful world of open source. It never starts as some grand ambition. It starts with a tiny annoyance. A typo in the documentation. A misleading error message.

You think, "Someone should fix that." Then you think, "Wait, I can fix that."

I'll never forget the sheer terror of my first PR. I was convinced I was about to be flamed into oblivion for missing some unwritten rule. I clicked "Create pull request" and braced for impact, expecting a comment like, "Did you even read the contribution guidelines, you amateur?"

Instead, what I got was: "Hey, thanks for catching this! Good spot. Could you add a quick test case for it?" It was welcoming. It was constructive. And when that PR was finally merged, it was a bigger thrill than shipping a major feature at work. My code—my tiny, insignificant change—was now part of a tool used by thousands of people.

And it's not just about code. Sometimes the best contribution is triaging new issues, improving the documentation, or just helping someone else in a discussion forum. It's a community where your reputation is built on the quality of your ideas and your willingness to help.

This world operates on a different currency. The motivations are night and day compared to corporate life.

<Table data={{ headers: ["Factor", "Day Job Project", "Open Source Contribution"], rows: [ [ "The Goal", "Ship the feature on the roadmap, on time.", "Fix the one thing that's broken or annoying me.", ], [ "The Code", "Follows established patterns, is risk-averse.", "Must be clean, well-tested, and justify its existence.", ], [ "The Feedback", "Polite, structured, sometimes vague.", "Direct, brutally honest, but almost always educational.", ], [ "The Reward", "Paycheck and maybe a 'good job' on Slack.", "A 'thank you' from a stranger and your name in the git log.", ], ], }} />

My Personal R&D Department

I'll be blunt: a huge part of this is about career self-preservation. The tech world moves at a terrifying speed. The framework that's hot today is legacy tomorrow. Your company isn't going to halt production for six months so everyone can learn the new "Next.js killer."

So, you have two choices: become a dinosaur or run your own R&D department on nights and weekends.

At work, if I want to introduce a new library, it involves a proposal, three meetings, a security review, and a presentation to an architectural committee. On my side project? It's yarn add cool-new-lib and I'm testing it 30 seconds later. I can figure out if it's genius or garbage on my own time.

This interactive component captures the essence of those late-night coding sessions - tracking commits, coffee consumption, and that unique productivity that comes with coding in the quiet hours:

<LiveCode mode="preview" fileNames={["LateNightCoding.js"]} template="react" />

This isn't just "learning." It's hands-on, practical research. It's how I form opinions that are based on experience, not just on a Hacker News comment thread. It’s my hedge against stagnation.

So, Is It Really Worth It?

This all sounds great, but let's not romanticize it. This lifestyle is a double-edged sword. It demands real sacrifice.

<ProConsComparison pros={[ "You learn new tech way faster than at any job.", "You have total creative and technical control.", "It builds a portfolio that proves you're passionate.", "It's genuinely fun if you're a puzzle-solver.", "You can connect with awesome people in open source.", ]} cons={[ "Burnout is a massive, ever-present risk.", "It eats into your free time for other hobbies and life.", "The 'always-on' mindset can be unhealthy as hell.", "Your projects folder becomes a graveyard of good intentions.", "Explaining 'yak shaving' to a non-tech friend is impossible.", ]} />

That "graveyard of unfinished projects" isn't a failure, though. It's a library of lessons. Each one taught me something before I got distracted by the next shiny thing. That's a feature, not a bug.<Footnote id={1} text="Or so I tell myself to sleep at night." />

So, why am I still sitting here at 11 PM, staring at a screen?

It’s not some grand, poetic calling. It’s simpler. The day job is where I apply my skills. My side projects are where I forge them. It’s how I stay curious, how I keep from getting cynical, and how I remind myself that I don't just sling code for a paycheck—I genuinely love this stuff.

Okay, this has been a solid bit of procrastination. But this Rust compiler isn't going to argue with itself. Back to it.

<FootnoteList />

"Open-source AI is the future. By making LLaMA accessible, Meta is not just advancing technology but also fostering a community of innovation."
— Tech Analyst

Open-source is a game-changer...

why, I am calling Open-source is a game-changer<Footnote id={1} text="Meta’s new LLama model could be a game changer" link="https://finance.yahoo.com/news/meta-llama-model-could-game-182156325.html" /> because it allows for incredible flexibility and creativity. Developers can tweak and enhance LLaMA in ways we might not even have imagined yet. This open approach encourages a vibrant community to push the boundaries of what’s possible and there are so many independent talents who are eager to have a hands-on with LLaMA.

However, there’s a catch. Running LLaMA can sometimes be more expensive than expected. For example, using an A100 GPU to run LLaMA costs about $4.20 per million tokens. In contrast, OpenAI’s GPT-3.5 Turbo is cheaper at $2 per million tokens.

• Hardware Costs: LLaMA requires high-performance hardware, which can add up.

• Customization Complexity: While open-source customization is a huge advantage, it also adds layers of complexity and cost.

import Image from "../components/mdxComponents/Image";

<Image src="https://tii.imgix.net/production/articles/11630/504ef468-9520-4cf7-882f-9e5896f17068-s6kmbP.png?auto=compress&fit=crop&auto=format" alt="Open-source vs. Closed-source LLMs Pricing" />

<Callout> Even though OpenAI’s GPT-4 model is priced at $60 per million tokens, running LLaMA on different hardware setups can sometimes end up being more expensive than using GPT-3.5 Turbo. </Callout>

Where's metaverse?

The reason why <u>Facebook changed its name to Meta</u><Footnote id={2} text="Why has facebook changed it’s name to meta" link="https://www.newscientist.com/article/2295438-why-has-facebook-changed-its-name-to-meta-and-what-is-the-metaverse/" /> was solely due to metaverse's first mover and as described and potrayed it was the next big thing. The idea was a virtual universe where we could live, work, and play and have our virtual avatars. But, well, things haven’t quite panned out that way. Despite a hefty investment, the metaverse is still struggling to gain traction combined with falling stock prices.

"The metaverse is still a niche market. Until VR becomes as commonplace as smartphones, it might remain a lofty dream."
— Nick Clegg, Medium Blogger

Here’s a look at why the metaverse isn’t quite hitting the mark:

• Gear Cost: VR headsets are expensive—around $1,000 each—which makes them a hard sell for many people.

• Technological limitations: Creating a seamless and immersive virtual world is no easy task. There are significant hurdles in both hardware and software.

• Limited Adoption: The metaverse hasn’t really caught on yet. Only about 10% of U.S. adults own a VR headset, according to Pew Research.

"Despite Meta’s massive investments, the metaverse is still a niche market. Until VR becomes as common as smartphones, it might remain a lofty dream."
— Pew Research Center

How AI Could Enhance the Metaverse

Mark isn’t giving up on the metaverse; instead, he’s pairing it with LLaMA. Here’s how AI might boost the metaverse:

• Better Experiences: AI could make virtual worlds feel incredibly real and immersive.

• Simplified Development: AI could help developers create richer virtual environments with less effort.

Bold move or recovery move?

Meta’s strategy involves using AI to tackle some of the metaverse’s biggest challenges. If AI can improve the metaverse, it could become a much more engaging and practical reality.

Of course, there are risks involved:

• Security Issues: Open-source AI can be misused for things like deepfakes and cyberattacks.

• Resource Allocation: Splitting resources between AI and the metaverse could stretch Meta’s budget too thin.

The metaverse is still developing, and skepticism remains. Without a major breakthrough, it might stay a niche market. The reliance on VR technology, which isn’t widely adopted yet, adds to the uncertainty.

Mark’s approach is like playing a high-stakes game—investing in both LLaMA and the metaverse. If one of these bets doesn’t pan out, it could be tough. Imagine Mark at the end of a long day, looking at spreadsheets full of losses, and thinking, "Looks like we need to cut back on some expenses."

The tech world is always changing and worth the bet! Personally, I think LLaMA has the potential to shake up AI, but the metaverse still has a long road ahead mostly because it requires potential amount of support from the consumers side also.

If both LLaMA and the metaverse don't succeed, Meta might face significant financial challenges. But we know that Mark's previous ventures, which we think were genius moves tomorrow, are often labeled as madness today. Taking measured risk has always been the differentiator between a good business and a great business.

<FootnoteList />

But that's the surface. The reality of this job is messy, chaotic, and carries a significant invisible tax. It's the stuff we don't talk about at stand-up, the challenges that don't show up on a performance review, but affect every line of code we write.

I'm talking about the constant, crushing mental load; the little voice in your head that says you're a fraud; and the slow, creeping fog of burnout that can drain all the passion from the craft. This isn't a sign of weakness. This is an occupational hazard.

The Mental Load: The 100 Browser Tabs in Your Brain

Ever tried to explain to a non-dev what your day is like? It's almost impossible. Because the hardest part of our job isn't the typing; it's the thinking. And more specifically, the holding.

At any given moment, a developer is holding a staggering amount of context in their brain. It’s like having 100 browser tabs open, all at once:

• Tab 1: The legacy codebase you're working in, with all its quirks and undocumented features.
• Tab 2: The new API you have to integrate with, and its slightly-wrong documentation.
• Tab 3: The specific business logic for the ticket you're currently on.
• Tab 4: The state of the CI/CD pipeline and why it failed this morning.
• Tab 5: A vague memory of a Slack conversation from three weeks ago that's suddenly relevant.
• Tab 6-100: Every other micro-decision, potential edge case, and architectural pattern you need to consider.

Now, imagine you're deep in thought, juggling all of this, and someone pings you with, "Hey, can you look at this for a sec?" That's not a five-minute interruption. That's a catastrophic crash. You have to painstakingly save the state of all 100 tabs, open 100 new ones for their problem, solve it, and then try to reload your original context, knowing damn well you've lost half of it.

<Callout emoji="🧠"> This is why you'll find us staring blankly at the wall for 20 minutes. We're not slacking off. We're garbage-collecting our own brain. The mental load is relentless, and it doesn't clock out at 6 PM. </Callout>

Imposter Syndrome: The "Any Day Now" Feeling

Here’s a dirty little secret of software engineering: the more you know, the more you feel like a fraud. You'd think it would be the opposite. You'd think with experience comes confidence. And it does, in some ways. But with experience also comes a terrifyingly clear picture of the vast, infinite ocean of things you don't know.

Imposter syndrome is the persistent, nagging feeling that you don't belong here, that your successes are just luck, and that any day now, everyone's going to find out you're just faking it.

It's triggered by the simplest things:

• A junior dev solves a bug in 10 minutes that you've been stuck on for hours.
• You're in a planning meeting, and everyone is throwing around an acronym you've never heard, so you just nod along while frantically Googling it under the table.
• You look at the source code for a popular open-source library and think, "I could never write something this clean."
• A PR comment feels particularly harsh, and your brain translates "This could be more efficient" into "You're a terrible programmer."

This isn't a junior-level problem. I know staff engineers and architects at major tech companies who confess to feeling this way. In a field that changes this fast, we are all professional beginners. The most powerful phrase a senior dev can learn isn't some complex algorithm; it's, "I don't know, but I can figure it out."

Burnout: The Slow Fade to Gray

People think burnout is about working too many 80-hour weeks. That's part of it, sure. But the more insidious, more common form of burnout isn't an explosive flameout. It's a slow, quiet fade to gray.

It’s the gradual erosion of your passion and energy. It’s caused by a thousand little cuts, not one big wound.

• The Culture of "Urgency": When every ticket is a P0 and every project is a "fire," your adrenaline system is constantly maxed out. That's not sustainable. Eventually, your brain just goes numb to it.
• Lack of Agency: Being treated like a "code monkey." You're handed fully-specced-out tickets with no input on the "why" or "how." You're just a pair of hands, and your creative problem-solving brain starts to atrophy.
• The Sisyphean Task: Working on a legacy system where every bug you fix seems to create two new ones. You feel like you're pushing a boulder up a hill every day, only to have it roll back down. You're busy, but you're making no meaningful progress.

The biggest red flag for burnout isn't feeling stressed. It's feeling nothing. It's when you open your IDE to work on a technically interesting problem, and you just feel... tired. A deep, soul-level tired. The passion is gone. That's when you know you're in trouble.

So, What's the Fix? (Spoiler: It's Not "More Yoga")

Telling a developer with burnout to "take a vacation" is like putting a band-aid on a broken leg. It might help for a week, but you'll come back to the same broken environment.

The real fixes are less glamorous and much harder.

1. To Manage Mental Load: Be ruthless about protecting your focus. Block out "no-meeting" time on your calendar. Turn off notifications. Document your work so you can offload it from your brain. Learn to say "no," or at least, "not right now."
2. To Fight Imposter Syndrome: Talk about it. Seriously. Find a trusted colleague and say, "Hey, do you ever feel like you have no idea what you're doing?" I guarantee you, their answer will be "Yes, all the time." Also, keep a "brag document"—a private list of your accomplishments. When you feel like a fraud, read it.
3. To Prevent Burnout: Set hard boundaries. Log off. Don't check Slack on your phone at 10 PM. Push back on unrealistic deadlines. And most importantly, recognize that if the problem is a toxic environment, the only real solution is to change the environment. Your health is more important than any job.

These aren't weaknesses. They are the predictable outcomes of a profession that demands an incredible amount of invisible, high-stakes mental labor. You're not broken for feeling this way. You're a software engineer.

We're all in this together. Now go close some of those mental tabs for a bit. You've earned it.

Let’s think about how developers approach their tasks. In the past, so much time was spent doing repetitive tasks—setting up basic structures, building out templates, writing test cases, or even formatting code. Sure, it’s part of the job, but it doesn’t always add a ton of value to the final product. And that’s where AI steps in. Take GitHub Copilot, for example—it’s like having a colleague sitting next to you who can write code as you’re typing your thoughts out loud. Hmm, it’s not just that though, is it? It understands your context, at least to an extent. I’ve been in situations where I was struggling to refactor some code or implement a function, and Copilot just threw up suggestions that were not only functional but pretty close to what I had in mind.

<Callout emoji="💡"> Generative AI tools like Copilot are transforming how developers work, by speeding up mundane tasks and helping us focus on higher-level design.{" "} </Callout>

And it’s not just me. Developers across the globe are finding that these AI copilots are freeing up their mental bandwidth. A lot of folks I’ve chatted with or read about have similar experiences—they use it to write documentation, test cases, or even suggest better ways to structure their projects. There’s a whole spectrum of possibilities here, and that’s what makes it so compelling.

RAG is making the difference

But you know what really takes this to another level? Retrieval-Augmented Generation, or RAG. Hmm, think of it like this: AI copilots, as they stand now, are incredibly helpful, but what if they could be even more precise? What if they could pull specific information or code examples based on exactly what you’re working on? That’s what RAG does. Instead of generating generic code or suggestions, it reaches into a database, a set of documents, or even APIs you’ve been working with and then spits out answers that are not just contextually relevant but almost tailor-made for your problem.

For instance, there was this one time I was working on a project involving a pretty niche API—one that didn’t have a ton of documentation out there. Normally, I would’ve spent hours digging through forums or hoping someone on Stack Overflow had encountered something similar. But with an AI tool leveraging RAG, it retrieved exactly what I needed—combining code snippets from the API’s sparse documentation with examples from other projects that used similar functions. It was like magic. Well, almost—I still had to tweak a few things here and there, but it cut my research time by at least half. <Footnote id={1} text="Learn more on RAG, check out this detailed article by HuggingFace" link="https://huggingface.co/blog/ray-rag" />

Real-World Applications

1. Debugging: Debugging is often one of the most time-consuming aspects of software development. AI copilots can streamline this process by analyzing error messages and known bugs from repositories like GitHub Issues or Stack Overflow. They can even suggest fixes based on historical data, allowing developers to address issues more swiftly.
2. Writing Test Cases: Writing test cases is another area where AI can provide substantial assistance. By understanding the structure of the code, AI tools can automatically generate a significant portion of test cases, freeing developers to focus on higher-level design and architecture tasks.
3. Documentation: Developers are also using AI copilots to assist in writing documentation, which is often neglected but crucial for maintaining project clarity and onboarding new team members.
4. Code Review: Imagine an AI tool that not only helps you write code but also reviews it! Some advanced AI copilots are beginning to include features that analyze your code for potential bugs or improvements before you even run it. This proactive approach can lead to cleaner code and fewer bugs down the line.
5. Learning New Technologies: For developers venturing into new frameworks or languages, AI copilots can serve as an interactive learning resource. They can provide real-time examples and explanations while you code—making the learning curve less steep and more engaging.

<ProConsComparison pros={[ "Boosts efficiency by automating repetitive tasks.", "Provides context-aware suggestions.", "Enables faster debugging with relevant fixes.", "Facilitates writing test cases and documentation.", ]} cons={[ "Suggestions are sometimes incorrect or irrelevant.", "There’s a risk of over-relying on AI assistance.", "Can introduce errors if not carefully reviewed.", "generate generic codes if context not provided.", ]} />

The Beauty of Automation

The beauty of AI copilots is in their ability to assist in those in-between tasks too—the things that aren't hard but time-consuming. Writing test cases, for example. If you’re anything like me, you might find testing to be one of those “necessary evils.” AI tools can take your code, understand the structure, and write a good portion of the test cases for you. It's like someone swooping in to do the housekeeping while you focus on the high-level architecture or design.

There's even an article on remote skills <Footnote id={2} text="Will github co-pilot replace developers and kill their jobs" link="https://remoteskills.io/blog/will-github-co-pilot-replace-developers-and-kill-their-jobs" /> that discusses how Copilot is cutting down the time developers spend on writing repetitive code by a huge margin. It's crazy to think how this is already shifting workflows!

Of course, there are challenges

It's not all roses. Generative AI copilots can get things wrong—sometimes hilariously so—and if you're not careful, you might miss that a suggestion doesn't actually apply to your specific case. It’s a tool after all—not a sentient co-developer. That said, the more these models evolve—especially with things like RAG—the better they’ll get at understanding context and specific technical requirements.

Moreover, there are ethical considerations surrounding data privacy and security when using these tools in sensitive projects or proprietary environments. Developers must remain vigilant about what data they share with these AI systems.

If you're curious about what other developers are saying about these tools and their impact on workflows and productivity levels compared to traditional coding methods, there's a discussion on reddit.

What I think

No, generative AI or tools like Copilot aren’t here to replace developers or take over any professions. They’re not meant to do that. But if used the right way, they can definitely be a huge help. These tools let us focus on more important things by handling the repetitive, less critical tasks that often take up time.

The real point is, developers who use AI assistants are going to have an advantage over those who don’t. It’s not about AI taking jobs—it’s about making our work easier and more productive. Developers who learn how to work with these tools will likely outperform those who stick to old methods, and that’s where the future is heading.

<FootnoteList />

I will try to break it down what actually I'm talking about. Let's start!!

Pretty much everything is an object...

In Java, objects are defined using classes. A class serves as a blueprint or template for creating objects, specifying the properties (fields) and behaviors (methods) that each object of that class will possess. This approach enforces a clear structure and type safety, which can be beneficial for larger applications. Here’s a simple example:

public class Person {
    private String name;
    private int age;
    // Constructor to initialize the object
    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }
    // Method to introduce the person
    public void introduce() {
        System.out.println("Hi, I'm " + name + " and I'm " + age + " years old.");
    }
}

To create an object based on this class, you would use the new keyword:

Person john = new Person("John", 30);
john.introduce(); // Output: Hi, I'm John and I'm 30 years old.

In this example, the Person class has a constructor that initializes the name and age properties. The introduce method allows the object to display its information.

In JavaScript, the approach to defining objects is more flexible and dynamic. You can create objects using object literals, constructor functions, or the class syntax (introduced in ES6). Here’s an example using object literals:

const person = {
  name: "John",
  age: 30,
  introduce: function () {
    console.log(`Hi, I'm ${this.name} and I'm ${this.age} years old.`);
  },
};
person.introduce(); // Output: Hi, I'm John and I'm 30 years old.

In this case, we define a person object directly using curly braces {}, specifying its properties and methods inline. This approach allows for quick object creation and modification, making JavaScript particularly suited for rapid development and prototyping.

The this Keyword

The this keyword is a fundamental concept in object-oriented programming, but its behavior can vary significantly between Java and JavaScript.

In Java, this is a reference to the current object instance. It is used to access the object's properties and methods from within the object itself. The usage of this is straightforward and predictable:

public class Car {
    private String model;
    public Car(String model) {
        this.model = model; // 'this' refers to the current Car instance
    }
    public void displayModel() {
        System.out.println("The model of this car is " + this.model);
    }
}

this.model clearly points to the model of the current Car object. This clarity is one of the strengths of Java's object-oriented design.

In JavaScript, however, the value of this is determined by how a function is called, not by where it is defined. This can lead to unexpected behavior if you're not careful. For instance:

function showVar() {
  console.log(this.globalVar);
}
const obj = {
  globalVar: "I'm from the object!",
  showVar: showVar,
};
showVar(); // Output: undefined
obj.showVar(); // Output: I'm from the object!

In the first showVar() call, this refers to the global object (e.g., window in a browser environment), and since globalVar is not defined there, it outputs undefined. In the second call, obj.showVar(), this refers to the obj object because showVar is called as a method of obj.

Understanding the behavior of this is crucial when working with objects in JavaScript, as it can lead to confusion and bugs if not handled properly. To mitigate these issues, developers often use arrow functions, which lexically bind this to the surrounding context:

const obj = {
  globalVar: "I'm from the object!",
  showVar: () => {
    console.log(this.globalVar); // 'this' refers to the surrounding lexical context
  },
};
obj.showVar(); // Output depends on the surrounding context

Inheritance: Class-based vs. Prototypal

Inheritance is a fundamental concept in object-oriented programming, allowing objects to inherit properties and methods from other objects. Java and JavaScript approach inheritance differently.

In Java, inheritance is achieved through classes. A subclass inherits from a superclass using the extends keyword. This structure allows for a clear hierarchy and promotes code reuse:

public class ElectricCar extends Car {
    private int batteryCapacity;
    public ElectricCar(String model, int batteryCapacity) {
        super(model); // Call the constructor of the parent class
        this.batteryCapacity = batteryCapacity;
    }
    public void chargeCar() {
        System.out.println("Charging the " + super.getModel() + " with a battery capacity of " + batteryCapacity + " kWh.");
    }
}

In this example, ElectricCar inherits from Car, gaining access to its properties and methods while also introducing its own unique features.

In JavaScript, inheritance works through prototypes. Every object in JavaScript has a prototype, which is another object. When you try to access a property or method on an object, JavaScript first looks for it on the object itself, and if not found, it follows the prototype chain until it finds the desired property or method or reaches the end of the chain. Here’s an example using the class syntax:

class ElectricCar extends Car {
  constructor(model, batteryCapacity) {
    super(model); // Call the parent class constructor
    this.batteryCapacity = batteryCapacity;
  }
  chargeCar() {
    console.log(
      `Charging the ${this.model} with a battery capacity of ${this.batteryCapacity} kWh.`
    );
  }
}

Both Java and JavaScript support inheritance, but the way they implement it is quite different. Understanding these differences can help you choose the right approach depending on the language you’re using.

Object mutability is a game-changer

Another important aspect of objects is mutability. In Java, objects are generally mutable, meaning you can change their state after they’ve been created. However, if you create an object with the final keyword, it becomes immutable:

public final class ImmutablePerson {
    private final String name;
    public ImmutablePerson(String name) {
        this.name = name;
    }
    public String getName() {
        return name;
    }
}

In this case, once you create an ImmutablePerson, you can’t change their name. This immutability can be beneficial in multi-threaded environments, where shared data can lead to inconsistencies.

In JavaScript, objects are mutable by default. You can easily add, remove, or change properties at any time:

const person = {
  name: "John",
  age: 30,
};
person.age = 31; // Changing the age
console.log(person.age); // Outputs: 31

This flexibility is great for rapid development, but it also means you need to be careful about unintended changes to your objects. To create immutable objects in JavaScript, you can use methods like Object.freeze():

const person = Object.freeze({
  name: "John",
  age: 30,
});
person.age = 31; // This will not change the age
console.log(person.age); // Outputs: 30

The thing you should keep in mind...

As a developer, you might find yourself working with both Java and JavaScript in different contexts. Both have their own unique approaches to object manipulation, each with its own strengths and use cases.

In Java, objects are created using classes, which define properties and methods. Key concepts like encapsulation help protect an object's data by restricting access to its internal state, while inheritance allows classes to inherit properties and methods from other classes, promoting code reuse. Interfaces provide a way to define a contract that classes can implement, ensuring consistency across different implementations. Polymorphism enables objects of different classes to be treated as objects of a common superclass, allowing for flexible and dynamic code.

In JavaScript, objects are more flexible and can be created using object literals or constructors. JavaScript objects can hold multiple values as key-value pairs, making them versatile for various applications. The principles of encapsulation and inheritance also apply, although JavaScript uses prototypes for inheritance rather than classes. Polymorphism is achieved through duck typing, where the type of an object is determined by its behavior rather than its class.

Java's class-based inheritance and static typing provide a structured and predictable approach, while JavaScript's prototypal inheritance and dynamic typing offer flexibility and expressiveness.

Alright Let's start with basics then~

Here is a simple example of a footnote<Footnote id={1} text="Reference to the resource that provides information about a topic" /> that you might use in your blog posts. You can add cited text pointing to a source.<Footnote id={2} text="Short summary about the source" /> Also, you can add the link to the source you are reffering to and<Footnote id={3} text="This reference is accompained with a link pointing to the external source" link="https://example.com" /> you might have use in your blog posts.

Formatting

Heading Level 4

Heading Level 3

Heading Level 2

Heading Level 1

<u>This is how underlined text looks like</u>

This is how bold text looks like

This is how italic text looks like

This is how strikethrough looks like

Ordered List

1. Item 1
2. Item 2
3. Item 3

Unordered List

• Item 1
• Item 2
• Item 3

BlockQuote

"The best part of beauty is that which no picture can express"– Francis Bacon

<Image src="https://picsum.photos/900/600" alt="This is an auto-image example from picsum" />

Table

Tables are useful for presenting structured data in a clear, organized manner. Here's an example of a table I use to display various levels of experience, learning appetite, project sizes, and solutions:

<Table data={{ headers: [ "Experience Level", "Learning Appetite", "Project/Team Size", "Recommended Solution", ], rows: [ ["Beginner", "Low", "Small", "useState"], ["Beginner", "Medium", "Small to Medium", "useContext + useReducer"], ["Intermediate", "High", "Large", "Redux Toolkit"], ["Advanced", "High", "Medium to Large", "Jotai, Valtio"], ["Advanced", "High", "Large", "Recoil (or Relay for GraphQL)"], ], }} />

Pro-Con Cards

<ProConsComparison pros={[ "SSR boosts SEO and performance.", "SSG enables faster page loads.", "Built-in routing and API routes.", "Automatic code splitting.", "Strong TypeScript support.", ]} cons={[ "Complex setup for large apps.", "Frequent updates need maintenance.", "Steep learning curve for advanced features.", "SSR increases server load.", "Third-party tools dependency.", ]} />

Inline Code

HashMap<Integer, String>

SELECT Count(*) FROM users

float x=9.99

const func=() => {}

Code Block

import React from "react";
const Greeting = () => {
  React.useEffect(() => {
    console.log("Hello, world!");
  }, []);
  return <div>Check the console for a greeting!</div>;
};
export default Greeting;

Live Code

Live code allows interactive code snippets and their outputs directly in my webpage. Here's an interactive MDX editor that demonstrates the power of mixing markdown with React components:

<LiveCode mode="preview" fileNames={["MDXDemo.js", "MDXComponents.js"]} template="react" />

<Callout emoji="💡"> Callout: Alright this block is a callout block to highlight essential information that readers shouldn't overlook. Below is how the tweet card looks like. </Callout>

<Tweet id="1505668279678824448" />

<FootnoteList />