Forem: Brent Ochieng

Guys what do you think about the AI bubble in 2026.. Is there reason to be optimistic as a dev, data scientist etc? coz honestly people are just in denial about AI capabilities. I still hold onto the the thought that the future is gloomy. what do you think

Brent Ochieng — Tue, 30 Dec 2025 16:16:31 +0000

Understanding Big O Notation in Python: A Practical Guide

Brent Ochieng — Tue, 30 Dec 2025 15:29:18 +0000

Introduction

In the world of software development, writing code that works is only half the battle. Writing code that works efficiently is what separates good developers from great ones. This is where Big O notation becomes invaluable. Whether you're building a startup's MVP, optimizing a data pipeline, or preparing for technical interviews, understanding algorithmic complexity is a fundamental skill that will serve you throughout your career.

Big O notation provides a mathematical framework for analyzing how algorithms scale. It answers a critical question: "What happens to my code's performance when my data grows from 100 records to 100 million?" In this comprehensive guide, we'll explore Big O notation through the lens of Python, examining real-world scenarios where this knowledge makes the difference between an application that scales and one that collapses under load.

What is Big O Notation?

Big O notation is a mathematical notation that describes the limiting behavior of a function when the argument tends toward infinity. In computer science, we use it to classify algorithms according to how their run time or space requirements grow as the input size grows.
The "O" stands for "order of" and represents the worst-case scenario of an algorithm's performance. When we say an algorithm is O(n), we mean that in the worst case, the time it takes grows linearly with the input size.

Key Characteristics of Big O

1. Focus on Growth Rate, Not Exact Time
Big O doesn't tell you that an algorithm takes exactly 5 seconds or 10 milliseconds. Instead, it describes the shape of the growth curve. An O(n²) algorithm might be faster than an O(n) algorithm for small inputs, but as the input grows, the quadratic algorithm will eventually become slower.
2. Worst-Case Analysis
Big O typically represents the worst-case scenario. This conservative approach ensures we're prepared for the most challenging conditions our code might face.
3. Ignores Constants and Lower-Order Terms
An algorithm that takes 3n² + 5n + 100 operations is classified as O(n²) because, as n grows large, the n² term dominates. The constants (3, 5, 100) and the lower-order term (5n) become negligible.

The Big O Hierarchy

Understanding the hierarchy of Big O complexities helps you make informed decisions about algorithm selection:
O(1) < O(log n) < O(n) < O(n log n) < O(n²) < O(2ⁿ) < O(n!)
From best (most efficient) to worst (least efficient), here's what each means:

O(1) - Constant: Executes in the same time regardless of input size
O(log n) - Logarithmic: Time grows logarithmically with input
O(n) - Linear: Time grows proportionally with input
O(n log n) - Linearithmic: Common in efficient sorting algorithms
O(n²) - Quadratic: Time grows quadratically (nested operations)
O(2ⁿ) - Exponential: Time doubles with each addition to input
O(n!) - Factorial: Extremely slow, only practical for tiny inputs

Big O in Python: Common Operations

Python's built-in data structures have specific time complexities. Understanding these is crucial for writing efficient code.

Lists

# O(1) - Constant Time Operations
my_list = [1, 2, 3, 4, 5]
my_list.append(6)           # Adding to end
element = my_list[2]        # Index access
my_list[-1] = 10           # Index assignment

# O(n) - Linear Time Operations
my_list.insert(0, 0)        # Insert at beginning (shifts all elements)
my_list.remove(3)           # Remove by value (searches then shifts)
5 in my_list                # Membership check
my_list.pop(0)              # Pop from beginning

# O(k) where k is the slice size
subset = my_list[1:4]       # Slicing creates new list

# O(n) for iteration
for item in my_list:
    print(item)

Dictionaries

# O(1) Average Case - Hash Table Operations
my_dict = {'name': 'Alice', 'age': 30}
my_dict['email'] = 'alice@example.com'  # Assignment
age = my_dict['name']                     # Lookup
del my_dict['age']                        # Deletion
'name' in my_dict                         # Membership check

