DEV Community: Gift Egbonyi

Why most beginner portfolios don’t get interviews (and how to fix yours)

Gift Egbonyi — Tue, 03 Feb 2026 17:40:44 +0000

Hey friends 👋🏾

Let’s be honest for a minute.

Most beginner portfolios don’t get interviews because the portfolio doesn’t communicate what recruiters actually want to see.

NB: it doesn't mean that the developer is bad

I’ve reviewed quite a few beginner portfolios and the same patterns keep showing up.

Let’s talk about them.

1️⃣ Too many cliché tutorial projects

If your portfolio is full of:

Todo apps
Weather apps
Calculator apps

…that’s not necessarily wrong.

The problem is everybody else has the same thing.

Recruiters have seen these projects hundreds of times. When they open your portfolio and see another cliché tutorial clone with no explanation, there’s nothing that makes you stand out.

How to fix it

You don’t need “unique” ideas. You need context.

For each project, answer:

Why did you build this?
What problem does it solve?
What did you learn while building it?

...a ready example is my portfolio section where I have some projects with case studies.

Even a simple app becomes interesting when you explain your thought process.

2️⃣ No explanation of decisions

Many portfolios show screenshots and links, but zero reasoning.

Recruiters aren’t just looking at what you built.
They want to know how you think.

If I see a project and can’t tell:

why you chose a certain stack
how you structured the app
what trade-offs you made

…it’s hard to judge your skill level.

How to fix it

Add short write-ups:

Why React and not something else?
Why this database?
What would you improve if you had more time?

You don’t need an essay. A few honest paragraphs would do.

3️⃣ No README (or a weak one)

This one hurts.

A missing README feels like submitting an assignment without instructions.

Or even worse, a README that says:

“This is a simple app built with React.”

That tells me nothing.

How to fix it

Your README should include:

What the app does
Who it’s for
How to run it locally
What features you’re proud of
Any known limitations

Think of it as a short conversation with the recruiter.

4️⃣ Projects are not live

If I can’t click and try your app, that’s a missed opportunity.

Most recruiters won’t clone your repo.
If there’s no live link, they’ll move on.

How to fix it

Deploy your projects.
Even basic hosting is fine.

What matters is:

The app runs
It doesn’t crash immediately
The core idea works

Perfection is not required.

5️⃣ No personality, no story

This is the mostly overlooked by a lot of beginners.

A lot of portfolios feel robotic.
No sense of who built them. No story. No voice.

But hiring is still human.

How to fix it

Add:

A short “About me” that sounds like you
Why you’re learning software engineering
What kind of problems you enjoy solving

You don’t need to overshare. Just be real.

What you should takeaway

A good beginner portfolio has:

Clear thinking
Honest communication
Showing how you approach problems

Recruiters aren’t expecting senior-level code.
They want to see how you think, not perfection.

If your portfolio tells a clear story about how you think and learn, interviews will come.

If you’re a beginner and this hit close to home, you’re not behind.
You probably just need to reframe how you present your work.

If this helped, drop a 💬 or 🧡

Connect with me on:

I share short, practical dev lessons regularly.

Follow me for more short, beginner-friendly JavaScript lessons every week.

Reach out to me for your web development gigs:
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Email: egbonyigiftvicky@gmail.com

See you next week! 🚀

Till then, write clean code and stay curious. 🦋

dilemma!

Gift Egbonyi — Thu, 22 Jan 2026 22:45:36 +0000

Heyy friends 👋🏽

I’ve been in a bit of a dilemma lately.

I can’t decide whether to keep doing tutorial-style posts like I’ve been doing, switch to more raw (unfiltered), real-life talks about my software engineering journey, or just mix both.

If my content has helped you in any way before, I’d genuinely love to hear from you on what you think.

I’m intentional about making the most of my time here. I want to share the unfiltered side of tech that people rarely talk about, while still breaking down complex concepts into something easy to grasp.

The issue is, I feel like I’ve got a lot to offer, and I’m struggling to narrow it down.
And honestly, what better way to decide than to hear directly from you?

So please, let me know your thoughts.

Connect with me on:

I share short, practical dev lessons regularly.

Follow me for more short, beginner-friendly JavaScript lessons every week.

Reach out to me for your web development gigs:
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Email: egbonyigiftvicky@gmail.com

See you next week! 🚀

Till then, write clean code and stay curious. 🦋

Don’t start with these databases as a beginner

Gift Egbonyi — Wed, 14 Jan 2026 19:45:33 +0000

Hey friends 👋

Happy New Year!

This year, we'll keep the momentum goin', so let's jump right into it!

I see many beginners jump straight into databases that add unnecessary complexity to their projects.
It usually starts well, then turns into frustration when shipping to production.

Let’s talk about two common ones.

1️⃣ PostgreSQL

