DEV Community: Fredrick Ogutu

A Better Way to build

Fredrick Ogutu — Fri, 14 Nov 2025 10:40:41 +0000

There was a stage in my development journey when I often dove headfirst into projects without much planning or structure. I’d start coding right away no sketches, no layout drafts, no clear idea of how the final user interface would look.

I’d usually get a few components built, only to realize later that my design didn’t hold up across different devices. Designing for desktop screens felt familiar and easy, but it often left me stuck in long, tedious sprints of refactoring just to make the project responsive.

That pattern taught me a valuable lesson: good design starts with intentionality.

Recently, I’ve made a conscious shift toward a mobile-first design and development approach. Building from smaller screens upward forces me to prioritize what really matters in the user experience. It has made my process more structured, my designs cleaner, and my projects far more enjoyable.

Pairing this approach with Tailwind CSS utility classes has also been a game-changer development feels faster, smoother, and surprisingly fun.

Over the past week, I challenged myself to build a fully responsive static website from scratch. It was both a test of my new workflow and a chance to see how quickly I could move from idea to polished result.

Here is the link to the full project

Beyond the project itself, I found the experience deeply rewarding. It sparked a curiosity to go further specifically, to build a backend for the site and explore how to enrich the application with AI agents, MCP, and RAG to get the most out of the UI.

Takeaways

Responsive Design isn’t just about resizing elements it’s about adapting experiences.
Mobile-First Development helps maintain focus, clarity, and scalability from the start.

This shift toward intentional design has not only improved my workflow but also reignited my passion for learning and creating with purpose.

⚡ Streaming and Caching for a Better UX in Next.js

Fredrick Ogutu — Fri, 31 Oct 2025 10:44:07 +0000

When building data-driven applications in Next.js, one of the most common bottlenecks you’ll face is slow data fetching. Whether you’re pulling data from a remote API or querying your own backend, a delay in just one request can hold back the entire page from rendering.

As the saying goes,

“Your application is only as fast as its slowest data fetch.”

This is especially true for dynamically rendered pages.

In one of my recent projects, I noticed a significant delay when fetching blog posts from the Dev.to API. While the data itself wasn’t heavy, the delay between fetching and rendering made the page feel sluggish. This experience led me to explore two powerful techniques built into Next.js streaming and caching to make my app feel fast, responsive, and smooth.

🌊 Streaming

Streaming allows you to send parts of a page to the client as soon as they’re ready, instead of waiting for all data to load. This means users can start interacting with sections of the UI immediately, even while slower parts are still rendering in the background.

It’s like serving snacks while the main course is still cooking, your users can start interacting with something right away, reducing perceived load time.

Next.js supports streaming at two levels:

Page-level streaming using loading.tsx files.
Component-level streaming using React’s <Suspense>.

Streaming a Whole Page

At the page level, you can use a loading.tsx file to display fallback UI while your data is being fetched. This helps avoid the “white screen” problem, where nothing is visible to users while they wait.

// app/blog/loading.tsx
import React from "react";