# O(n) - Must iterate all items
for key, value in my_dict.items():
    print(key, value)

Sets

# O(1) Average Case
my_set = {1, 2, 3, 4, 5}
my_set.add(6)               # Add element
my_set.remove(3)            # Remove element
5 in my_set                 # Membership check

# O(n) where n is the smaller set
set1 = {1, 2, 3}
set2 = {3, 4, 5}
intersection = set1 & set2  # Intersection

Real-World Examples

Let's explore scenarios where understanding Big O notation makes a tangible difference in application performance.
Example 1: Social Media Feed - Finding Duplicates
Imagine you're building a social media application where users can post updates. You need to detect duplicate posts to prevent spam.
Naive Approach - O(n²):

def find_duplicates_naive(posts):
    """
    Check every post against every other post.
    Time Complexity: O(n²)
    Space Complexity: O(1)
    """
    duplicates = []
    for i in range(len(posts)):
        for j in range(i + 1, len(posts)):
            if posts[i] == posts[j]:
                duplicates.append(posts[i])
    return duplicates

# With 1,000 posts: ~500,000 comparisons
# With 10,000 posts: ~50,000,000 comparisons
# With 100,000 posts: ~5,000,000,000 comparisons

Optimized Approach - O(n):

def find_duplicates_optimized(posts):
    """
    Use a set to track seen posts.
    Time Complexity: O(n)
    Space Complexity: O(n)
    """
    seen = set()
    duplicates = []
    for post in posts:
        if post in seen:
            duplicates.append(post)
        else:
            seen.add(post)
    return duplicates

# With 1,000 posts: 1,000 operations
# With 10,000 posts: 10,000 operations
# With 100,000 posts: 100,000 operations

Real-World Impact: For 100,000 posts, the naive approach performs 5 billion comparisons, while the optimized approach performs just 100,000 operations—a 50,000x improvement! This could be the difference between a response time of milliseconds versus several minutes.

Example 2: E-Commerce Search - Product Lookup
You're building an e-commerce platform with millions of products. Users need to find products quickly.
Linear Search - O(n):

def find_product_linear(products, target_id):
    """
    Search through products sequentially.
    Time Complexity: O(n)
    """
    for product in products:
        if product['id'] == target_id:
            return product
    return None

# Average case: check half the products
# With 1 million products: ~500,000 checks on average

Binary Search - O(log n):

def find_product_binary(products, target_id):
    """
    Binary search on sorted product list.
    Time Complexity: O(log n)
    Prerequisite: products must be sorted by id
    """
    left, right = 0, len(products) - 1

    while left <= right:
        mid = (left + right) // 2
        if products[mid]['id'] == target_id:
            return products[mid]
        elif products[mid]['id'] < target_id:
            left = mid + 1
        else:
            right = mid - 1

    return None

# With 1 million products: ~20 checks maximum
# With 1 billion products: ~30 checks maximum

Hash Table Lookup - O(1):

def create_product_index(products):
    """
    Create a hash table for instant lookups.
    Time Complexity: O(n) to build, O(1) to lookup
    Space Complexity: O(n)
    """
    return {product['id']: product for product in products}

def find_product_hash(product_index, target_id):
    """
    Look up product in hash table.
    Time Complexity: O(1)
    """
    return product_index.get(target_id)

# With any number of products: 1 check

Real-World Impact: For a database of 1 million products:

Linear search: ~500,000 operations on average
Binary search: ~20 operations maximum
Hash table: 1 operation

This explains why databases use indexes (essentially hash tables and B-trees) rather than scanning entire tables.

Example 3: Netflix Recommendations - Comparing User Preferences

You're building a recommendation system that needs to compare a user's watch history with millions of other users to find similar tastes.

Nested Loop Approach - O(n² × m):

