But they don't check whether the numbers on those elements are correct. A data-pipeline bug that shows Malaysia's population as 3.4 million instead of the real 34 million slips past every selector test in the suite.

The element still exists. A number still renders. The page still looks right. But the bug ships and sits there until a human notices.

I work as a full-stack engineer. Writing end-to-end (E2E) tests with Playwright and unit tests with Jest is part of my day job. I also use Playwright MCP, the bridge between AI assistants like Claude and a running browser, when I need to generate first-draft test code or debug a flow.

None of that tooling closes the maintenance tax on selector-based suites. Every E2E suite I keep alive at work accumulates data-testid selectors, waitForSelector calls, and tests that break because someone renamed a button.

Bug0's Breaking Apps Hackathon gave me a pretext to try something different. Over a weekend, I built an automated regression suite for Malaysia's three public open data portals, data.gov.my, OpenDOSM, and KKMNow, using Passmark, Bug0's open-source AI-driven Playwright library.

The tests are written in plain English. Two AI models verify each assertion. A third arbitrates disagreements.

What You'll Find Below:

• How to write an E2E test that checks whether a dashboard's numbers are correct, not only whether the page renders

• A specific assertion pattern (range-bounded KPIs) that catches an entire class of data-pipeline bug that selector tests miss, with working examples ready to copy

• A cross-field math assertion that takes one sentence in Passmark and around a hundred lines of code without it

• How Passmark's own failure explanations became my debugging loop (the single biggest shift in how I'll write E2E tests going forward)

• The real limits: a 14% cache-hit rate, a dependency on OpenRouter, and what two-model voting fails to catch

Table of Contents

• Why Malaysia's Open Data Portals?

• What Is Passmark?

• The Hero Spec: Range-Bounded Assertions

  • What Two-Model Voting Doesn't Catch

• Going Further: Cross-Field Math

• What I Found Across Three Runs

  • The Debugging Loop

  • The Two Specs That Still Fail Are the Most Interesting

• What It Cost, and Why Cache Rate Is Cost Rate

• The Pattern Worth Stealing

• Honest Verdict

• Resources

Why Malaysia's Open Data Portals?

The hackathon suggested targets like Vercel Commerce, Cal.com, and Hashnode. These all would've been solid picks.

But I wanted to test something local and closer to my day-to-day work instead. I also wanted a data-heavy site where the numbers on screen have to be accurate, as I work with numbers too on a daily basis.

Malaysia has three public open-data portals:

• data.gov.my, run by MAMPU, the government's digital transformation agency

• OpenDOSM, run by the Department of Statistics

• KKMNow, run by the Ministry of Health

They're public, no authentication required, with documented APIs. Seemed like a good fit for an automated test suite. The data on them is what Malaysians use every day, so accuracy isn't optional.

What Is Passmark?

Passmark is a Playwright library where the tests read like specs. Here's an example:

await runSteps({
  page,
  userFlow: "population dashboard smoke",
  steps: [
    { description: "Navigate to https://data.gov.my/dashboard/kawasanku" },
    {
      description: "Wait for the country-level Malaysia view to render",
      waitUntil: "A headline population number is visible",
    },
  ],
  assertions: [
    {
      assertion:
        "The page shows Malaysia's total population as a number greater than 20 million and less than 40 million",
    },
  ],
  test,
  expect,
});

There are no selectors, no data-testid, and no page.locator(). The assertion expresses what I care about, in the words I would use with a colleague.

On the first run, an AI agent drives the page and caches the resolved Playwright action to Redis. Every run after that replays at native Playwright speed with zero model calls.

When the UI changes and a cached action fails, the AI re-engages only for that step. Two assertion models (Claude and Gemini) vote. A third model arbitrates disagreements.

The Hero Spec: Range-Bounded Assertions

Range-bounded assertions were the first shape of test I wrote, and the one I came back to most across the suite.

The idea is straightforward: check that a number on the page falls inside a sensible range, not that a specific element exists.

The image below is the Playwright report from the population spec, with all four range-bounded assertions passing.

The range-bounded population test is the one that shows Passmark's real value.

Traditional Playwright asserts DOM structure. It confirms that an element with class kpi-total contains the text 34.2 million. That tells you the page rendered, not whether the number makes sense.

A bug that shows Malaysia's population as 3.42 million sails past any selector test. The DOM is correct. The number renders. Nothing breaks in the conventional sense.

Passmark reads the page, evaluates the claim, and fails because 3.42 million falls outside the sane range. Two models vote. A hallucination by one model alone produces no false pass.

What Two-Model Voting Doesn't Catch

Voting defends against one model misreading the page. It doesn't defend against both models misreading the page the same way. If Claude and Gemini both parse "32.4 million" as "3.24 million" because of the same unusual spacing in the DOM, they agree, they vote pass, and the bug ships.

The mitigation is assertion design. Write assertions that are hard to misread. A range check ("between 20 million and 40 million") is harder for a model to get wrong than a prose check ("roughly 34 million"). Numerical bounds leave less room for interpretation than adjectives. The more your assertion looks like a unit test written in English, the less room the models have to disagree.

Going Further: Cross-Field Math

Range-bounded assertions are a good first step. They catch "is this number in the right ballpark?" But they don't catch "do these numbers agree with each other?"

For that, you need cross-field math. If a dashboard shows a total population and a breakdown by gender, those two things are supposed to agree. Male plus female should equal total. Ethnicity breakdown percentages should sum to 100.

test("Cross-field math: sex breakdown sums to total population", async ({ page }) => {
  test.setTimeout(180_000);
  await runSteps({
    page,
    userFlow: "population sex breakdown consistency",
    steps: [
      { description: "Navigate to https://data.gov.my/dashboard/kawasanku" },
      {
        description: "Wait for the Malaysia country-level view with breakdown data",
        waitUntil:
          "A headline total population figure is visible and a breakdown by sex is shown on the page",
      },
    ],
    assertions: [
      {
        assertion:
          "The male and female population values shown on the page add up to approximately the headline total population, within a 5% margin",
      },
      {
        assertion:
          "Any percentage-based breakdowns visible on the page (by sex, age, or ethnicity) sum to approximately 100% within a 2 percentage-point margin",
      },
      {
        assertion: "No breakdown value is negative or greater than the headline total",
      },
    ],
    test,
    expect,
  });
});

Try writing that in vanilla Playwright. You need selectors for the headline number, selectors for the breakdown components, number parsing with a comma-aware regex, and a margin calculation. Seventy to a hundred lines of code to verify three invariants a primary school student would call obvious.

The Passmark version is one spec. I ran it against Kawasanku's live country view. All three assertions passed in 1.4 minutes. Passmark's annotation, verbatim:

"The headline total population figure 'Malaysia has a population of 32,447,385 people.' is visible, and 'Gender And Age Distribution' is shown, which implies a breakdown by sex (male, female) will be available."

Two models read the page, extract the numbers, do the arithmetic, and agree. When the dashboard changes layout in three months, the same assertion still works, because it never named a selector.

This is the class of test I want running against every dashboard product that I touch. Financial totals matching their line items. Percentages that sum to 100. Inventory counts equal to the sum of warehouse locations. This rarely gets checked today, because writing the check by hand outweighs the perceived value of running it.

What I Found Across Three Runs

Every passing spec after run 1 came from Passmark telling me, in plain English, why my assertion didn't match the page.

Here are three examples from run 1:

For dataset-detail.spec.ts, I asserted "an API usage snippet (curl or JS) is shown." knowingly that the page is using Python and I wanted to see what the result was. Passmark replied:

"The page contains API usage snippets, but they are specifically for Python using the requests library. There are no snippets provided in curl or JavaScript formats."

The page had snippets. I asked for the wrong languages. Fix: accept any language.

For dashboard-population.spec.ts, I asserted "a chart visualizing population by age or ethnicity is rendered." Passmark replied:

"The current page displays charts for vital statistics such as Live Births, Deaths, and Natural Increase over time, but there is no chart visualizing population specifically by age groups or ethnicity."

The charts are there. Not the slice I guessed. Fix: accept any chart about population.

For kkmnow/hospital-utilisation.spec.ts, I asserted a "headline bed-utilisation percentage." Passmark replied:

"While there are multiple bed-utilisation percentages listed in tables and rankings further down the page, there is no prominent, top-level headline KPI figure displaying the overall bed-utilisation percentage."

The numbers are there. I had asked for a layout the designers didn't build.

This is the killer feature: Passmark's failure messages aren't stack traces. They're explanations. The AI read the page, compared it against my words, and pointed me at the fix. Nothing like a selector-based test throwing TimeoutError: waiting for locator.

The Debugging Loop

Once I saw the pattern, the loop became my main technique. Here's the procedure:

1. Read the failure message word for word. Don't skim.

2. Trust it as a description of what is on the page. The AI has read the page. Your assertion has not.

3. Rewrite the assertion so it matches what's on the page. Broaden, narrow, or restate.

4. Run it again.

The discipline is to not argue with the tool. The page is what the page is. Your assertion is what is wrong. Every time I tried to "fix" the page (convinced my assertion was right and the site was broken), I lost some time. Every time I took the failure message at face value and rewrote, the test passed on the next run.

This is the one of the changes in how I'll write E2E tests going forward. The feedback loop is the tool. Every failed assertion is a draft of the correct one.

The Two Specs That Still Fail Are the Most Interesting

1. The two models disagreed and the arbiter call failed.

On catalogue-search.spec.ts, Claude voted fail (72% confidence) and Gemini voted pass (100% confidence) on the same assertion. I had written the assertion in a way that read two ways.

Passmark escalated to an arbiter model through OpenRouter. The call came back with a 504 from Cloudflare. The arbiter never ran. The suite failed the spec.

This is an honest limit, not a fluke. Any CI that runs Passmark depends on OpenRouter's availability. External gateway errors happen. My fix for the final run was a global retry wrapper around the OpenRouter call, and the 504 stopped being a problem in practice.

If you bring this to production CI, plan for retries and treat OpenRouter outages as a first-class failure mode in your runbook.

This failure taught me something about assertion design: my wording was ambiguous. Claude's reading was reasonable. Gemini's reading was reasonable. When you write tests in English, being precise about what you mean is part of writing a good test.

2. The wait condition fired too early.

On the KKMNow spec, I had waitUntil: "A utilisation metric is visible". The page showed the section label "Hospital Bed Utilisation (%)" before the numbers finished loading. The wait step saw the label, decided the condition was met, and moved on. By the time the numbers rendered, the test had run out of time. Once the page was fully loaded, the range assertions would have passed on content.

"The page displays multiple bed-utilisation percentages within the specified range (0% to 120%). For example, the ranked list shows Perlis at 93.1% and Melaka at 88.2%."

The lesson: your waitUntil wording needs the same care as your assertion wording. Both are read by AI. A vague wait is as bad as a vague assertion.

What It Cost, and Why Cache Rate Is Cost Rate

Each of the three runs took about 20 minutes on 13 specs with a single worker. The hackathon's pooled OpenRouter key covered the AI costs, so I have no personal dollar figure to report.

The more useful cost finding is what gets cached.

$ docker exec passmark-redis redis-cli DBSIZE
5

Five steps out of roughly 35 were cached across three runs. A 14% cache-hit rate. The Passmark README explains why:

Only steps that produced a single tool call get cached. Multi-step sequences are considered non-deterministic.

Most of my steps described multi-tool sequences. "Open the area selector and choose Selangor, then wait for navigation" becomes click, wait, verify. Those don't cache by design.

This matters for your budget. An 86% miss rate means 86% of your steps call a model on every run. The cost model is per-tool-call via OpenRouter.

To estimate your own bill: count non-atomic steps in your suite, multiply by your chosen model's per-call price at current OpenRouter rates, and the product is your recurring cost per run. Cache rate is cost rate.

The fix is authoring discipline. Split compound descriptions into atomic steps. Treat cache fill rate as a metric you track, not an implementation detail to ignore. A suite with 80% atomic steps costs a fifth of a suite with 14%.

The Pattern Worth Stealing

The idea here is bigger than Passmark.

Check that the numbers on your dashboards make sense. Most teams don't. They should.

A one-line assertion like "the headline number is between 20 million and 40 million" catches several classes of bug regular tests miss.

Here are four common ones:

• The data pipeline divided by the wrong thing, so the number on screen is ten times too small.

• A timezone bug made yesterday's total show up under tomorrow's date.

• The data never refreshed, so users are looking at last week's numbers.

• A locale flip swapped commas and decimals, so 1,234,567 is now reading as 1.234567.

Civic portals were my target. The pattern applies anywhere a dashboard shows numbers. Fintech reports, SaaS analytics, healthcare metrics, e-commerce admin panels. Any screen where a number is supposed to mean something.

Most of these numbers never get tested. Writing the check by hand is tedious. You need a selector to find the number, code to parse it, code to handle units, and a margin calculation. Fifty lines for one check. Nobody bothers.

You don't need Passmark to steal the idea. The same check works in plain Playwright with page.evaluate and number parsing. The Passmark version is just more efficient to write and readable by anyone on the team, not only engineers.

Honest Verdict

Passmark works. Across three runs I went from 4 of 13 passing to 12 of 13 without touching a selector, guided by the tool's own feedback.