PostgreSQL is powerful. No debate there.
But power comes with trade-offs that beginners often underestimate.

What usually happens:

Hosting it in production is not straightforward
Managing it without an ORM like Prisma can be stressful
Even with tools like pgAdmin, the interface is hard to navigate
Most hosting providers (Render, Railway, etc.) only offer short free periods
Once the free tier ends, you either pay or risk losing your data

Yes, Supabase exists.
But that introduces another layer you now need to learn and maintain.

For someone still learning backend basics, this is a lot.

2️⃣ SQLite

SQLite is excellent... locally.

It’s simple, fast and perfect for learning.

But in production?
It falls apart.

It’s not built for multiple concurrent users
It doesn’t handle real-world traffic well
It’s fine for demos and practice projects, not client-facing apps

Use SQLite to learn.
Don’t ship it to production for real users.

What beginners often overlook 👇🏽

As a developer, your job isn’t just to write code.

You evaluate cost, scale and trade-offs before writing a single line.

When you’re building for a client, ask yourself:

What is their budget?
Who will maintain this later?
What happens when the free tier ends?
Is this tool solving the problem, or adding complexity?

Good developers don’t chase the latest tech.
They make smart, sustainable technical decisions.

That’s what clients actually pay for.

🙋🏾‍♀️ Wrap-Up

If you’re a beginner, start simple.
There’s no prize for making your life harder than it needs to be.

That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If this helped you, leave a 💬 or 🧡
I share short, practical dev lessons like this regularly.

Follow me for more short, beginner-friendly JavaScript lessons every week.

Reach out to me for your web development gigs:
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)
Email: egbonyigiftvicky@gmail.com

See you next week! 🚀

Till then, write clean code and stay curious. 🦋

Why == and === behave differently in JavaScript

Gift Egbonyi — Fri, 12 Dec 2025 16:51:30 +0000

Hey friends! 👋

If you’ve ever compared two values and got an unexpected result, don’t worry, that happens lots of times with == and ===. JavaScript comparisons can be behave strangely until you know what’s happening behind the scenes.

I'm going to make this as simple as possible.

1️⃣ `===` → Strict equality

=== checks two things:

Are the values the same?
Are the types the same?

Both must match.

Examples:

5 === 5        // true
5 === "5"      // false
true === 1     // false
null === undefined // false

If the types don’t match, JavaScript won’t even try. It just says “nope”.

2️⃣ `==` → Loose equality

== tries to be “helpful” by converting values before comparing them.
This is called type coercion.

Examples:

5 == "5"       // true  (string → number)
true == 1      // true  (boolean → number)
false == 0     // true
null == undefined // true  (special case)

It looks helpful…
but this “helpfulness” is what leads to weird behaviour like:

"" == 0        // true
"0" == 0       // true
[] == 0        // true

You’re not meant to memorise these.
The rule is simple:

== converts. === doesn’t.

3️⃣ Why this happens

JavaScript tries to compare values with == by making them the same type first.

A few conversions that happen behind the scenes:

strings → numbers
booleans → numbers
arrays → strings
null and undefined → only equal to each other

It does all these steps automatically — which is why it gets confusing fast.

4️⃣ Which one should you use?

For beginners (and honestly, most cases), stick with:

===

It’s predictable.
It won’t surprise you.
And it forces you to know what type you’re comparing.

Use == only when you fully understand the conversion rules — or when you specifically want:

null == undefined

to be true.

5️⃣ A simple demo

Try this in your console:

console.log(0 == false);   // true
console.log(0 === false);  // false

console.log("5" == 5);     // true
console.log("5" === 5);    // false

You’ll instantly see the difference.

6️⃣ Quick summary

Comparison	Checks Type?	Converts Values?	Example
`===`	Yes	No	`"3" === 3` → false
`==`	No	Yes	`"3" == 3` → true

Short version:

=== is strict and honest.
== tries too hard.

🙋🏾‍♀️ Wrap-Up

If JavaScript comparisons have ever confused you, it’s not your fault.
The coercion rules behind == are messy.
Using === gives you cleaner logic and fewer surprises.

That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If you enjoyed this, leave a 💬 or 🧡 to let me know.

Follow me for more short, beginner-friendly JavaScript lessons every week.

I'm still hunting for full stack roles,
contract or full-time.
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)

See you next Wednesday 🚀, hopefully, on time!

Till then, write clean code and stay curious. 🦋

What happens when you type a URL into your browser?

Gift Egbonyi — Wed, 26 Nov 2025 19:40:22 +0000

Hey friends! 👋

Let’s talk about something we all do every day:

Typing a URL into your browser

In case you don’t know what a URL is: URL stands for Uniform Resource Locator. It’s basically the address of a webpage, just like your home address tells people where you live, a URL tells the internet where a page is located.

We type URLs so casually:

https://google.com

…but a lot happens behind the scenes before that page appears on your screen.