def find_similar_users_naive(target_user, all_users):
    """
    Compare target user with every other user's entire history.
    Time Complexity: O(n² × m) where n is number of users, 
                     m is average watch history length
    """
    similarities = []
    target_history = set(target_user['watched'])

    for user in all_users:
        if user['id'] == target_user['id']:
            continue

        user_history = user['watched']
        common_shows = 0

        # O(m²) comparison for each pair
        for show1 in target_history:
            for show2 in user_history:
                if show1 == show2:
                    common_shows += 1

        similarities.append({
            'user_id': user['id'],
            'common_shows': common_shows
        })

    return sorted(similarities, key=lambda x: x['common_shows'], reverse=True)

# With 10,000 users and 100 shows each: 10 billion comparisons

Set Intersection Approach - O(n × m):

def find_similar_users_optimized(target_user, all_users):
    """
    Use set intersection for efficient comparison.
    Time Complexity: O(n × m) where n is number of users,
                     m is average watch history length
    """
    similarities = []
    target_history = set(target_user['watched'])

    for user in all_users:
        if user['id'] == target_user['id']:
            continue

        user_history = set(user['watched'])
        # O(m) set intersection
        common_shows = len(target_history & user_history)

        similarities.append({
            'user_id': user['id'],
            'common_shows': common_shows
        })

    return sorted(similarities, key=lambda x: x['common_shows'], reverse=True)

# With 10,000 users and 100 shows each: ~1 million operations

Real-World Impact: The optimized version is 10,000x faster. This is why recommendation systems use sophisticated algorithms and data structures—the naive approach becomes computationally infeasible at scale.

Example 4: Data Processing Pipeline - Log Analysis
You're analyzing server logs to identify suspicious activity patterns.

Reading Entire File - O(n):

def analyze_logs_in_memory(log_file):
    """
    Load entire log file into memory.
    Time Complexity: O(n)
    Space Complexity: O(n) - stores entire file in memory
    """
    with open(log_file, 'r') as f:
        logs = f.readlines()  # Loads everything into memory

    suspicious_ips = set()
    ip_counts = {}

    for log in logs:
        ip = extract_ip(log)
        ip_counts[ip] = ip_counts.get(ip, 0) + 1

        if ip_counts[ip] > 1000:  # Suspicious threshold
            suspicious_ips.add(ip)

    return suspicious_ips

# Problem: A 10GB log file requires 10GB of RAM

Streaming Approach - O(n) with O(k) Space:

def analyze_logs_streaming(log_file):
    """
    Process logs line by line without loading everything.
    Time Complexity: O(n)
    Space Complexity: O(k) where k is number of unique IPs
    """
    suspicious_ips = set()
    ip_counts = {}

    with open(log_file, 'r') as f:
        for line in f:  # Generator - one line at a time
            ip = extract_ip(line)
            ip_counts[ip] = ip_counts.get(ip, 0) + 1

            if ip_counts[ip] > 1000:
                suspicious_ips.add(ip)

    return suspicious_ips

# A 10GB log file needs only enough RAM for unique IP tracking
# Typically a few MB instead of 10GB

Real-World Impact: The streaming approach allows you to process logs that are larger than your available RAM, making it possible to analyze terabytes of data on modest hardware.

When Big O Doesn't Tell the Whole Story

While Big O notation is incredibly useful, it has limitations:

1. Constants Matter for Small Inputs

# Algorithm A: O(n) with constant factor of 1000
def algorithm_a(data):
    result = 0
    for _ in range(1000):
        for item in data:
            result += item
    return result

# Algorithm B: O(n²) with constant factor of 1
def algorithm_b(data):
    result = 0
    for i in data:
        for j in data:
            result += i * j
    return result

# For n < 32, algorithm_b is actually faster!

2. Average Case vs. Worst Case

Python's list.sort() uses Timsort, which is O(n log n) in the worst case but often performs closer to O(n) on partially sorted data—a common real-world scenario.

3. Space-Time Tradeoffs

Sometimes you can trade memory for speed or vice versa:

# Time-optimized: O(1) lookup, O(n) space
def fibonacci_memoized(n, memo={}):
    if n in memo:
        return memo[n]
    if n <= 1:
        return n
    memo[n] = fibonacci_memoized(n-1, memo) + fibonacci_memoized(n-2, memo)
    return memo[n]

# Space-optimized: O(n) time, O(1) space
def fibonacci_iterative(n):
    if n <= 1:
        return n
    prev, curr = 0, 1
    for _ in range(2, n + 1):
        prev, curr = curr, prev + curr
    return curr

Practical Guidelines for Python Developers

1. Choose the Right Data Structure

Need fast lookups? Use dict or set (O(1) average) instead of list (O(n))
Need ordered data with fast insertions at both ends? Use collections.deque instead of list
Need to maintain sorted data? Use bisect module for O(log n) insertions

2. Avoid Nested Loops When Possible

# Bad: O(n²)
for item in list1:
    if item in list2:  # O(n) lookup
        print(item)

# Good: O(n)
set2 = set(list2)  # O(n) to create set
for item in list1:  # O(n) iteration
    if item in set2:  # O(1) lookup
        print(item)

3. Use Built-in Functions and Libraries

Python's built-in functions are implemented in C and highly optimized:

# Slower
max_value = float('-inf')
for value in data:
    if value > max_value:
        max_value = value

# Faster
max_value = max(data)

4. Profile Before Optimizing

Use Python's profiling tools to identify actual bottlenecks:

import cProfile
import pstats

def my_function():
    # Your code here
    pass

profiler = cProfile.Profile()
profiler.enable()
my_function()
profiler.disable()

stats = pstats.Stats(profiler)
stats.sort_stats('cumulative')
stats.print_stats(10)

Conclusion: The Relevance of Big O in Modern Development

Understanding Big O notation is not about memorizing complexities—it's about developing an intuition for how code scales. In today's world where applications routinely handle millions of users and petabytes of data, this intuition is invaluable.

Consider these real-world scenarios:

Startups: Your MVP works with 100 users. Will it survive 10,000? Understanding Big O helps you avoid architectural decisions that require complete rewrites.
Data Science: Processing a sample dataset takes 10 seconds. Your production dataset is 1000x larger. Big O tells you if you need 10,000 seconds (2.7 hours) or 10,000,000 seconds (115 days).
API Development: Your endpoint responds in 50ms. What happens when traffic doubles? Triples? Understanding algorithmic complexity helps you predict and plan.

Understanding *args and **kwargs in Python, Explained in Plain English

Brent Ochieng — Fri, 05 Dec 2025 08:35:38 +0000

If you’ve ever written a Python function and wondered how to make it accept any number of inputs, you’re not alone. This is where two strangely named but incredibly powerful tools come in:

*args
**kwargs
Think of them as flexible containers that let your functions handle unpredictable or unlimited inputs — without breaking.

In this article, we’ll break them down using real-life examples, simple explanations, and copy-paste code.

1. What Is *args?

*args lets your function accept any number of positional arguments, even zero.

Think of it like this:

Imagine you’re at a supermarket checkout.
Some customers bring 2 items, some bring 20.
Instead of creating a different till for each customer, the cashier accepts any number of items.

***args **does exactly that for functions.

Example: Adding Any Number of Numbers

def add_numbers(*args):
    return sum(args)

print(add_numbers(2, 3))           # 5
print(add_numbers(10, 20, 30))     # 60
print(add_numbers())               # 0

Whatever you pass into the function is packed into a tuple called args

2. What Is **kwargs?

****kwargs **lets your function accept any number of named arguments — things passed as key=value.

Real-life comparison:

Think of filling out a hotel registration form.

Every guest gives different details:

Name only
Name + email
Name + phone + nationality
The hotel needs one form flexible enough to accept anything.

***kwargs* works exactly like that.

Example: Guest Registration

def register_guest(**kwargs):
    return kwargs

print(register_guest(name="Brent", room=305))
# {'name': 'Brent', 'room': 305}