Still, the caveats are real:

• On a cold cache, every step waits for a model. Budget more wall-clock time than a selector suite.

• In my suite only 14% of steps cached. The other 86% pays model cost on every run. Authoring discipline (atomic steps) is the difference between cents and dollars per run.

• Two-model voting doesn't protect against both models misreading the same way. Write assertions that are hard to misread.

• Every assertion depends on OpenRouter's availability. External gateway errors need a retry strategy before this runs in CI.

What stuck with me: Passmark didn't make me better at Playwright. It made me write tests I would have skipped otherwise.

What I imagine myself doing at work:

• Run a small nightly Passmark suite against the critical dashboards, focused on range and freshness checks.

• Keep traditional Playwright and Jest for everything that has to be fast and deterministic.

• Treat every Passmark failure message as a specification of the page, not an error to argue with.

Try this, even if you never touch Passmark. Pick a number on a dashboard you work with. Write a test that fails if the number is outside a sane range. See what breaks. That is the whole pattern and purpose of this article.

Resources

• Repo: github.com/LeeRenJie/passmark-hackathon

• Passmark: github.com/bug0inc/passmark

• Breaking Apps Hackathon: hashnode.com/hackathons/breaking-things

• Test targets: data.gov.my, OpenDOSM, KKMNow

For a project I was recently working on, the requirement was to use WordPress as the site's backend. Content management, blog posts, and media were all handled through the WordPress admin. The frontend was open: it could be a theme, a template, or something customized through Elementor.

I could've built the same result in Elementor, but the process would've been slower and harder to maintain. Drag-and-drop works until the design gets specific, and then every small tweak costs more time than it should.

As a full stack developer, writing code turned out to be faster for me and produced cleaner output. Tools like Claude Code make the iteration cycle even tighter. So I kept the requirement – WordPress as the backend – and decided to build the frontend separately in code.

I wanted to share how I did this so that, if you're facing similar requirements, you'll know the way forward.

By the end of this tutorial, you'll have:

• A WordPress install serving content through its REST API on a subdomain

• An Astro SSR frontend rendering the content on the root domain

• A Cloudflare Pages deployment triggered on every git push

• Security hardening for a headless WordPress setup

• Draft post preview working across both systems

Prerequisites: You should be comfortable with the command line, have basic familiarity with WordPress admin, and know enough JavaScript to read and write simple functions.

To follow along, you'll need a WordPress installation, a GitHub account, and a Cloudflare account.

Table of Contents

• Why Headless WordPress?

• The Architecture

• Why Astro?

• Infrastructure Setup

  • Step 1: Move DNS to Cloudflare

  • Step 2: Create the CMS Subdomain

• WordPress Configuration

  • Tell WordPress it Lives on the Subdomain

  • Must-Use Plugin: Redirect and Preview

  • Clean Up Plugins

• The Astro Frontend

  • astro.config.mjs

  • .env

  • src/lib/wordpress.js

  • src/middleware.js

  • src/layouts/Layout.astro

  • src/pages/blog/index.astro

  • src/pages/blog/[slug].astro

  • src/pages/sitemap.xml.ts

  • src/styles/global.css

• CI/CD with Cloudflare Pages

• Final Thoughts

• Good to Know

Why Headless WordPress?

Headless WordPress separates content management from content delivery. WordPress keeps doing what it handles well: storing content and giving editors a familiar admin interface. A separate frontend handles rendering, routing, and performance.

A few situations where this split pays off:

• Your content team is trained on WordPress and moving them elsewhere would slow everyone down. Headless preserves their workflow and gives you a modern frontend.

• Your site needs a design or interaction pattern that a WordPress theme or page builder struggles to deliver. Custom dashboards, interactive tools, data-driven layouts, or integrations with non-WordPress APIs all fit here.

• You want edge delivery and modern tooling without rebuilding content management from scratch. WordPress handles content and media well. A JavaScript frontend on a CDN handles delivery well. Headless lets each side do its job.

• You need the same content across multiple surfaces. One WordPress install feeds a marketing site, a mobile app, and an internal dashboard through the same REST API.

Headless is not a fit for every site. Skip it if your site is a simple brochure, if one person does everything in the admin, or if you have no developer time to maintain a second codebase. A regular WordPress theme is the better answer there.

The Architecture

The term "headless" means you strip WordPress of its frontend responsibility. Instead of WordPress generating and serving HTML pages to visitors, it only stores and serves content through its REST API. A separate frontend framework, in this case Astro, handles what the visitor actually sees.

When a visitor loads a page, the request hits Cloudflare Pages, which runs the Astro server. Astro fetches the relevant content from WordPress via the REST API, builds the HTML, and returns it to the visitor. WordPress never touches the visitor's browser.

Content editors log into the WordPress admin at the CMS subdomain. They write, publish, and manage content as they normally would. The moment they publish, the content is live. There's no rebuild step because Astro fetches fresh data on every request.

The REST API has been built into WordPress since version 4.7. You don't need a GraphQL plugin, a paid headless CMS service, or any extra infrastructure.

Why Astro?

You could use Next.js, Nuxt, or SvelteKit here as well. But I chose Astro because its defaults fit this use case.

Astro compiles components to plain HTML and ships zero JavaScript to the browser by default. You only add client-side JavaScript where you explicitly need it.

For a CMS-driven site, most pages need none. SSR mode means every request fetches fresh data from WordPress at runtime, so content changes go live immediately without a rebuild. Cloudflare has an official adapter that handles the build output. Tailwind v4 integrates through a Vite plugin with no config file needed.

If WordPress wasn't a requirement, I would have used Next.js with Payload CMS. Payload gives you a fully typed CMS built in TypeScript that sits inside the same Next.js project, with more control over your content schema from day one. But the requirement was WordPress, and for a WordPress REST API frontend, Astro is the faster and cleaner choice.

Infrastructure Setup

Here's my setup: domain at Namecheap, WordPress on Hostinger shared hosting, and a Google Workspace email. The steps below apply to any host, whether shared hosting with cPanel or hPanel, a VPS with Apache or Nginx, or a self-managed server.

Step 1: Move DNS to Cloudflare

First, you'll need to move your domain's nameservers to Cloudflare. This gives you free DDoS protection, SSL, and the ability to attach a custom domain to Cloudflare Pages.

Before switching, verify that all DNS records transferred correctly, including your website A or CNAME records. For email, get your MX, SPF, DKIM, and DMARC values from your email provider's admin panel and add them to Cloudflare DNS first, otherwise email breaks during propagation.

Step 2: Create the CMS Subdomain

Move WordPress to cms.yourdomain.com so the root domain is free for Astro. In Cloudflare DNS, add an A record pointing cms at your server IP, or a CNAME if your host uses a CDN hostname. Then create the subdomain in your hosting panel pointing to the same WordPress directory.