1️⃣ The browser checks the URL

Your browser first checks:

is this a valid URL?
is it HTTP or HTTPS?
which domain are we visiting?

Nothing is loaded yet, it's just making sure the link is valid.

2️⃣ It looks in the cache

Your browser asks itself:

“Have I seen this page before?”

It checks cached files like:

HTML
CSS
images
JavaScript

If it finds something fresh enough, it may skip some steps and load faster.
If not, it moves on.

3️⃣ DNS: Finding the website’s address

Computers don’t understand names like google.com.
They use IP addresses like:

142.250.187.14

So the browser asks a DNS server:

“What is the IP address for this domain?”

If the server knows, it replies with the correct address.
Now your browser knows where on the internet to go.

4️⃣ Your browser says hello to the server

Once the IP address is known, the browser reaches out to the server hosting the site using HTTP or HTTPS.

This is basically a digital handshake:

“Hi, can you send me the page for google.com?”

With HTTPS, this handshake is encrypted to keep your data safe.

5️⃣ The server sends the HTML back

If everything is fine, the server responds with:

HTML (the main file)
links to CSS, images, scripts, fonts, etc.

The browser now starts building the webpage.

6️⃣ The browser builds the page step by step

This part is called rendering, and it happens in three simple steps:

✔️ Builds the DOM

Turns HTML into a tree of elements.

✔️ Builds the CSSOM

Applies your CSS rules.

✔️ Renders everything visually

Combines both trees to draw the page.

This is how:

layouts
colours
buttons
text

all appear where they should.

7️⃣ JavaScript runs

After rendering starts, JavaScript files load.
These files:

fetch data
handle clicks
update the UI
power animations
run app logic

This is when the page becomes “interactive”.

8️⃣ The page finally appears

Once everything above is done, you see the final webpage — and the browser keeps running scripts or fetching data as needed.

All of this happens in a twinkle of an eye.

🙋🏾‍♀️ Wrap-Up

So the next time you type:

https://gift-egbonyi.onrender.com

Remember this little journey:

URL → Cache → DNS → Server → HTML → DOM → CSS → Render → JavaScript → Page.

It’s a lot of steps, but browsers make it feel instant.

That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If you enjoyed this, leave a 💬 or 🧡 to let me know.

Follow me for more short, beginner-friendly JavaScript lessons every week.

I'm still hunting for full stack roles,
contract or full-time.
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)

See you next Wednesday 🚀, hopefully, on time like today!

Till then, write clean code and stay curious. 🦋

Why you should stop writing long functions

Gift Egbonyi — Thu, 20 Nov 2025 16:18:52 +0000

Hey friends! 👋

Let’s talk about something every beginner struggles with:

Why you should stop writing long functions and how to break them into smaller ones

Long functions feel "easy" when you're starting out.
You want the code to work, and you don't understand how to break them into smaller functions, or in what order to call these small functions, so everything goes into one place.

But over time, those bulky functions turn into:

untraceable bugs
code that’s hard to read
features that are difficult to update
unnecessary stress

Smaller functions make your code cleaner and easier to reason about.

This is what I mean.

1️⃣ Long functions hide mistakes

Take this example:

const processUser = (data) => {
  // Validate
  if (!data.email.includes("@")) throw new Error("Invalid email");

  // Format
  const name = data.name.trim().toUpperCase();

  // Save
  localStorage.setItem("user", JSON.stringify({ name, email: data.email }));

  // Notify
  alert("User saved!");
}

It works.
But it mixes validation, formatting, saving and notifications features in one place.
If something breaks, you probably mightn't spot the issue very fast.

2️⃣ Smaller functions focus on one job

Now, let’s split it:

const validateUser = (data) => {
  if (!data.email.includes("@")) throw new Error("Invalid email");
}

const formatUser = (data) => {
  return {
    name: data.name.trim().toUpperCase(),
    email: data.email
  };
}

const saveUser = (user) => {
  localStorage.setItem("user", JSON.stringify(user));
}

const notify = () => {
  alert("User saved!");
}

const processUser = (data) => {
  validateUser(data);
  const user = formatUser(data);
  saveUser(user);
  notify();
}

Now you can see exactly what’s happening at a glance.

3️⃣ Smaller functions make testing easier

Which one would you rather test?

This?

processUser({ name: "Gift", email: "gift@gmail.com" });

or these?

validateUser(data);
formatUser(data);
// etc.

Why experts like short functions that focus on one feature:

let you test one idea at a time.
spot bugs earlier.
other developers can easily read your code,
helpful when you use a JavaScript framework like React.js which is components based.
helpful in next.js.

4️⃣ I promise, your future self will thank you!

Readable code isn’t for others alone.
It’s for you in two months when you no longer remember what you wrote.

Splitting functions forces you to:

name things clearly
structure your logic
avoid hidden behaviours