print(register_guest(name="Alice", email="alice@email.com", nights=3))
# {'name': 'Alice', 'email': 'alice@email.com', 'nights': 3}

Everything goes into a dictionary called kwargs.

OUTPUT:

Toppings: ('cheese', 'beef')
Details: {'size': 'large', 'crust': 'thin'}

3.Why *args and **kwargs Matter in Real Projects

Here’s why developers (and data analysts) rely on them:

✔ They make functions flexible
✔ They help you build reusable code
✔ They simplify APIs and utilities
✔ They clean up long function signatures
✔ They allow you to pass through unknown parameters

In short:
They help your code adapt instead of break.

One-sentence summary:

*args is a bag of unnamed values, and **kwargs is a dictionary of named values.

Final Thoughts

**args* and ***kwargs* are not advanced concepts but rather practical tools that make your functions smarter and more flexible.
Mastering them early will save you hours of debugging in the future.

Understanding Common Table Expressions (CTEs) in SQL — And Why They Matter in Data Analysis

Brent Ochieng — Fri, 21 Nov 2025 09:15:43 +0000

If you’ve spent enough time writing SQL queries, you’ve probably found yourself staring at a long, repetitive, hard-to-read block of code. Maybe you copied the same subquery three times. Maybe you nested queries inside queries until your brain begged for mercy.

This is where Common Table Expressions, better known as CTEs, come in. They offer a simple way to write cleaner, more readable, and more maintainable SQL. And for data analysts, learning CTEs is one of those skills that instantly upgrades the quality of your work.

What Exactly Is a CTE?

A Common Table Expression (CTE) is a temporary, named result set that exists only for the duration of a single SQL statement.

Think of it like creating a mini-table, just for a moment, to help you break down a query into logical steps.

It usually starts with the keyword:

WITH

A simple example:

WITH top_customers AS (
    SELECT customer_id, SUM(amount) AS total_spent
    FROM payments
    GROUP BY customer_id
)
SELECT *
FROM top_customers
WHERE total_spent > 1000;

Here, top_customers is not a permanent table. It’s just a temporary result that makes the final query easier to manage.

Why Use a CTE?

CTEs shine in three major areas:

1. Readability

A long query becomes easier to understand when broken down into smaller steps.

2. Reusability

You can reference the CTE multiple times within the same query without repeating code.

3. Maintainability

If you need to modify something, you change it once inside the CTE instead of updating multiple subqueries.

For analysts who read and maintain SQL regularly, these benefits are huge.

How CTEs Are Used

You can use a CTE for almost anything, but here are the most common use cases:

1. Simplifying Complex Queries

Sometimes, your logic requires several transformations. With CTEs, you can approach SQL like a workflow: Step 1, Step 2, Step 3.

WITH cleaned_data AS (
    SELECT 
        order_id,
        customer_id,
        amount,
        DATE(order_date) AS order_date
    FROM orders
),
aggregated AS (
    SELECT 
        customer_id, 
        SUM(amount) AS total_spent
    FROM cleaned_data
    GROUP BY customer_id
)
SELECT *
FROM aggregated
ORDER BY total_spent DESC;

Each section becomes easier to explain and debug.

2. Avoiding Repeated Subqueries

Without a CTE, you might write the same subquery multiple times.

WITH avg_sales AS (
    SELECT AVG(amount) AS avg_amount
    FROM sales
)
SELECT *
FROM sales
WHERE amount > (SELECT avg_amount FROM avg_sales);

Instead of running the same calculation repeatedly, the CTE stores it once.

3. Creating Recursive Queries (Hierarchies)

This is one of the most powerful SQL features: recursive CTEs.

They're used for:

Employee-management hierarchies

Folder/subfolder structures

Generating sequences or running totals

Example:

WITH RECURSIVE hierarchy AS (
    SELECT 
        employee_id,
        manager_id,
        1 AS level
    FROM employees
    WHERE manager_id IS NULL

    UNION ALL

    SELECT 
        e.employee_id,
        e.manager_id,
        h.level + 1
    FROM employees e
    JOIN hierarchy h ON e.manager_id = h.employee_id
)
SELECT *
FROM hierarchy
ORDER BY level;