One thing people miss: your server needs its own SSL certificate for the connection between Cloudflare and your origin to work. Cloudflare handles SSL at its edge, but if the origin has no certificate, you get a 525 error.

On Hostinger, this isn't automatic for new subdomains. Install it manually through hPanel. On cPanel, use Let's Encrypt. On a VPS, use Certbot.

Moving WordPress off the root domain also means /wp-admin no longer exists at your main domain, which reduces exposure. But the default login path is still /wp-admin on the subdomain. That is the first thing you should change — more on this in the Good to Know section at the end.

WordPress Configuration

Tell WordPress it Lives on the Subdomain

In wp-config.php, before the "That's all, stop editing!" comment:

define('WP_HOME',    'https://cms.yourdomain.com');
define('WP_SITEURL', 'https://cms.yourdomain.com');

WordPress admin is now at cms.yourdomain.com/wp-admin. The old path at the root domain stops working. That's intentional.

Must-Use Plugin: Redirect and Preview

WordPress has a folder called mu-plugins inside wp-content. Files placed there are treated as must-use plugins. They load automatically on every request, before regular plugins, and there is no way to activate or deactivate them through the admin UI. This makes them the right place for behaviour you never want accidentally turned off.

Create wp-content/mu-plugins/headless-redirect.php:

<?php
/*
Plugin Name: Headless Redirect
Description: Redirects frontend visitors to the Astro site and rewires the WordPress preview link.
*/

add_action('template_redirect', function() {
    if (is_user_logged_in()) return;
    if ($_SERVER['HTTP_HOST'] === 'cms.yourdomain.com') {
        wp_redirect('https://yourdomain.com', 302);
        exit;
    }
});

add_filter('preview_post_link', function(\(link, \)post) {
    $token = HEADLESS_PREVIEW_SECRET;
    \(type  = \)post->post_type;
    return 'https://yourdomain.com/preview?type=' . \(type . '&id=' . \)post->ID . '&token=' . $token;
}, 10, 2);

The template_redirect action fires when WordPress is about to render a page. If the visitor isn't logged in and the request is on the CMS subdomain, it redirects them to the main frontend. Logged-in editors pass through to the admin normally. REST API requests to /wp-json/... don't go through template_redirect at all, so they are unaffected.

The preview_post_link filter changes what happens when an editor clicks Preview on a draft post. By default, WordPress previews using its own theme, which in a headless setup renders blank.

This filter replaces that URL with a request to your Astro /preview page, passing the post ID, post type, and a secret token. Your Astro preview page uses those values to fetch the draft via the REST API and renders it exactly as it would appear live.

Clean Up Plugins

Now it's time to remove everything that renders the frontend: page builders, caching plugins, and hosting onboarding plugins.

But you'll want to keep Akismet, Wordfence, and Yoast SEO. Yoast adds SEO meta and Open Graph data directly to the REST API response, which your Astro pages read through post.yoast_head_json.

Then switch the active theme to a lightweight default. WordPress requires one active, but nobody sees it.

The Astro Frontend

Start with pnpm create astro@latest, then install the Cloudflare adapter and Tailwind:

pnpm add @astrojs/cloudflare
pnpm add -D @tailwindcss/vite tailwindcss

astro.config.mjs

import { defineConfig } from 'astro/config'
import cloudflare from '@astrojs/cloudflare'
import tailwindcss from '@tailwindcss/vite'

export default defineConfig({
  output: 'server',
  adapter: cloudflare({ imageService: 'passthrough' }),
  vite: { plugins: [tailwindcss()] },
})

output: 'server' puts Astro into full SSR mode. Without it, Astro pre-renders pages at build time, which breaks dynamic routes like /blog/[slug] that depend on WordPress content that didn't exist at build time.

imageService: 'passthrough' is required specifically for Cloudflare Workers. Astro's default image service uses Sharp, which depends on child_process and fs. Those Node.js built-ins don't exist in the Cloudflare Workers runtime. The deployment fails with a module resolution error. Setting passthrough skips image processing entirely and renders standard <img> tags instead.

.env

WORDPRESS_API_URL=https://cms.yourdomain.com

Add this same variable in Cloudflare Pages project settings under Environment Variables before deploying.

src/lib/wordpress.js

This file is the single place all WordPress API calls go through. Centralising them means if the API URL or authentication changes, you update one file.

The _embed parameter is important. By default, a post response only includes the post data. Featured images, author details, and categories are separate entities with their own IDs. Without _embed, you would need additional API requests to fetch each one. Adding it inlines all that related data into the same response.

cache: 'no-store' on every fetch call is not optional. Cloudflare Workers runs a fetch cache internally that's separate from HTTP Cache-Control headers. Without disabling it, Cloudflare caches your WordPress API responses at the edge. An editor publishes a post and sees the old version on the frontend because the cached response is being served.

const WP_URL = import.meta.env.WORDPRESS_API_URL

const fetchWP = (path) =>
  fetch(`\({WP_URL}\){path}`, { cache: 'no-store' }).then((r) => r.json())

export const getPosts = (page = 1, perPage = 10) =>
  fetchWP(`/wp-json/wp/v2/posts?_embed&per_page=\({perPage}&page=\){page}`)

export const getPostBySlug = async (slug) => {
  const posts = await fetchWP(`/wp-json/wp/v2/posts?_embed&slug=${slug}`)
  return posts[0]
}

export const getCategories = () =>
  fetchWP(`/wp-json/wp/v2/categories`)

export const getPostsByCategory = (categoryId, page = 1) =>
  fetchWP(`/wp-json/wp/v2/posts?_embed&categories=\({categoryId}&page=\){page}`)

export const getAllPostsForSitemap = () =>
  fetchWP(`/wp-json/wp/v2/posts?_fields=slug,modified&per_page=100`)

The sitemap function uses _fields instead of _embed to fetch only the fields it needs, keeping that request lightweight.

src/middleware.js

Middleware runs on every request before the page handler. This one adds Cache-Control: no-store to every SSR response so Cloudflare doesn't cache the rendered HTML pages.

export function onRequest(_context, next) {
  return next().then(response => {
    const newResponse = new Response(response.body, response)
    newResponse.headers.set('Cache-Control', 'no-store, no-cache, must-revalidate')
    newResponse.headers.set('CDN-Cache-Control', 'no-store')
    return newResponse
  })
}

The original Response from Astro has immutable headers, so you can't call .headers.set() on it directly. The fix is to construct a new Response using the original body and response as the init argument. The new Response has mutable headers, so .set() works. CDN-Cache-Control is a Cloudflare-specific header that controls caching at the edge independently from the standard Cache-Control header.