It’s a habit that pays off quickly.

How to break a long function into smaller pieces

A simple approach:

✔️ Step 1: Look for sections that do different jobs

Validation, fetching, formatting, rendering and separate them.

✔️ Step 2: Extract each section into its own function

Give each one a short, clear name.

✔️ Step 3: Keep each function focused

One idea per function.
If a function starts doing two things, break it again.

✔️ Step 4: Call them in order

Your main function becomes a clean “storyline”.

Quick before/after

❌ Before

One big block:

function checkout(cart) {
  // validate
  // calculate
  // update UI
  // save to server
}

✔️ After

Small clear steps:

const validateCart = (cart) => {}
const calculateTotal = (cart) => {}
const updateUI = (total) => {}
const saveToServer = (cart) => {}

const checkout = (cart) => {
  validateCart(cart);
  const total = calculateTotal(cart);
  updateUI(total);
  saveToServer(cart);
}

Much easier to maintain.

🙋🏾‍♀️ Wrap-Up

Short functions make your code:

cleaner
easier to debug
painless to update
easier for other developers to read
kinder on your future self

Start small. Refactor bit by bit.
Your codebase and your future self will thank you.
That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If you enjoyed this, leave a 💬 or 🧡 to let me know.

Follow me for more short, beginner-friendly JavaScript lessons every week.

I'm still hunting for full stack roles,
contract or full-time.
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)

See you next Wednesday 🚀, hopefully, on time!

Till then, write clean code and stay curious. 🦋

What happens when you type console.log()?

Gift Egbonyi — Fri, 14 Nov 2025 20:45:43 +0000

Hey friends! 👋

Two days late! I'm not nailing this adulting as I should fr. I missed our usual Wednesday hangout, but with just reason ofcourse. I won't bore you with the details, so here’s a quick, light tutorial to make it up.

We always write:

console.log("Hello world!");

…but have you ever wondered what actually happens when that line runs?

Let’s break it down in a simple way.

What Happens When You Type `console.log()`?

JavaScript doesn’t magically push text onto the screen. A few things happen behind the scenes, fast enough that we don’t notice.

Here’s the journey.

1️⃣ Your code gets parsed

Before anything runs, the browser checks your code for:

valid syntax
correct placement of parentheses
missing commas
stray characters

If all is fine, it creates something called the execution context.
(Think of it as preparing the environment.)

2️⃣ JavaScript reaches the `.log()` call

When execution gets to your line:

console.log("Hello");

JavaScript doesn’t print anything itself.
Instead, it sees:

console → an object provided by the browser
log → a method inside that object
"Hello" → the argument you’re sending

3️⃣ The browser steps in

The console object isn’t part of JavaScript.
It’s provided by your browser (Chrome, Firefox, Safari, etc.) through the Web APIs.

When you call:

console.log("Hello");

You’re basically saying:

“Browser, please take this value and show it in your developer tools.”

4️⃣ The browser forwards the text to the DevTools console

Your browser receives "Hello" and pushes it into the DevTools output area.

That’s why you can customise the console, clear it, filter logs, and change colours — it’s the browser doing the work, not JavaScript.

5️⃣ The call completes

The log() method finishes and returns undefined.
(That’s why running console.log(console.log("Hi")) prints Hi and then undefined.)

Why do I even need this information?

Well, understanding this tiny journey helps beginners:

see the difference between JavaScript and browser features
understand why console.log() behaves differently in Node.js
avoid thinking the console is part of the core language
debug smarter

Try this out

Open your browser console and run:

console.log({ name: "Gift", age: 22 });

You’ll notice you can:

expand the object
inspect properties
view it in different formats

That’s the browser again not JavaScript.

🙋🏾‍♀️ Wrap-Up

So the next time you type:

console.log("testing…");

You’ll know the journey:

Parse → Execute → Browser handles it → DevTools prints it.

Small detail.
But...
Nice to know.

That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If you enjoyed this, leave a 💬 or 🧡 to let me know.

Follow me for more short, beginner-friendly JavaScript lessons every week.

I'm still hunting for full stack roles,
contract or full-time.
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)

See you next Wednesday 🚀, hopefully, on time!

Till then, write clean code and stay curious. 🦋

Understanding the `this` Keyword in JavaScript

Gift Egbonyi — Wed, 05 Nov 2025 18:45:26 +0000

Hey friends! 👋

It’s another Wednesday, and yes, we’re still learning JavaScript together!

Today’s topic is one that confuses almost everyone when they first start out: the this keyword.

Let’s simplify it and see how it works using a live demo.

What is `this`?

this refers to the object that owns the code being executed.
But what that means depends on how and where you use it.

Let’s look at 4 common places you’ll see this in action.

1️⃣ In the Global Scope

In browsers, this in the global scope refers to the window object.

console.log(this); // window