export default function Loading() {
  return (
    <main className="min-h-screen px-4 py-6">
      {/* Header skeleton */}
      <header className="mx-auto max-w-5xl mb-8">
        <div className="flex items-center gap-4">
          {/* avatar */}
          <div
            className="h-10 w-10 rounded-full bg-md-background animate-pulse"
            aria-hidden
          />
          {/* site title placeholder */}
          <div className="flex-1">
            <div className="h-6 w-64 rounded-md bg-md-background animate-pulse" />
            <div className="mt-3 flex gap-3">
              {/* tag placeholders */}
              <div className="h-6 w-20 rounded-full bg-md-background animate-pulse" />
              <div className="h-6 w-24 rounded-full bg-md-background animate-pulse" />
              <div className="h-6 w-16 rounded-full bg-md-background animate-pulse" />
            </div>
          </div>
        </div>
      </header>

      {/* Cards grid skeleton */}
      <section className="mx-auto max-w-5xl">
        <div className="grid grid-cols-1 md:grid-cols-2 gap-8">
          {Array.from({ length: 2 }).map((_, i) => (
            <article
              key={i}
              className="rounded-2xl bg-white shadow-[0_10px_35px_rgba(99,102,241,0.12)] p-6"
              aria-hidden
            >
              {/* image */}
              <div className="h-40 md:h-48 w-full rounded-lg bg-md-background animate-pulse mb-4" />

              {/* title + date row */}
              <div className="mb-3">
                <div className="h-5 w-3/4 rounded-md bg-md-background animate-pulse mb-2" />
                <div className="h-3 w-1/4 rounded-md bg-md-background animate-pulse" />
              </div>

              {/* excerpt */}
              <div className="space-y-2 mb-4">
                <div className="h-3 w-full rounded-md bg-md-background animate-pulse" />
                <div className="h-3 w-11/12 rounded-md bg-md-background animate-pulse" />
                <div className="h-3 w-8/12 rounded-md bg-md-background animate-pulse" />
              </div>

              {/* tags */}
              <div className="flex flex-wrap gap-2 mb-6">
                <div className="h-8 w-20 rounded-full bg-md-background animate-pulse" />
                <div className="h-8 w-24 rounded-full bg-md-background animate-pulse" />
                <div className="h-8 w-16 rounded-full bg-md-background animate-pulse" />
              </div>

              {/* read more button */}
              <div className="w-36 h-10 rounded-full bg-md-background animate-pulse" />
            </article>
          ))}
        </div>
      </section>
    </main>
  );

With this file in place, Next.js automatically serves it as a temporary placeholder whenever the /blog route is loading. Users can still navigate around without waiting for the full page to render.

This design mimics my actual blog cards image at the top, followed by the title, date, tags, and a “Read more” button.
Even though the data hasn’t loaded yet, users can clearly see what to expect.

Streaming at the Component Level

While page-level streaming is useful, sometimes you want even finer control. That’s where React’s suspense component comes in.

It lets you defer rendering specific components until their data is ready, ideal for dynamic sections of your app.

Here’s how I wrapped my Blogs component:

// app/blog/page.tsx
import { Suspense } from 'react';
import Blogs from '../ui/blog/Blogs';
import { BlogSkeleton } from '../ui/blog/skeletons';

export default async function Blog() {
  return (
    <div className="relative pt-2 px-2">
      <Suspense fallback={<BlogSkeleton />}>
        <Blogs />
      </Suspense>
    </div>
  );
}


// app/ui/blog/skeletons.tsx
export function BlogSkeleton() {
  return (
    <section className="h-full w-full bg-inherit flex flex-col justify-center items-center gap-6 md:flex-row md:gap-12">
      {[...Array(3)].map((_, i) => (
        <div key={i} className="flex flex-col items-center w-11/12 px-2 py-3">
          <div className="mt-3 w-11/12 h-2/6 bg-md-background"></div>
          <div className="mt-3 w-full bg-md-background"></div>
          <div className="bg-md-background"></div>
          <div className="w-4/6 mx-auto"></div>
        </div>
      ))}
    </section>
  );
}

With this setup, the static parts of the page render immediately, while the <Blogs /> component streams in once its data has finished loading. If the fetch takes longer, users see the BlogSkeleton instead of a blank space a small detail that greatly improves perceived responsiveness.

Caching

Streaming improves how data loads. Caching improves how often data needs to load.

Caching stores the results of expensive operations (like API requests) so that subsequent requests for the same data are served faster. This is especially powerful in server components, where you can use React’s built-in cache() function.

Here’s how I applied caching to my blog data fetch:

// app/lib/fetchBlogs.ts
import { cache } from "react";
import { Blog } from "../types/index";

export const fetchBlogs = cache(async function fetchBlogs(): Promise<{ blogs: Blog[]; count: number }> {
  try {
    const res = await fetch("https://dev.to/api/articles?username=fiveace_merill");
    const blogs: Blog[] = await res.json();

    const simplifiedBlogs = blogs.map(({ id, title, description, published_at, url, cover_image, tag_list }) => ({
      id,
      title,
      description,
      published_at,
      url,
      cover_image,
      tag_list,
    }));

    const count = simplifiedBlogs.length;
    console.log("Articles fetched successfully");
    console.log(`Total blogs: ${count}`);

    return { blogs: simplifiedBlogs, count };
  } catch (error) {
    console.error(`Error fetching articles: ${error}`);
    return { blogs: [], count: 0 };
  }
});

By wrapping the fetch logic inside cache(), repeated requests for the same data are served instantly from memory rather than refetching from the API. This significantly reduces latency and helps avoid hitting external API rate limits.

Enabling Cache Components

Next.js also lets you enable caching at the component level using Cache Components a newer optimization that preserves state during navigation.

To enable it, update your Next.js config:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

Once enabled, Next.js uses React’s Activity mode to keep component state intact during client-side navigation.

This means:

Form inputs and expanded sections remain preserved when moving between routes.
Navigation feels faster and more fluid.
Effects are cleaned up and restored only when needed.

In short, caching complements streaming by making transitions and repeated renders smoother without unnecessary data fetching.

To cache a component add use chache to any server component to make it cached and included in the prerendered shell or mark utility functions as use cache and call them from within the server component.

export async function fetchProjects() {
  'use cache'
  try {
    const data = await sql`SELECT * FROM projects LIMIT 3`;
    console.log('Data fetch completed after seconds.');
    return data;
  } catch (error) {
    console.error('Database Error:', error);
    throw new Error('Failed to fetch projects data.')
  }
}

You can not use runtime APIs like cookies and headers from inside a cached component.

Conclusion

Optimizing user experience isn’t just about making things faster it’s about making them feel faster.

By combining Streaming and Caching in Next.js, I was able to transform a slow, blocking data fetch into an experience where content appears progressively, interactions remain fluid, and returning users benefit from cached data.

It’s these small technical adjustments that often have the biggest impact on how users perceive your app. Next time you’re faced with sluggish data fetching, consider streaming your components and caching your results your users will thank you.

Reflections on Learning, Mentorship, and Growth

Fredrick Ogutu — Mon, 13 Oct 2025 11:19:57 +0000

Learning has never been a straight path for me; it’s been shaped by curiosity, the people I’ve met, and the fears I’ve learned (and still learn) to face. From discovering computers for the first time to watching others pursue mastery before me, this is my reflection on how discomfort, mentorship, and persistence all play their part in growth.

Early Encounters & Missed Turns

Growing up, I was lucky enough to be exposed to computers a Windows Vista, to be exact. My dad introduced me to Microsoft Word, and that small exposure felt magical. I spent hours poking at menus, typing, and undoing mistakes. It didn’t feel like a career path yet just a toy, a curiosity.

When high school arrived, the notion of computer studies was there, but I opted out. Part of me excuses it as fate; part of me knows I just didn’t believe I belonged. My brother once remarked that computer classes seemed tedious, not “worth it.” At the time, I accepted that remark without question. I also watched classmates who cared deeply about tech still drift into other careers; teachers, doctors, as if the spark had been dimmed somewhere along the way.

But one friend stood apart. He was an early adopter, experimenting with code, pushing boundaries even when the rest of us were content with textbooks.

The Gap Year & What I Learned from Him

We spent a lot of that gap year before college together. By then, he was already part of the Andela Community, tinkering with side projects, reading documentation, and engaging with dev circles. I watched him jump into frameworks and tools I’d barely heard of.

Watching him in his element was something else: flying through terminal windows, dropping terms like Docker, Kubernetes, and Kotlin like they were a second language. He didn’t just know computers; he understood their potential, their language, their logic.

But more than that, he showed me a path of devouring uncertainty rather than avoiding it. He seemed comfortable failing fast, exploring boldly, admitting “I don’t know,” then going to figure it out. He made learning look alive.

That contrast between those who drifted away and him who leaned in quietly rewired how I saw possibility. He didn’t hand me answers. He embodied a posture. And that posture nudged me: I wanted fluency too, not just surface comfort.

Mentorship, Noise, and the Challenge of Learning

If inspiration is a spark, mentorship is the fuel that keeps it burning. In tech, where everything changes, stacks evolve, and “best practices” expire, having someone with just a bit more visibility helps you cut through the noise.

Looking back, I realize that learning often begins as a deep, intentional desire to be better, but it’s also shaped by the people around us. I realize now that my first mentor wasn’t official; there were no check-ins, but he was my friend. Watching him work taught me more than I could have learned from any syllabus. I observed his habits, his curiosity, and his willingness to fail fast and recover even faster. Without ever intending to, he modeled what active learning looked like.

Over time, I realized mentorship isn’t always about direct instruction. Sometimes it’s quiet, the kind that happens through observation. It’s not just advice; it’s example. It’s the implicit permission to be curious, to fail, to explore tangents, and to ask “dumb” questions without shame. That form of mentorship shaped me long before I recognized it for what it was.

That realization became critical later, when anxiety and self-doubt crept in. Especially in software, the fear of not knowing enough, of falling behind, or of failing publicly it’s ever-present.

Then I came across an article that reframed my thinking: “Unnecessary Anxiety in Software Development” by SimpleThread. It argued that anxiety, rather than being an obstacle, can serve as a signal.

The author used a vivid metaphor: imagine walking across a narrow plank between two buildings. The task is the same as walking on flat ground, but the stakes or perceived danger make it terrifying. In development, we often work without safety nets: no tests, no staging, no guardrails. Naturally, anxiety rises because the environment amplifies the risk.

One insight stood out:

When working on anxiety, do the thing that feels bad and avoid the thing that feels good.

In other words, approach discomfort instead of retreating from it.

That line stayed with me because it echoed something I’d already seen in my friend’s behavior and something I still try, often imperfectly, to practice myself.

In hindsight, what I called friendship was also mentorship in disguise, a reminder that guidance doesn’t always arrive with a title. Sometimes it’s simply someone showing you, by example, that the uncomfortable path forward is still worth taking.

One insight stood out:

When working on anxiety, do the thing that feels bad and avoid the thing that feels good.

In other words, approach discomfort instead of retreating from it.

That line stayed with me because it echoed something I’d already seen in my friend’s behavior and something I still try, often imperfectly, to practice myself.

The Ongoing Conflict: Learning vs. Bills

Here’s a truth I don’t pretend to have solved: I still oscillate between wanting to learn and needing to earn. There are days when I’m turned toward a new framework, excited to build something just for fun. And there are days when I worry if those hours will ever pay the rent.

Learning feels risky. Investing time in something may or may not yield fruit. Meanwhile, bills and responsibilities demand immediate returns. That tension is real. But I try to remember: learning with intention, even if it’s slow, compounds. I don’t have to master everything, but I can commit to leaning in where curiosity and need intersect.

I also lean on small guardrails: naming what I want to learn, framing small experiments, pairing with others, and asking naive questions. These act like my safety nets. They reduce my internal cost of failure.

From Fear to Signal, From Anxiety to Action

The article argues anxiety isn’t always a foe; it can be a signal. Instead of ignoring it, I try to listen: What’s behind this worry? What do I fear missing? What’s the next small step I can take that moves me forward, not paralyzed?

This flip from avoidance to approach is hard. It doesn’t just require willpower; it requires strategy. Often, I remind myself: the blinders of fear are opaque. They hide solutions that are right in front of you.

Sometimes the move is structural: add tests, staging, peer review, guardrails in your workflow so that the stakes feel safer and you can experiment. Sometimes it’s personal: reach out to a mentor, share where you’re stuck, break a problem down, try something new, even if you expect failure.

Anxiety doesn’t disappear. But it becomes less of a tyrant, more of a map.

Final Thoughts & a Question for You

I don’t pretend to have mastered my path. I’m still juggling curiosity, fear, bills, and ambition. But I see how small, intentional choices seeking connection, leaning into discomfort, and naming my fears make the journey more meaningful.

Every time I ask myself whether I’ll pick the secure path or the learning path, I try to remember: growth happens where stability and risk overlap not at extremes, but in the tension.

How do you approach learning in the midst of your work, and how do you balance it with what life expects of you?

Inspired by Unnecessary Anxiety in Software Development by SimpleThread.

From CSV to SQL: Importing CSV Real World Data into PostgreSQL.

Fredrick Ogutu — Sat, 03 May 2025 15:24:09 +0000

Like many other data projects, I found myself staring at a Kaggle dataset, which in this case was centered around student depression. However, this time equipped with a new skill, SQL, I couldn't help but wonder what insights I could obtain about the complex and sensitive topic of mental health. Out of curiosity, I set out to go from CSV to SQL in PostgreSQL.
This article documents the steps I took to load the dataset into a PostgreSQL database: cleaning the data, designing a table schema, and loading the data using PostgreSQL's built-in tools.

Inspecting and Cleaning the dataset

The dataset seemed relatively intuitive to use. The cleaning process involved the following steps.

Renaming the table and column names using lowercase snakecase.
Removing special character "?" from the Financial Stress column.
Validation of data types, e.g, ascertaining that numeric columns are numeric.

Defining a PostgreSQL Schema

With the dataset cleaned, I found the schema below to best represent the data in the file.

CREATE TABLE student_depression (
  id SERIAL PRIMARY KEY,
  gender TEXT,
  age INT,
  city TEXT,
  profession TEXT,
  academic_pressure NUMERIC,
  work_pressure NUMERIC,
  cgpa NUMERIC,
  study_satisfaction NUMERIC,
  job_satisfaction NUMERIC,
  sleep_duration TEXT,
  dietary_habits TEXT,
  degree TEXT,
  suicidal_thoughts BOOLEAN,
  work_study_hours NUMERIC,
  financial_stress NUMERIC,
  family_history BOOLEAN,
  depression BOOLEAN
);

Importing the CSV file into PostgreSQL

Depending on your tools and environment, there are several options for importing data, from using a graphical tool like pgAdmin to a direct SQL query.
For my case, I was using a locally hosted PostgreSQL, and found the command line to be convenient.

psql -U your_username -d student_depression -c "\COPY student_depression FROM 'path/to/student_depression_dataset.csv' DELIMITER ',' CSV HEADER;"

The \copy command reads the file from your computer and sends it to the database, and is easier to use when there is no direct file access on the server.

Requirement to successfully load a CSV file with psql

The table should already exist with a matching schema.
Problematic columns and values should either be renamed or removed during the cleaning process.
Only then can you use the \ COPY command embedded within the bash script.
In the event of an error message, like mismatched columns or conflicting data types. Adjustment of the file was required.

Running Sample SQL Queries

With the data loaded, you can test and explore your dataset with SQL.

Counting total records

SELECT COUNT(*) AS total_students
FROM student_depression;

Grouping by gender

SELECT gender, COUNT(*) AS count
FROM student_depression
GROUP BY gender;

Average cgpa by depression status

SELECT depression, AVG(cgpa) AS avg_cgpa
FROM student_depression
GROUP BY depression;

Top five cities by number of students

SELECT city, COUNT(*) AS num_students
FROM student_depression
GROUP BY city
ORDER BY num_students DESC
LIMIT 5;

Conclusion and next steps

This project turned out to be a rewarding venture into structuring data into a queryable SQL format. Even though I loaded the dataset into a single flat table, it was a great opportunity to explore and reinforce fundamental concepts of SQL. I now appreciate the importance of a proper schema design.

However, the limitations of the singular table approach quickly became apparent. Analyzing CGPA trends across cities and other measures was difficult to perform effectively. Concepts like common Table Expressions, subqueries, correlated subqueries, and window functions are much more suitable when used with a relational setup.

Moving forward, using primary and foreign keys, the dataset should be normalized and refactored into multiple linked tables to unlock more analytical power.