src/layouts/Layout.astro

Every page goes through this layout. HTML structure, meta tags, and global imports live here so you don't repeat them on every page.

---
interface Props {
  title: string
  description?: string
}
const { title, description = '' } = Astro.props
---
<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>{title}</title>
    <meta name="description" content={description} />
  </head>
  <body>
    <slot name="nav" />
    <main id="main-content"><slot /></main>
    <slot name="footer" />
  </body>
</html>

Named slots let the navbar and footer sit outside <main>, keeping the HTML landmark structure correct for accessibility.

src/pages/blog/index.astro

---
import Layout from '../../layouts/Layout.astro'
import { getPosts, getCategories, getPostsByCategory } from '../../lib/wordpress'

const page = Number(Astro.url.searchParams.get('page') ?? 1)
const categoryId = Astro.url.searchParams.get('category')

const [posts, categories] = await Promise.all([
  categoryId ? getPostsByCategory(categoryId, page) : getPosts(page, 10),
  getCategories(),
])
---
<Layout title="Blog">
  <nav>
    <a href="/blog">All</a>
    {categories.map((cat) => (
      <a href={`/blog?category=${cat.id}`}>{cat.name}</a>
    ))}
  </nav>

  <ul>
    {posts.map((post) => {
      const image   = post._embedded?.['wp:featuredmedia']?.[0]?.source_url
      const imageAlt = post._embedded?.['wp:featuredmedia']?.[0]?.alt_text ?? ''
      return (
        <li>
          {image && <img src={image} alt={imageAlt} />}
          <a href={`/blog/${post.slug}`} set:html={post.title.rendered} />
          <div set:html={post.excerpt.rendered} />
        </li>
      )
    })}
  </ul>

  {page > 1 && <a href={`/blog?page=${page - 1}`}>Previous</a>}
  <a href={`/blog?page=${page + 1}`}>Next</a>
</Layout>

Promise.all fetches posts and categories in parallel. The category filter reads from the URL query string so the same page handles both /blog and /blog?category=5 without separate routes.

Featured images live inside post._embedded['wp:featuredmedia'][0] because _embed inlines the media object into the post response.

src/pages/blog/[slug].astro

---
import Layout from '../../layouts/Layout.astro'
import { getPostBySlug } from '../../lib/wordpress'

const { slug } = Astro.params
const post = await getPostBySlug(slug)
if (!post) return Astro.redirect('/404')

const image    = post._embedded?.['wp:featuredmedia']?.[0]?.source_url
const imageAlt = post._embedded?.['wp:featuredmedia']?.[0]?.alt_text ?? ''
const author   = post._embedded?.author?.[0]?.name
const seoTitle = post.yoast_head_json?.title ?? post.title.rendered
const seoDesc  = post.yoast_head_json?.og_description ?? ''
---
<Layout title={seoTitle} description={seoDesc}>
  <article>
    <h1 set:html={post.title.rendered} />
    <p>{author} · {new Date(post.date).toLocaleDateString()}</p>
    {image && <img src={image} alt={imageAlt} />}
    <div set:html={post.content.rendered} />
  </article>
</Layout>

Use set:html for WordPress content, not {post.content.rendered}. Astro treats curly brace expressions as text and escapes the HTML, so you see raw tags printed on the page instead of rendered content.

Always guard with if (!post) return Astro.redirect('/404'). If someone visits a slug that doesn't exist, the API returns an empty array. Without the guard, accessing properties on undefined throws an error that crashes the Cloudflare Worker and returns a 500.

post.yoast_head_json is available when Yoast SEO is active. It contains the computed SEO title and description that Yoast generates. Using it means the SEO work done in WordPress carries over to the Astro frontend automatically.

src/pages/sitemap.xml.ts

import type { APIRoute } from 'astro'
import { getAllPostsForSitemap } from '../lib/wordpress'