2️⃣ Inside an Object Method

When this is used inside a method, it refers to the object that owns the method.

const person = {
  name: "Gifty",
  greet() {
    console.log("Hi, I'm " + this.name);
  },
};

person.greet(); // "Hi, I'm Gifty"

3️⃣ Inside a Regular Function

If you use this inside a normal function (not part of an object),
this will be undefined in strict mode — or window in non-strict mode.

function showThis() {
  console.log(this);
}

showThis(); // undefined (in strict mode)

4️⃣ Inside an Arrow Function

Arrow functions don’t have their own this.
They inherit this from where they were created.

const obj = {
  name: "GiftySoftDev",
  arrow: () => {
    console.log(this.name); // undefined
  },
  regular() {
    console.log(this.name); // "GiftySoftDev"
  },
};

obj.arrow();
obj.regular();

🧑‍💻 CodePen Demo

Play with this

We’ll build a mini visualiser that lets you click buttons to see what this refers to in each context.

HTML

<div class="container">
  <h2>JavaScript "this" Visualiser</h2>
  <p>Click the buttons below to see what <code>this</code> refers to!</p>

  <button id="globalBtn">Global Scope</button>
  <button id="methodBtn">Object Method</button>
  <button id="regularBtn">Regular Function</button>
  <button id="arrowBtn">Arrow Function</button>
  <button id="eventBtn">Event Listener</button>

  <div id="output" class="output">Click a button to see the result 👇</div>
</div>

CSS

body {
  font-family: system-ui, sans-serif;
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh;
  background: #f7f7f7;
}

.container {
  background: white;
  padding: 20px 30px;
  border-radius: 10px;
  text-align: center;
  box-shadow: 0 4px 10px rgba(0,0,0,0.1);
}

button {
  margin: 5px;
  padding: 8px 14px;
  border: none;
  border-radius: 6px;
  cursor: pointer;
  background: #4f46e5;
  color: white;
  font-size: 14px;
}

button:hover {
  background: #4338ca;
}

.output {
  margin-top: 20px;
  padding: 15px;
  border: 1px dashed #ccc;
  border-radius: 8px;
  background: #fafafa;
  font-family: monospace;
}

JavaScript

const output = document.getElementById("output");

function logResult(label, value) {
  output.textContent = `${label}: ${value}`;
}

// Global scope
document.getElementById("globalBtn").addEventListener("click", function() {
  logResult("Global this", this === window ? "window" : this);
});

// Object method
document.getElementById("methodBtn").addEventListener("click", function() {
  const user = {
    name: "Gifty",
    sayName() {
      logResult("Object Method", this.name);
    },
  };
  user.sayName();
});

// Regular function
document.getElementById("regularBtn").addEventListener("click", function() {
  function showThis() {
    logResult("Regular Function", this === window ? "window" : this);
  }
  showThis();
});

// Arrow function
document.getElementById("arrowBtn").addEventListener("click", function() {
  const arrow = () => logResult("Arrow Function", this === window ? "window" : this);
  arrow();
});

// Event listener
document.getElementById("eventBtn").addEventListener("click", function() {
  logResult("Event Listener", `this is the button with text: "${this.textContent}"`);
});

How the Demo Works

Global Scope: this → window
Object Method: this → the object (user)
Regular Function: this → undefined (in strict mode)
Arrow Function: this → the outer context (inherits)
Event Listener: this → the element that triggered the event

👉 Try it on CodePen

🙋🏾‍♀️ Wrap-Up

this can be tricky — but once you understand how it’s set depending on where and how a function runs, it starts to make sense.

Here’s a quick summary:

Context	`this` refers to
Global scope	`window`
Object method	The object
Regular function	`undefined` (strict mode)
Arrow function	Inherits from outer scope
Event listener	The element clicked

That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If you enjoyed this, leave a 💬 or 🧡 to let me know.

Follow me for more short, beginner-friendly JavaScript lessons every week.

I'm still hunting for full stack roles,
contract or full-time.
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)

See you next Wednesday 🚀, on time!

Till then, write clean code and stay curious. 🦋

Understanding JavaScript Closures

Gift Egbonyi — Thu, 30 Oct 2025 14:16:49 +0000

Hey friends! 👋

I couldn't make it yesterday and I feel sad about that 😔. I lost a relative so I was at her wake. But I'm here today :)

Today is closures, one of those concepts that seems a bit complex but actually very practical once you see it in action.

Closures occur when a function remembers variables from its outer scope, even after that outer function has finished running.

Example 1: Basic Closure

function greet(name) {
  const greeting = 'Hello';
  return function() {
    console.log(`${greeting}, ${name}!`);
  }
}

const sayHello = greet('Alice');
sayHello(); // "Hello, Alice!"

Here’s what’s happening:

greet('Alice') returns a function.
That returned function remembers the variables greeting and name.
Even though greet has finished executing, sayHello() still works.

Example 2: Counter with Closure

Closures are perfect for keeping private variables.

function createCounter() {
  let count = 0;
  return function() {
    count++;
    return count;
  }
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

count is private. You can’t access it directly from outside.
Each call remembers the previous value.

Example 3: Real-World Use Case

function makeMultiplier(x) {
  return function(y) {
    return x * y;
  }
}

const double = makeMultiplier(2);
const triple = makeMultiplier(3);

console.log(double(5)); // 10
console.log(triple(5)); // 15

Closures let us create flexible and reusable functions.

Here is a Challenge for You

No codepen today but can you answer the question below?

function secretPassword(password) {
  return function(guess) {
    return guess === password ? 'Access granted' : 'Access denied';
  }
}

const checkPassword = secretPassword('1234');
console.log(checkPassword('0000')); // ?
console.log(checkPassword('1234')); // ?

“Why does this work even though secretPassword has finished running?”

🙋🏾‍♀️ Wrap-Up

A closure is a function remembering its scope even after execution.
Useful for private data, partial application, and factory functions.
Always think: “Which variables does this function remember?”

That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If you enjoyed this, leave a 💬 or 🧡 to let me know.

Follow me for more short, beginner-friendly JavaScript lessons every week.

I'm still hunting for full stack roles,
contract or full-time.
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)

See you next Wednesday 🚀, on time!

Till then, write clean code and stay curious. 🦋

Understanding Time vs Space Complexity: Why You Can’t Always Optimise Both

Gift Egbonyi — Wed, 22 Oct 2025 14:38:08 +0000

Hey friends! 👋

I'm excited to be on time for our date! I’ve been working on my time management lately, and one thing that helps is turning on Work Mode on my iPhone. It keeps me focused on things like this. :)

Last few Wednesdays, we looked at running time and space complexity separately.
Today, let’s see how they interact.

Sometimes, you can make your program faster by using more memory.
Other times, you can save memory, but it’ll take longer to run.

That’s the time–space trade-off.

⚖️ Examples of the Trade-Off

i. Faster at the cost of memory

// Precompute squares (uses more memory)
const squares = Array.from({length: 1000}, (_, i) => i * i);

// Accessing a square is O(1)
console.log(squares[500]); // super fast

Time: O(1) (instant lookup)
Space: O(n) (stored 1000 numbers)

ii. Less memory at the cost of time

// Compute squares on the fly (uses less memory)
function getSquare(n) {
  return n * n;
}

console.log(getSquare(500)); // slower for repeated lookups

Time: O(1) per calculation, but repeated calls take longer overall
Space: O(1) (no array stored)

The takeaway

There’s no perfect balance.
Faster algorithms often use extra memory.
Memory-efficient ones might run slower.
Knowing both helps you make smarter design choices.

🧑🏾‍💻 Visualise It: CodePen Demo

We’ll build a simple chart to show the trade-off:

Precomputed array → fast but memory-hungry
On-the-fly computation → slower but light on memory

Move the slider to change the input size, and watch how the chart updates.
Hit Reset to start again.

👉 Time vs Space Visualiser (CodePen)

How It Works

Blue line: Precomputed squares — fast, but memory increases with n.
Green line: On-the-fly — slower, minimal memory use.
Yellow line: Memory usage for the precomputed array.

🙋🏾‍♀️ Wrap-Up

Complexity	Meaning	Example usage
O(1)	Constant space	Simple maths or fixed variables
O(n)	Grows with input	Building an array or list
O(n²)	Grows faster	Nested loops creating data

That’s it for today!
What should we talk about next Wednesday? Drop it below 👇

Connect with me on GitHub

Was this tutorial helpful? Got questions? Drop them in the 💬, I love feedback.

I’m keeping these light, fun, and useful, one small project at a time.
If you enjoyed this, leave a 💬 or 🧡 to let me know.

Follow me for more short, beginner-friendly JavaScript lessons every week.

I'm still hunting for full stack roles,
contract or full-time.
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

Portfolio

Web trails:
LinkedIn | X (Twitter)

See you next Wednesday 🚀, on time!

Till then, write clean code and stay curious. 🦋

Understanding Space Complexity

Gift Egbonyi — Wed, 15 Oct 2025 21:54:59 +0000

Hey friends! 👋

Better late than never right? :)

Last week, we talked about running time which is how fast your program runs.
This week, let’s look at its quieter sibling: space complexity which is how much memory your program uses.

When you write code, it doesn’t just take time to run; it also takes memory to store variables, data structures and temporary values.
Sometimes your program runs fast but eats up too much memory. That’s where space complexity comes in.

What’s Space Complexity?

It’s the total amount of memory a program needs to complete its work.
That includes:

Variables and constants
Function call stack
Data structures like arrays, objects, or linked lists