This walks through an entire organizational structure using recursion.

4. Preparing Data for Visualization or Reporting

Most dashboards and reports need data that has been:

Cleaned
Aggregated
Filtered
Joined

CTEs help create step-by-step logic, which makes transformations clear and transparent.

When Should You Use a CTE?

CTEs are ideal when:

Your SQL query is becoming long or unreadable
You need to reuse the same result in multiple places
You want to logically break the query into stages
You’re calculating something step-by-step
You need recursion
You want to make your SQL explainable to teammates, managers, or future you

They may not be the best choice when performance is extremely critical, since some databases materialize CTEs and others don’t. But for most daily analytical tasks, CTEs are perfectly efficient.

Why CTEs Are Important in Data Analysis

In data analysis, clarity is everything. It’s not enough to get the right answer—your SQL needs to be readable, reproducible, and trustworthy.

CTEs help analysts:

✔ Build cleaner data pipelines
✔ Avoid errors from duplicated logic
✔ Explain logic clearly to stakeholders
✔ Work iteratively and transform data step by step
✔ Write analysis queries that can easily be revisited later

SQL can be intimidating when queries become too complex. CTEs allow you to think in layers, similar to dataframes in Python or steps in Power BI.

This makes your analysis process more structured and your results more reliable.

Final Thoughts

Learning CTEs is one of the fastest ways to become a better SQL writer. They make your queries more organized, more readable, and far easier to debug.

Whether you’re analyzing sales performance, building dashboards, or preparing datasets for machine learning, CTEs give you the clarity and structure you need to work efficiently.

If you’re moving into professional data work, mastering CTEs isn’t optional—it’s essential.

10 Reasons Why Python is Still the Best Programming Language in 2025 (and Beyond)

Brent Ochieng — Tue, 30 Sep 2025 06:59:53 +0000

Python has been around for decades, yet in 2025 it still wears the crown as the most beloved programming language. Whether you’re a beginner in Nairobi learning to code for the first time or a senior engineer working on advanced AI models in Tokyo, Python continues to be the language everyone talks about. Let’s dive into ten clear reasons why Python remains the GOAT programming language today and why it’s set to dominate the future.

1. Python powers Artificial Intelligence and Machine Learning
AI is everywhere right now, and Python is the backbone. From training deep learning models to building chatbots and recommendation systems, Python frameworks like TensorFlow, PyTorch, and Scikit-learn are leading the charge. In Africa, where AI is being applied to solve problems in agriculture, fintech, and healthcare, Python is the language behind these innovations.

2. Python is the language of Data Science
Data is the new oil, and Python is the refinery. With tools like Pandas, NumPy, and Matplotlib, data analysts can clean, process, and visualize datasets effortlessly. For startups in Africa that rely on insights to make smarter decisions, Python provides the foundation.

3. Python is beginner-friendly
Unlike many programming languages that feel intimidating, Python reads almost like English. Its simplicity means a university student in Kenya can pick it up fast, yet still use it to build powerful systems. That gentle learning curve is one of the reasons why it continues to attract new developers every year.

4. Python has a massive global community
When you get stuck, chances are someone else has already solved your problem. Python has one of the largest developer communities in the world, with countless tutorials, forums, and conferences like PyCon. This community support ensures that the language stays alive and keeps improving.

5. Python works across multiple industries
Python is not locked to one domain. It’s in finance, education, gaming, manufacturing, medicine, and agriculture. In Kenya, fintech companies are using it to build mobile banking apps, while agritech startups use it to analyze farm data. This cross-industry adoption makes Python extremely versatile.

6. Python still matters in Web Development
Even though JavaScript dominates front-end development, Python quietly powers the back end. Frameworks like Django and Flask make it easy to build scalable and secure applications. Many African startups use Django to launch their first products because it allows them to move quickly.