export const GET: APIRoute = async () => {
  const posts = await getAllPostsForSitemap()

  const urls = [
    { loc: 'https://yourdomain.com/', lastmod: new Date().toISOString() },
    { loc: 'https://yourdomain.com/blog/', lastmod: new Date().toISOString() },
    ...posts.map((p) => ({
      loc: `https://yourdomain.com/blog/${p.slug}/`,
      lastmod: p.modified,
    })),
  ]

  const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
\({urls.map((u) => `  <url>\n    <loc>\){u.loc}</loc>\n    <lastmod>${u.lastmod}</lastmod>\n  </url>`).join('\n')}
</urlset>`

  return new Response(xml, { headers: { 'Content-Type': 'application/xml' } })
}

This generates fresh XML on every request, so the sitemap always reflects currently published posts without a rebuild.

src/styles/global.css

@import "tailwindcss";

@theme {
  --color-brand: #your-color;
  --font-sans: 'Your Font', sans-serif;
}

Tailwind v4 uses CSS-first configuration through the @theme block. CSS variables defined here become Tailwind utilities automatically. --color-brand becomes bg-brand, text-brand, and so on. No tailwind.config.js needed.

CI/CD with Cloudflare Pages

With the Astro code in place, the last piece is getting it deployed. Cloudflare Pages connects directly to GitHub, so you don't have to maintain a separate pipeline.

Here are the steps:

1. Push your repo to GitHub.

2. Go to Cloudflare Pages, create a project, connect it to your GitHub repository.

3. Set the build command to pnpm build and the output directory to dist.

4. Under Environment Variables, add WORDPRESS_API_URL pointing to https://cms.yourdomain.com.

5. Deploy.

After the first deploy, every push to main triggers a new deployment automatically. Cloudflare runs the build, and within minutes the new version is live globally. Content updates in WordPress go live immediately, since Astro fetches from WordPress on every request. A developer pushing code and an editor publishing a post are completely independent operations.

Final Thoughts

This setup exists because of the specific requirement that the content team was already on WordPress and changing that was not on the table.

If you're starting fresh with no CMS in place, this is probably not the stack you want. Go with something like Next.js and Payload CMS where the backend and frontend are designed to work together from the start.

But if your situation matches where content editors are already familiar with WordPress, and you need a custom frontend that a page builder can't deliver cleanly, then this separation makes sense.

Pros:

• Content editors keep using WordPress. No retraining, no migration.

• The frontend has full control over design and behaviour. No theme or plugin constraints.

• Deployments are automatic on every push. Content changes go live immediately without a rebuild.

• No added cost for most sites. WordPress stays on its existing host. Cloudflare Pages is free within generous limits, and scales to $5 per month on the Workers Paid plan if you outgrow them.

Cons:

• Two systems to maintain instead of one. You operate the WordPress install (updates, plugins, backups) and maintain the Astro codebase separately.

• The WordPress REST API has limitations. Complex content structures or real-time features need more work to handle compared to a purpose-built headless CMS.

• Adapter and deployment target are tied together. @astrojs/cloudflare v13 drops Pages support in favor of Workers, so staying on Pages means staying on v12. Details in the Good to Know section.

• Frontend changes require a developer. With Elementor, anyone with admin access could adjust layouts directly in the browser. Here, any visual change outside of content goes through code, which means it goes through you.

The stack is WordPress on existing hosting, Astro on Cloudflare Pages, with GitHub as the bridge between development and production. It solves a specific problem cleanly. Outside of that problem, there are better options.

Good to Know

Change the default login URL immediately. Every bot targets /wp-login.php and /wp-admin. Install WPS Hide Login and move it to something custom. Anyone hitting the default paths gets a 404.

Remove the /wp-json/wp/v2/users endpoint. It returns a public list of usernames. In headless mode you get author data through _embed and have no use for this endpoint. Add to the mu-plugin:

add_filter('rest_endpoints', function($endpoints) {
    unset($endpoints['/wp/v2/users']);
    unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    return $endpoints;
});

Disable XML-RPC and enable 2FA. Add add_filter('xmlrpc_enabled', '__return_false') to the mu-plugin — you aren't using it in headless mode and it's a common brute force target. Enable Wordfence's Brute Force Protection and add two-factor authentication through WP 2FA for all admin accounts.

Don't upgrade @astrojs/cloudflare to v13 if you deploy via Cloudflare Pages git-push CI. v12 outputs dist/_worker.js which Pages CI expects. v13 outputs a different format for wrangler deploy — Pages CI falls back to serving the dist folder as a static site and every SSR route returns 404 with no helpful error message.

The v12 adapter throws a deprecation warning on entrypointResolution. Silence it by adding entrypointResolution: 'auto' to the adapter options. Test before committing — it changes how the build locates the Worker entry file.

Custom Post Types follow the same pattern. Register the CPT with show_in_rest: true and a rest_base, and it shows up at /wp-json/wp/v2/your-base. The same fetch helpers, _embed, and slug routing work exactly the same way.

The REST API returns pagination headers. The raw response includes X-WP-Total and X-WP-TotalPages headers before you call .json(). If you want proper previous/next pagination, read those instead of guessing whether a next page exists.

Wrap API calls in try/catch. If WordPress is unreachable, an unhandled fetch throws and returns a 500. A try/catch returns an empty page instead, which is a much better failure mode.

Preview auth uses Application Passwords. WordPress 5.6 added Application Passwords under Users → Profile. That's what WP_APP_USER and WP_APP_PASSWORD in your .env should point to — not your regular admin password. Generate one per environment. Define the preview token as a constant in wp-config.php (define('HEADLESS_PREVIEW_SECRET', '...')) and reference that constant in the mu-plugin — never hardcode secrets in version-controlled files.

A recent Harvard-backed study of 285,000 firms found that junior software engineering roles have declined by 23%, while senior roles have increased by 14%.

Part of the reason is that many graduates come out of university with similar academic results. A good CGPA matters, but on its own, it rarely shows employers how you will perform in a real work setting. At the same time, with AI boosting productivity, companies often see more value in pairing senior developers with AI tools than hiring juniors who still need time to adapt.

That is exactly why hackathons matter. They give students a chance to stand out by showing they can solve real problems, work with real technologies, and create solutions that add value beyond what AI can do. It is one of the clearest ways to build credibility and open doors in a market where traditional first jobs are getting harder to land.

I did not begin with a big international hackathon. My first hackathon was a small one on campus, and to be honest, I almost did not go. I had never built anything outside of class assignments, and I worried I would not be good enough. In the end I signed up anyway, even though I did not have a full team and had no idea what to expect.

That first experience showed me that hackathons are not about being an expert, they are about being willing to learn on the spot. I made mistakes, but I also picked up new skills and met people who were just as nervous and curious as I was. The point is that hackathons are meant for learning and experimenting, just like university, only here you get to do it in a setting closer to real-world. Realizing that took the pressure off and gave me the confidence to join bigger competitions later.

When my team “Sweetzerland” joined the Hilti IT Competition 2024 with support from my university, Asia Pacific University of Malaysia, it was not the usual hackathon. Instead of a weekend sprint, it lasted months. We had time to do research, design the system, build it out, and finally pitch it.

The process was tough, but it gave us real exposure that lectures rarely provide, and it opened doors I never expected. I even used it as the solution for my final year project, which later received the best project award during graduation.

Here’s why I believe every student should try participating in as many hackathons as possible during their college/university days.

Table Of Contents

• You Meet People Who Care as Much as You Do

• From Case Studies to Real Solutions

• Teamwork and Feedback

• Opportunities and Growth

• It’s Simply Fun

• Where to Find Hackathons

• Final Thoughts

You Meet People Who Care as Much as You Do

One of the best parts of hackathons is the people you meet. You are surrounded by others who are just as motivated to solve problems and willing to put in the effort to make their ideas work. Everyone brings their own strengths, whether it is coding, design, research, or pitching, and you quickly see how much energy and passion fills the room.

I remember in my previous hackathon, some teams were experimenting with VR while others used machine learning, all tackling the same theme in completely different ways. It was exciting to see how many different approaches people could bring to the same problem. And when the community is small, you often find similar participants in various hackathons.

That shared drive creates a special kind of connection. The people you brainstorm with at 2 a.m. or share a quick meal with between sessions often become friends, collaborators, or mentors long after the hackathon ends. It is not just about competing, it is about finding a community of people who are just as curious and committed as you are.

From Case Studies to Real Solutions

In university, most projects come with fictional case studies and guided hints. Hackathons are different. You are given a theme and have to figure out the real problem behind it, design a solution that actually fits how the company/industry works, and make sure it is viable to roll out with a clear return on investment. That shift from schoolwork to solving real-world issues changes the way you think.

Along the way, you also end up using industry standard tech stacks, solving problems under real constraints, and learning how to push past self-doubt. Imposter syndrome is common when you see so many great ideas around you. Our brain is built for survival, so it naturally reacts with fear when facing something new and uncertain. What helped me was reframing that fear, not as proof that I did not belong, but as proof I was stepping into a new territory. Breaking problems into smaller wins, asking questions openly, and remembering that even the most confident people in the same room will feel the same way made it easier to keep going. Over time, the progress you see in yourself becomes the best confidence boost of all.

Teamwork and Feedback

What surprised me most in a hackathon was how much the team dynamic mattered. I usually worked on the frontend or as a full stack developer, but I quickly learned that code alone would not carry the project. The real challenge was keeping research, design, coding, and slide preparation all moving in parallel. With limited time, you cannot afford to wait for one task to finish before starting another, so clear delegation and trust in each teammate’s role are critical.

A good teammate is not just skilled, but committed. The teams that thrived were the ones where people showed up consistently, shared ideas openly, and pushed through even when the energy dipped. In longer hackathons especially, perseverance mattered more than raw talent.

The feedback from mentors also changed how I thought about building solutions. In one hackathon, a mentor asked us, “What is the main feature in your solution?” That hit me, because we had built a system that did a bit of everything, but nothing stood out. After that, we focused on one main feature we had researched, the one we knew could create the biggest impact for the business. We spent most of our time refining that flow and only mentioned the smaller features briefly.

That lesson stuck. As software engineers, it is tempting to show how many features we can build, because our mindset is often stuck at “more features mean more skillful, which means a higher chance of winning.” That may work for school projects, but businesses care about ROI. They want to know if your solution is strong enough to justify the resources it would take to implement. Focusing on the feature with exponential upside not only made our pitch clearer, but it also shifted how I think about software engineering as a whole. It is not just about writing code, but about creating value that matters to businesses.

Opportunities and Growth

Hackathons open doors in ways you might not expect. When I started applying for jobs, having hackathon experience on my CV made it easier to stand out. Recruiters saw it as proof that I could solve problems under pressure and collaborate with others.

Some opportunities also come in unexpected forms. For me it was getting featured in The Star, Malaysia’s national newspaper, which showed me that hackathons can give you visibility and credibility beyond the competition itself.

Most importantly, hackathons shifted my mindset. After competing I found myself saying yes to more opportunities and pushing past my comfort zone. And once I did it, I kept doing it. Each step gave me more exposure and confidence, because the last time I did that, it gave me a life-changing experience. This has benefitted me in many ways once I started working. When we are young, we have time, energy, and fewer commitments. That is when growth can be exponential if we take risks with minimal downsides.

It’s Simply Fun

The most important point is that Hackathons are also fun. You meet people, you get swags, you grow your portfolio, you get cold hard cash, and sometimes you get to travel. And out of all the hackathons, for me it meant a trip to Switzerland, something I never imagined a student hackathon would bring. And I wouldn’t change a thing if I was given them same choice again.

Where to Find Hackathons

If you’re ready to try one, here are some platforms that regularly host student-friendly hackathons:

• Major League Hacking (MLH): Global student hackathons, both online and in-person.

• Devfolio: A hub for hackathons in AI, Web3, fintech, and more.

• Devpost: Popular for online hackathons with international participation.

• Hackathon.com: A global directory of upcoming events.

It’s also worth keeping an eye on hackathons run by universities, or by companies like Google and AWS. Sometimes they have student ambassadors who organize hackathons on campus, and many of these events are open globally. These can be great entry points to start building experience.

Final Thoughts

If you have never joined a hackathon, the question is simple, what do you have to lose? The answer is nothing. There are no downsides and only benefits. You gain skills, exposure, and experiences you will carry long after graduation.

Looking back, one regret I have is that I only joined a few during my four years of university. Even with the handful I did, the impact was huge. It makes me wonder how much more I could have learned and experienced if I had joined more. Every hackathon brings something new, it could be a lesson, a connection, or even an opportunity you never saw coming.

Don’t wait until you feel ready. Sign up, show up, and figure it out along the way. Your future self will thank you.

Hey there, fellow developers! Imagine this. You've just landed your first tech job or maybe you're fresh out of a coding boot camp/university. You're pumped, excited, and ready to show the world with everything you've got.

But wait a minute—ever heard of the Dunning-Kruger Effect?

No, it's not the name of a cool Unicorn company or a secret programming language. It's actually a psychological phenomenon where people think they know more than they actually do. And trust me, it's super easy to fall into this trap when you're new and eager to impress.

Why should you care? Well, this mindset can actually hold you back from truly excelling in your new role.

But fear not, we're going to dive into how you can navigate this tricky terrain and come out the other side not just confident, but truly capable of being an awesome developer.

The Excitement of the First Job

Remember the moment you saw that "Congratulations" email? Your adrenaline kicked in, your heart races, your palms got a little sweaty, and you probably did a mini happy dance (at least I did).

You felt like you had just won the lottery, and in a way, you did! You've spent a tremendous amount of effort to reach that position and finally, you're now part of the tech world.

Moving into that first week on the job, you walked into the office (or logged into that Zoom call) with your best "I'm a serious coder" face. Your new workspace is all set up – imagine your own standing desk, complete with dual monitors and a mechanical keyboard that makes the most satisfying click-clack sound.

You're given your first project or task, and you think, "Pssh, I've got this. How hard can it be?"

You're filled with excitement and ready to tackle anything that comes your way. Debugging errors? Bring it on. Complex algorithms? No problemo. You feel invincible, like a coding wizard.

But here's the thing—this is exactly where the Dunning-Kruger Effect starts to creep in. You feel like you can conquer any coding challenges thrown your way. But is that really the case? Let's find out.

_Photo by [Unsplash](https://unsplash.com/@brookecagle?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Brooke Cagle / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

The Reality Check

A couple of weeks into your job, something starts to feel... different🫤. That initial rush of "I can do anything!" starts to fade as you dive deeper into your projects.

You encounter coding problems that your bootcamp or university courses didn't expose you to. You find yourself Googling terms you've never heard of and staring at error messages that might as well be written in a completely unfamiliar language.

Remember that "simple" task you were so confident about? Well, it's not looking so simple anymore. You start to realize that the codebase is a labyrinth, and you're just a tiny mouse trying to find the cheese. You're attending meetings where people casually throw around acronyms and jargon. You nod along, but inside, you're thinking, "What are they even talking about?"

This is the moment—the reality check. It hits you like a ton of bricks: "I have so much more to learn." And let's be honest, it's a humbling experience. You might even feel a bit discouraged or overwhelmed. That coding wizard wand you were holding seems a little too weak for you now.

But hey, don't beat yourself up. Many developers face this problem including myself. It's the universe's way of saying, "Welcome to the real world of tech. It's time to level up." And guess what? This is where the real growth begins.

Why the Dunning-Kruger Effect is Actually a Good Thing

Well well well, so you've hit that reality check. You're feeling a bit down, maybe even doubting if you're cut out for this tech life.

But here's the twist: that uncomfortable feeling, that realization that you're not a coding wizard (yet), is actually a good thing. Yep, you heard me right. It's good, and here's why.

The Dunning-Kruger Effect isn't just some fancy term psychologists use to make you feel bad about yourself. It's a natural part of the learning journey. Think of it as your brain's way of saying, "Hey, slow down, buddy. There's more to see here."

When you're at the peak of "Mount Stupid" early on in your career, as shown in the image above, you don't know what you don't know. But the moment you start to doubt, the moment you feel that discomfort, is when you become aware of your limitations.

You see, the Dunning-Kruger Effect can be your wake-up call, your catalyst for genuine growth. It's like a checkpoint in a video game that says, "Are you sure you're ready for the next level?" If you are, you'll need to gear up, learn some new moves, and maybe even team up with others who can help you on your quest.

So, instead of seeing this psychological effect as a pitfall, view it as a springboard. It's a chance for you to pivot. It's your opportunity to identify the gaps in your knowledge and skills, and then hustle to fill them.

You'll start asking questions, seeking feedback, and practicing like never before. Before you know it, you'll be climbing up the slope of "enlightenment," where you not only gain expertise but also the wisdom to recognize there's always more to learn.

In a nutshell, the Dunning-Kruger Effect is not your enemy. It's more like your brutally honest friend who tells things like they are and keeps you in check, so you can become the best version of yourself.

And let's be real, we could all use a friend like that, especially when we're just starting to explore the tech world.

_Photo by [Unsplash](https://unsplash.com/@grzegorzwalczak?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Grzegorz Walczak / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Practical Tips to Overcome Overconfidence

Now you've established that the Dunning-Kruger Effect can be your ally. But how do you move from that awkward phase of overconfidence to actually getting better? Here are some down-to-earth, no-nonsense tips to help you get there.

Self-Assessment: Know Yourself

First things first, take a step back and honestly evaluate your skills. People always say that awareness is the first step to self-improvement. No sugar-coating, no inflating your abilities. Use online quizzes, coding challenges from websites like Leetcode or HackerRank, or even old-fashioned pen and paper to jot down what you know and what you don't. This will give you a clear picture of where you stand.

_Photo by [Unsplash](https://unsplash.com/@brett_jordan?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Brett Jordan / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Seek Feedback: The Mirror Doesn't Lie, But It Doesn't Tell the Whole Truth

Your own assessment is a good start, but it's not enough. You need external perspectives to get a fuller picture.

Don't be shy—ask for feedback from your colleagues, mentors, or even your local online communities. Listen carefully, keep an open mind, and don't get defensive.

Remember, feedback is a gift, even when it stings a little. Ensure to only take feedback that are directed at your skills rather than being personal in nature.

_Photo by [Unsplash](https://unsplash.com/@wocintechchat?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Christina @ wocintechchat.com / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Set SMART Goals: You Can't Improve What You Don't Track

You've probably heard of SMART goals: Specific, Measurable, Achievable, Relevant, and Time-bound. (Source: Kat Boogard) Use this framework to set targets for yourself.

Instead of vague goals like "I want to get better at JavaScript," aim for something more concrete like, "I will complete a JavaScript project that involves API calls within two weeks." or "I will learn how to integrate with Stripe API by building an e-commerce website within this month."

You can use roadmap.sh to track your progress and get a general roadmap, too.

_Photo by [Unsplash](https://unsplash.com/@kellysikkema?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Kelly Sikkema / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Break It Down: One Step at a Time

Big goals can be overwhelming, especially when you are learning something from scratch. Break them down into smaller manageable tasks that you can tackle daily (preferably) or weekly.

Each small win will not only boost your confidence and motivation to stay consistent but also give you a clearer path forward.

_Photo by [Unsplash](https://unsplash.com/@bruno_nascimento?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Bruno Nascimento / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Keep Learning: The River Never Stops Flowing

The tech world is always evolving, and so should you. Make learning a habit. Whether it's reading articles, watching tutorials, taking up new courses, or building new projects, keep that brain of yours hungry for more knowledge.

Just make sure that you show up consistently:

Reflect and Adjust: Rinse and Repeat

Every now and then, take some time to reflect on your progress. Celebrate your wins, no matter how small, and learn from your setbacks. Adjust your goals and strategies as needed and keep going. Be strict for yourself but do not beat yourself down too hard when a target is not met. Progress is progress no matter the context.

Overcoming overconfidence isn't about downplaying your abilities. It's about fine-tuning them. It's about turning that initial spark of enthusiasm into a steady flame that lights your way through the ever-changing landscape of tech. And trust me, once you get the hang of it, there's no stopping you.

_Photo by [Unsplash](https://unsplash.com/@joshuaearle?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Joshua Earle / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

The Path to Becoming Outstanding

So, what's the endgame here? Well, overcoming the Dunning-Kruger Effect isn't just about avoiding embarrassment or getting through the day without a hiccup. It's about long-term growth. It's about becoming the developer who not only knows their stuff but also knows what they don't know.

That's a powerful combo, my fellow friends. It makes you more competent, more hirable, and let's be honest, a lot more fun to work with.

_Photo by [Unsplash](https://unsplash.com/@krakenimages?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">krakenimages / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Conclusion

Alright, let's wrap this up. The Dunning-Kruger Effect is like that awkward puberty phase we all go through. It's uncomfortable, a bit embarrassing, but also completely natural.

Just like Neo in "The Matrix," you have a choice. You can take the blue pill, stay in your comfort zone, and believe whatever you want to believe. Or you can take the red pill and embrace the awkwardness, the bumps, and the steep learning curves.

Taking the red pill means acknowledging that there's a whole world of programming wisdom you've yet to discover. It's a commitment to learn, grow, and become not just a better developer, but an outstanding one.

And guess what? You've got what it takes 🫵🏻, so let's commit to excellence, one repo at a time! 📦

_Photo by [Unsplash](https://unsplash.com/@jdavydko?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Roman Davydko / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

To end on a quote:

"Don't get set into one form, adapt it and build your own, and let it grow, be like water" — Bruce Lee

Additional Resources

If you're keen on diving deeper into this topic and leveling up your skills, here are some resources that can help you on your journey:

Books 📚

1. "Mindset: The New Psychology of Success" by Carol S. Dweck - Understand the power of a growth mindset.
2. "Deep Work: Rules for Focused Success in a Distracted World" by Cal Newport - Learn how to focus and produce high-quality work.
3. "The Pragmatic Programmer" by Andrew Hunt and David Thomas - A must-read for every new developer.

Articles 📝

1. Understanding the Dunning-Kruger Effect - A Psychology Today article that breaks down the psychology.
2. How to Overcome Imposter Syndrome - A Medium article that provides actionable tips.
3. The Developer’s Edge: How To Become A Senior Developer - Hackernoon article focusing on the path to seniority.

Online Courses 🖥️

1. The Science of Well-Being by Yale University - Coursera course that can help you understand happiness and productivity.
2. Learning How to Learn - Another Coursera gem that teaches you the most efficient ways to learn new topics.

Feel free to explore these resources and take what resonates with you. Happy learning! 🌟