You’ll often see it written like O(n), just like time complexity but here, it means memory grows with input size.

Example 1: Constant Space (O(1))

function sum(a, b) {
  return a + b; // only stores a, b, and result
}

No matter how big your input is, this function uses the same small amount of memory.

Example 2: Linear Space (O(n))

function makeArray(n) {
  const arr = [];
  for (let i = 0; i < n; i++) {
    arr.push(i);
  }
  return arr;
}

Here, memory grows with the array size.
If n = 10, it stores 10 numbers.
If n = 10,000, it stores 10,000 numbers. That’s O(n) space.

Why It's Relevant

Imagine running an app on a cheap phone.
If your algorithm keeps duplicating arrays or creating new objects in loops, it might crash or slow down — even if it’s fast in theory.

Understanding space complexity helps you write code that’s both efficient and scalable.

Try It Out Yourself

How It Works

Select an algorithm type (O(1), O(n), or O(n²)).
Click Run Test.
The chart plots how “memory usage” grows as input size increases. It’s a simulation — not real browser memory — but the pattern matches what happens in real programs.

Try Tweaking It

In the JavaScript panel, find:

const sizes = [10, 100, 500, 1000, 2000];

Change it to:

const sizes = [100, 1000, 5000, 10000];

Then Run Test again and watch how the curve changes.
The quadratic one will skyrocket.

👉 CodePen link: Space Complexity Visualiser

🙋🏽‍♀️ Wrap up!

Summary

Complexity	Meaning	Example
O(1)	Constant space	Simple math or fixed variables
O(n)	Grows with input	Building an array or list
O(n²)	Grows faster	Nested loops creating data

That’s it for today!
Next Wednesday, we’ll look at how time and space complexity work together and why you can’t always optimise both at once.

Till then, write clean code and stay curious!

Connect with me on GitHub

Was this tutorial helpful? Got questions? Or any insight to help me write better tutorials? Let me know in the 💬!

That’s it for today’s midweek mini tutorial!

I’m keeping things light, fun and useful; one small project at a time.

If you enjoyed this, leave a 💬 or 🧡 to let me know.

And if you’ve got an idea for something you'd like me to try out next Wednesday, drop it in the comments. 👇

Follow me to see more straight-forward and short tutorials like this :)

I'm still hunting for full stack roles,
contract or fulltime. 
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

:-)

Portfolio

Web trails
You can also find me here on LinkedIn
or here X (Twitter)

✍🏾 I’m documenting my learning loudly every Wednesday. Follow along if you're learning JavaScript too!
Let’s keep learning together!

See you, ~~same time~~, next Wednesday🚀

🕒 Running Time Wednesday! Understanding Big O (Made Simple)

Gift Egbonyi — Wed, 08 Oct 2025 17:53:01 +0000

It’s Running Time Wednesday!

Hey friends 👋

Like I stated last week, today, we are learning something that every developer should understand — running time, also known as Big O notation.

It sounds fancy, but it’s just a way to measure how fast (or slow) your code runs as your input grows.

Let’s break it down.

What’s Running Time?

Running time tells you how the performance of your code changes as the amount of data increases.

For example, sorting 10 items is quick. Sorting 10, 000 items? That’s where efficiency comes into play.

So, Big O helps you predict how your program behaves when things scale (up or down).

Why “Big O”?

“Big O” describes the order of growth, in essence, how the number of operations grows compared to the size of the input (n).

We’re not counting seconds; we’re counting how many steps your algorithm takes as n increases.

Common Big O Notations

Notation	Name	Description	Example
O(1)	Constant time	Doesn’t depend on input size	Accessing an element by index
O(log n)	Logarithmic	Grows slowly as input increases	Binary search
O(n)	Linear	Grows directly with input	Looping through an array
O(n log n)	Linearithmic	Common in efficient sorting	Merge sort, quicksort
O(n²)	Quadratic	Grows fast with nested loops	Comparing every pair in a list
O(2ⁿ)	Exponential	Doubles with every new element	Recursive Fibonacci
O(n!)	Factorial	Blows up quickly	Generating all permutations

Quick Examples

1️⃣ O(1) — Constant

function getFirst(arr) {
  return arr[0]; // One step, no matter how big arr is
}

2️⃣ O(n) — Linear

function printAll(arr) {
  for (let item of arr) console.log(item);
  // Takes more time as arr grows
}

3️⃣ O(n²) — Quadratic

function printPairs(arr) {
  for (let i of arr) {
    for (let j of arr) {
      console.log(i, j);
    }
  }
  // For 10 items = 100 operations
}

Visualising Growth

O(1)     → constant line
O(log n) → slow curve
O(n)     → steady climb
O(n²)    → sharp rise
O(2ⁿ)    → rocket 🚀

You don’t need maths to get it — just imagine how the number of steps go up for larger inputs.