7. Python integrates with almost everything
Python is often called a “glue language” because it works well with other technologies. You can combine it with C, C++, Java, SQL, and even IoT hardware. For developers working on complex systems that require multiple technologies, Python is the bridge that brings everything together.

8. Python makes automation effortless
If you’ve ever wanted to save time by automating boring tasks, Python is your best friend. From web scraping and report generation to managing servers and DevOps pipelines, Python scripts cut down hours of manual work into minutes. That’s productivity at its best.

source: Bacancy

9. Python dominates in education and research
Most universities and coding bootcamps around the world, including here in Africa, are teaching Python as the first programming language. It’s simple enough for beginners, yet powerful enough for advanced research in AI, blockchain, and quantum computing. This ensures that the next generation of developers already speak Python fluently.

10. Python’s ecosystem is future-proof
The ecosystem keeps growing every year. Whatever problem you’re trying to solve, such as cloud computing, blockchain, natural language processing, or even game development, there’s probably a Python library for it. With big tech companies like Google, Microsoft, and Meta backing it, Python is here to stay.

source: Tristan Salles

Conclusion
Python in 2025 is more than just a programming language. It’s a tool for solving real-world problems, a gateway for beginners to enter tech, and a reliable partner for professionals working on cutting-edge projects. For developers across Africa and beyond, Python represents opportunity, simplicity, and limitless potential. That’s why it’s still the GOAT and likely will be for years to come.

Will Humans Ever Live to 100? A Data-Driven Journey Through Life Expectancy

Brent Ochieng — Tue, 16 Sep 2025 09:48:23 +0000

When I began exploring global life expectancy data from 1960 to 2023, I wasn’t just curious about numbers; I wanted to answer a deeper question:
Are we moving toward a future where living to 100 becomes the norm?

As a Kenyan data analyst, I’ve seen firsthand how conversations about health often focus on the here and now, outbreaks, access to hospitals, and the affordability of treatment. But when I pulled 63 years of data into a Jupyter Notebook and began visualizing the trends, something fascinating emerged.

What the Data Reveals

Globally: Life expectancy has risen by more than 15 years since 1960. That’s a whole extra childhood added to the average life.

Europe: Life expectancy jumped from 68 years (1960) to over 80 today — and Prophet forecasts suggest 82–84 years by 2049.

America: The steady climb was suddenly interrupted in 2020–21, a powerful reminder of how global crises can undo years of progress almost overnight.

East Africa: My favorite part of this project is seeing that despite decades of challenges, our region is catching up, with steady gains year after year.

When I plotted East Africa’s numbers, it felt personal. It told a story of resilience — of how healthcare campaigns, better nutrition, and expanded access to medicine have changed what it means to grow old here.

Modern Medicine’s Silent Revolution
Modern medicine has completely redefined what it means to age. Vaccinations, antibiotics, improved maternal care, and chronic disease management have turned once-fatal illnesses into treatable conditions.

When we talk about life expectancy increasing, we’re really talking about millions of lives saved. For instance, children living past their fifth birthday, mothers surviving childbirth, and elders living long enough to meet their great-grandchildren.

But the data also reminds us: progress is not guaranteed. The pandemic dip in 2020 is a warning that gains can be fragile.

Will We Get to 100?
The projections show we are inching closer, but slowly. If Europe reaches 84 years by 2049, that’s still 16 years away from 100. To cross that line, we will need more than just medical innovation. We’ll need:

Preventive healthcare that keeps people healthier for longer.

Equitable access to treatments across countries and income levels.

Social systems that support ageing populations without leaving anyone behind.

What This Project Taught Me
As analysts, we often focus on the code, the models, the plots. But data like this reminds us that behind every line on a chart is a story about humanity.

For me, this was more than an analysis. It was a chance to reflect on how far we’ve come, and what it will take to ensure that a child born in Nairobi today might one day celebrate their 100th birthday not as an exception, but as part of the new normal.

You can explore the full analysis, code, and forecasts here:
https://github.com/BrentOchieng/Global-Life-Expectancy-Trend-1960-2049