Try It Yourself in CodePen

👉 Play with Running Time Examples

Pick a function type – O(1), O(n), or O(n²)
Click “Run Test.” The chart shows how long each one takes for different array sizes.

Constant time stays flat, linear grows steadily, and quadratic shoots up fast.

Try tweaking it
In the JavaScript panel, find this line:

const sizes = [100, 500, 1000, 2000];

Change it to something bigger:

const sizes = [1000, 5000, 10000, 20000];

Then click Run again.
You’ll see the chart climb faster — that’s how running time scales with data.

🙋🏽‍♀️ Wrap up!

Here’s the takeaway:

Running time = how your algorithm scales (go up or down).
Think of Big O as a way to predict how an algorithm will handle a huge amount of data. It's about growth, not how fast it runs right now.
Aim for O(1) or O(log n) when possible, but clarity comes first.

Next Wednesday, we’ll connect this to space complexity, that is, how much memory your program uses.

Till then, write clean code and stay curious!

Connect with me on GitHub

Was this tutorial helpful? Got questions? Or any insight to help me write better tutorials? Let me know in the 💬!

That’s it for today’s midweek mini tutorial!

I’m keeping things light, fun and useful; one small project at a time.

If you enjoyed this, leave a 💬 or 🧡 to let me know.

And if you’ve got an idea for something you'd like me to try out next Wednesday, drop it in the comments. 👇

Follow me to see more straight-forward and short tutorials like this :)

I'm still hunting for full stack roles,
contract or fulltime. 
Please check out my [Portfolio](https://gift-egbonyi.onrender.com)

:-)

Portfolio

Web trails
You can also find me here on LinkedIn
or here X (Twitter)

✍🏾 I’m documenting my learning loudly every Wednesday. Follow along if you're learning JavaScript too!
Let’s keep learning together!

See you, same time, next Wednesday🚀

DEV Community: Gift Egbonyi

Why most beginner portfolios don’t get interviews (and how to fix yours)

1️⃣ Too many cliché tutorial projects

How to fix it

2️⃣ No explanation of decisions

How to fix it

3️⃣ No README (or a weak one)

How to fix it

4️⃣ Projects are not live

How to fix it

5️⃣ No personality, no story

How to fix it

What you should takeaway

dilemma!

Don’t start with these databases as a beginner

1️⃣ PostgreSQL

2️⃣ SQLite

What beginners often overlook 👇🏽

🙋🏾‍♀️ Wrap-Up

Why == and === behave differently in JavaScript

1️⃣ === → Strict equality

2️⃣ == → Loose equality

3️⃣ Why this happens

4️⃣ Which one should you use?

5️⃣ A simple demo

6️⃣ Quick summary

🙋🏾‍♀️ Wrap-Up

What happens when you type a URL into your browser?

1️⃣ The browser checks the URL

2️⃣ It looks in the cache

3️⃣ DNS: Finding the website’s address

4️⃣ Your browser says hello to the server

5️⃣ The server sends the HTML back

6️⃣ The browser builds the page step by step

✔️ Builds the DOM

✔️ Builds the CSSOM

✔️ Renders everything visually

7️⃣ JavaScript runs

8️⃣ The page finally appears

🙋🏾‍♀️ Wrap-Up

Why you should stop writing long functions

1️⃣ Long functions hide mistakes

2️⃣ Smaller functions focus on one job

3️⃣ Smaller functions make testing easier

4️⃣ I promise, your future self will thank you!

How to break a long function into smaller pieces

✔️ Step 1: Look for sections that do different jobs

✔️ Step 2: Extract each section into its own function

✔️ Step 3: Keep each function focused

✔️ Step 4: Call them in order

Quick before/after

❌ Before

✔️ After

🙋🏾‍♀️ Wrap-Up

What happens when you type console.log()?

What Happens When You Type console.log()?

1️⃣ Your code gets parsed

2️⃣ JavaScript reaches the .log() call

3️⃣ The browser steps in

4️⃣ The browser forwards the text to the DevTools console

5️⃣ The call completes

Why do I even need this information?

Try this out

🙋🏾‍♀️ Wrap-Up

Understanding the `this` Keyword in JavaScript

What is this?

1️⃣ In the Global Scope

2️⃣ Inside an Object Method

3️⃣ Inside a Regular Function

4️⃣ Inside an Arrow Function

🧑‍💻 CodePen Demo

HTML

CSS

JavaScript

How the Demo Works

🙋🏾‍♀️ Wrap-Up

Understanding JavaScript Closures

Example 1: Basic Closure

Example 2: Counter with Closure

Example 3: Real-World Use Case

1️⃣ `===` → Strict equality

2️⃣ `==` → Loose equality

What Happens When You Type `console.log()`?

2️⃣ JavaScript reaches the `.log()` call

What is `this`?