That is the moment most of us realise console.log was never a logging system. It was a debugging tool we accidentally shipped to production.

In this post we'll swap it for Pino, a logging library that writes one JSON object per line instead of loose strings. We'll install it, make the output readable while we develop, pull it into a single shared logger module, and thread one id through an entire workflow so a request is easy to follow. We're using pino 10.3.1, pino-pretty 13.1.3 and Next.js 16.3.1, and the outputs below are all copied straight from a real terminal.

Where console.log runs out#

console.log is fine right up until someone else has to read what it wrote. Then a few problems show up at once.

The levels don't actually do anything. You might reasonably point out that console already has debug, info, warn and error, and it does. But in Node, those are mostly just different methods. There is no log level threshold you can configure. They all print.

That means a message you only needed while debugging and a message that means "payments are down" can both end up in production. The only way to silence the first one is to remove the line or add your own condition.

Node does make one distinction: warn and error write to stderr, while debug, info and log write to stdout. That's two output streams, not a useful logging hierarchy.

There are also no timestamps on regular log entries, so you can't tell whether two lines happened a millisecond apart or ten minutes apart. console.time() and console.timeEnd() can measure how long a particular operation takes, but that's different from automatically recording when each log entry happened.

And there is no structure. Something like console.log('user', id, 'took', ms) produces a sentence. A sentence is fine for a human reading a terminal, but it isn't very useful when you need to filter, group, or search your logs.

And that's the part that really hurts in production: searchability.

Your hosting provider gives you a search box. You type the user ID you're investigating and expect to find every related log entry. But your ID is buried inside a string with spaces and other text around it. There's no field saying userId that the logging system can reliably filter on.

If you'd like a nudge to stop reaching for it, the pre-commit hook setup in our Husky post includes a check that blocks any commit containing a console.log, which pairs nicely with actually having something better to replace it with.

What Pino gives you instead#

Pino writes one JSON object per line. That format has a name, NDJSON (newline-delimited JSON), and most log platforms know how to parse it out of the box.

Each line carries a numeric level, a timestamp, the process ID, the hostname and your message. Anything extra you attach becomes a real field, not part of a sentence. So "find me every warning for user 42 in the last hour" becomes a filter rather than a grep that you have to squint at.

But isn't building JSON slower than printing a string, you might wonder? It is a fair question, and the answer is the reason Pino exists. Most logging libraries format a message: they take a template, interpolate values into it, apply colours, and pad columns, all before anything gets written. Pino serialises instead. It turns your object into a JSON string with as little work as possible and pushes it to stdout, leaving the prettifying to a separate process that only runs when you ask for it. Less work per line means logging costs you less inside a hot request path. ⚡

Installing Pino and writing the first log#

Let's install it. In your Next.js project, run:

npm install pino

That is the only package you need for production. We'll add pino-pretty shortly, but that one belongs in dev dependencies, so we'll keep them separate on purpose.

If you're on TypeScript, and these days most Next.js projects are, you do not need a types package. Pino ships its own type definitions inside the package. @types/pino does exist on npm, but it is only a stub whose description literally says that pino provides its own definitions, so installing it gains you nothing. Every snippet below typechecks under strict as it stands.

Now the smallest possible logger. The question that trips people up here is where do I actually put this, so let's be concrete: it has to be a file that runs on the server. The quickest way to see a real line of output is a route handler, so create src/app/api/health/route.ts:

import pino from 'pino';

const log = pino();

export async function GET() {
  log.info('health check requested');
  return Response.json({ ok: true });
}

Start your app with npm run dev, then visit http://localhost:3000/api/health.

Now look in the terminal where npm run dev is running, not the browser console. This catches nearly everyone once: log.info runs on the server, so its output goes to the server's stdout. Nothing appears in your browser devtools, and that is correct behaviour rather than a broken setup.

We'll move this logger into its own module in a moment, so treat the route handler as a place to see it work rather than where it lives permanently.

That is the whole setup. pino() with no arguments creates a logger with all the defaults, and log.info(...) writes a line at the info level. Here is what came out in the terminal, with the pid and hostname values swapped for neutral ones since yours will differ anyway:

{"level":30,"time":1787040941389,"pid":71541,"hostname":"my-laptop.local","msg":"health check requested"}

Let's read that line field by field, because every log you write from now on has this shape.

• level is 30, which is Pino's numeric code for info.
• time is a Unix timestamp in milliseconds. It is not pretty, but it is unambiguous, and every log platform converts it for you.
• pid and hostname tell you which copy of your app wrote the line. pid is the process ID, a number the operating system hands to every running program, and hostname is the machine it ran on. While you're developing there is only one copy, so both look like noise. They start earning their place the moment several copies run at the same time, whether that's a cluster of processes on one server or containers spread across several, because then they are the only thing telling you which copy produced the entry you're staring at.
• msg is the string you passed in.

And if your reaction to "level":30 is that a number is a lot less readable than the word info, you are completely right. The same goes for a timestamp like 1787040941389, which no human reads at a glance. Nobody stares at raw JSON like this while developing, and you won't have to either. We'll fix exactly that in a couple of minutes with a tool called pino-pretty, so let the ugly version stand for now. It is ugly on purpose, because this is the shape a log platform wants to receive, not the shape you read.

The log levels, and which one to reach for#

Pino ships six levels, each with a number attached:

The default level is info, and this is the part beginners get caught by. Anything below 30 is silently dropped.

Let's prove that in the route handler we already have, by adding a debug line above the info one:

export async function GET() {
  log.debug('starting health check');
  log.info('health check requested');
  return Response.json({ ok: true });
}

Refresh /api/health and only one line comes back:

{"level":30,"time":1787040941389,"pid":71541,"hostname":"my-laptop.local","msg":"health check requested"}

The debug call ran perfectly well. It just went nowhere. Not an error, not a warning. Nothing. Your logger is working exactly as designed, because you asked it for a level it was told to ignore. We'll turn that dial with an environment variable further down, and this line will come back without you editing the file again.

Adding context: the object-first argument#

A health check is a thin example, because nothing about it ever varies. Every request logs the same sentence. So let's move somewhere the values actually change and keep building there: a route that looks up an order by id, at src/app/api/orders/route.ts.

The single habit that makes Pino worth the install is passing an object before the message:

import pino from 'pino';

const log = pino();

export async function GET(request: Request) {
  const orderId = new URL(request.url).searchParams.get('id') ?? 'unknown';
  const startedAt = Date.now();

  // stand-in for whatever your real lookup does
  await new Promise((resolve) => setTimeout(resolve, 120));

  const durationMs = Date.now() - startedAt;

  log.info({ orderId, durationMs }, 'order loaded');

  return Response.json({ id: orderId });
}

Notice the order: object first, string second. Visit /api/orders?id=8842 and that object gets merged into the top level of the JSON line:

{"level":30,"time":1787042421780,"pid":80250,"hostname":"my-laptop.local","orderId":"8842","durationMs":120,"msg":"order loaded"}

orderId and durationMs are now fields. Not text buried inside msg, but real keys with real values. That means your log platform can offer you "filter where orderId = 8842" or "show me every request over 500ms", and it means each value keeps its type, so 120 is a number you can compare against rather than the characters 1, 2 and 0.

Compare it with what most of us write out of habit:

// Don't do this
log.info(`order ${orderId} loaded in ${durationMs}ms`);

That produces "msg":"order 8842 loaded in 120ms". To find the slow ones you now have to match a substring, and the moment you reword the message, every saved search and every alert built on top of it quietly stops matching. Keep the message a constant string and put the variable parts in the object. That one rule is most of the benefit.

Making it readable while you develop#

Structured JSON is superb for machines and rough on human eyes. That's what pino-pretty is for.

npm install --save-dev pino-pretty

There are two ways to wire it up, and they are not equivalent.

The first way is piping. Leave your logger untouched and send the output through the pino-pretty binary:

next dev | npx pino-pretty

Which turns those JSON lines into this:

[11:50:21.717] INFO (82862): order loaded
    orderId: "8842"
    durationMs: 120

Readable timestamp, the level spelled out and colour-coded, and your extra fields indented underneath. Your app never knows any of this happened. It is still writing plain JSON to stdout, and a separate process is doing the formatting.

The second way is a transport, configured on the logger itself. That means passing an option to the pino() call in your route handler for now, though in the next section we'll move this into a single shared logger file where it really belongs:

const log = pino({
  transport:
    process.env.NODE_ENV !== 'production'
      ? { target: 'pino-pretty', options: { colorize: true } }
      : undefined,
});

The transport option tells Pino to hand each line to a worker thread running pino-pretty. The isDev guard is doing real work here: in production you want raw JSON, because your host is going to parse it.

So which one? Here's the tradeoff:

Piping is the safer default, and it has a bonus: it prettifies everything on stdout, including Next.js's own startup lines. The transport wins when you can't control how the app is started, like a hosted dev environment or a script someone else owns.

For what it's worth, I went with the piping. This was my first time setting Pino up, and I did not fancy walking into surprises on day one.

And we are not finished with this setup. What we have works, but the structure is still rough around the edges: the logger is created inside a route file, and every route that wants to log has to build its own. We'll tidy that up as we go, so treat what follows as improvements to this same setup rather than a fresh start.

One logger module, not one per file#

Your instinct will be to call pino() wherever you need to log. Resist it. 🙂

A Pino logger holds a write stream, and if a transport is configured it holds a worker thread too. Creating a fresh one inside a route handler means building all of that on every single request, then throwing it away. And if a transport is involved, that's a thread spawned per request, which is a genuinely expensive way to write a line of text.

So we create it once. Make a file at src/lib/logger.ts, which is where it will live from now on:

import pino from 'pino';

export const logger = pino({
  level: process.env.LOG_LEVEL || 'info',
  base: { env: process.env.NODE_ENV },
});

You don't have to annotate the return type. Pino infers it, and hovering logger in your editor shows Logger<never, boolean>, which is the type you'd import as Logger from pino if you ever need to write it down (passing the logger into a helper function, for instance).

Two options in there. level reads from an environment variable with a sensible fallback, which we'll come back to. base replaces the default pid and hostname fields with whatever you give it. Here we're tagging every line with the environment, so staging and production logs are told apart at a glance.

Then everywhere else you import it:

import { logger } from '@/lib/logger';

export async function GET(request: Request) {
  const orderId = new URL(request.url).searchParams.get('id') ?? 'unknown';

  logger.info({ orderId }, 'order loaded');

  return Response.json({ id: orderId });
}

Child loggers, when you want context to stick#

Once you have the singleton, you can branch off it. A child logger carries fields automatically so you stop repeating yourself:

const requestLog = logger.child({ requestId });

requestLog.info('started');
requestLog.info({ ms: 42 }, 'finished');

Both lines carry requestId without you passing it twice. A child is cheap, because it shares the parent's stream rather than opening a new one, so this is the right way to add per-request context, and the wrong way is a fresh pino() call.

That per-request use is the one most people reach for first. There is a second one that pays off just as much, though, and it is worth knowing about early: labelling whole areas of your app. If your codebase has invoicing, payments and ordering, give each of them a child logger and create it once, next to the singleton:

// src/lib/logger.ts
export const paymentsLog = logger.child({ module: 'payments' });
export const ordersLog = logger.child({ module: 'orders' });

Every line those write now carries its label, without a single extra argument at the call site:

{"level":30,...,"module":"payments","msg":"charge captured"}
{"level":40,...,"module":"orders","orderId":"8842","msg":"stock low"}

Which turns "show me everything payments did this morning" into a filter on one field, rather than you trying to remember which messages the payments code happens to use. It also survives refactors, because the label lives in the logger rather than in the wording of each message.

The two uses stack, which is where this gets genuinely useful. Branch a per-request child off a module child and the line carries both:

const requestLog = ordersLog.child({ requestId });

requestLog.info({ ms: 42 }, 'finished');

{"level":30,...,"module":"orders","requestId":"req-77","ms":42,"msg":"finished"}

And there is one more thing a child can carry: its own level, set independently of its parent. That is what the second argument to child() is for, an options object where level is one of the things you can set:

export const paymentsLog = logger.child({ module: 'payments' }, { level: 'debug' });

Leave that second argument off, as we did earlier, and the child simply inherits whatever the parent is set to.

With the root logger sitting at info, that one line means payments emits its debug output while every other area of the app stays quiet. When you are chasing a bug in one subsystem in production, that is the difference between the detail you need and a firehose of everything at once.

Where logging actually runs in a Next.js app#

This one catches people who put a logger.info() in a component and then hunt for it in the browser console. Next.js runs your code in more than one place, and Pino is a Node.js library.

The rule that keeps you out of trouble: import the logger only from files that are server-only. If a client component imports your logger module, the bundler follows that import and you'll get a build error about a Node module in browser code, which is confusing until you realise it's the import chain talking, not the logging call.

For middleware on the Edge runtime, console.log genuinely is the tool you have. It's a small enough surface that it rarely matters.

Log levels per environment with LOG_LEVEL#

Remember our logger reading process.env.LOG_LEVEL? Now we can use it.

Add it to .env.local for your own machine:

LOG_LEVEL=debug

With that set, every log.debug() you sprinkled around starts printing, and when you unset it, they all go quiet again without you touching a line of code. That is the whole point of levels: debug calls are permanent instrumentation you leave in the codebase, not temporary lines you delete before committing.

A setup that works well in practice:

• local development: debug, so you see the detail while building
• staging: debug or info, depending on how noisy things get
• production: info, or warn on a very high-traffic service

Set it in your hosting provider's environment variable settings rather than committing it, the same way you handle everything else in there. Our post on keeping secrets out of your repo with environment variables covers the .env file conventions and what belongs in each one. LOG_LEVEL isn't a secret, but it lives alongside the ones that are.

One thing worth knowing: the level is read once, when the logger is created. Changing the variable means restarting the process. You can also change it at runtime with logger.level = 'debug', which is handy behind an admin-only route on a service you can't restart casually.

Frequently Asked Questions#

Should I log the error and throw it as well?#

Usually, no. Pick one place to log it.

A useful rule is:

Throw where it fails, log where you handle it.

Here is what goes wrong when you do both.

Say saveOrder() catches a database error, logs it, and then throws it. The code that called it catches the error and logs it again:

async function saveOrder(order) {
  try {
    await db.orders.create(order);
  } catch (err) {
    log.error({ err }, 'failed to save order');
    throw err;
  }
}

async function checkout(order) {
  try {
    await saveOrder(order);
  } catch (err) {
    log.error({ err }, 'order could not be completed');
  }
}

The result is two log entries for one failure:

{"level":50,...,"msg":"failed to save order"}
{"level":50,...,"msg":"order could not be completed"}

Now when you are looking at your logs, you have to figure out whether those are two separate problems or the same problem being reported twice.

Usually, the second message is the useful one.

saveOrder() only knows that saving the order failed. The code handling the checkout knows what that failure means to the application: the order could not be completed.

That's the message you actually want to see when you are investigating a problem.

So saveOrder() should throw the error and let its caller decide what to do with it:

async function saveOrder(order) {
  try {
    await db.orders.create(order);
  } catch (err) {
    throw new OrderSaveError({ cause: err });
  }
}

The caller can then log it once:

try {
  await saveOrder(order);
} catch (err) {
  log.error({ err }, 'order could not be completed');
}

This also keeps your lower-level functions reusable. The same database failure might need to be retried in one place, turned into an error response somewhere else, or simply recorded and ignored in a background job.

The function that caused the error usually doesn't know which one is appropriate.

Why don't my log.debug() lines show up?#

Because the default level is info, and anything below it is dropped without a word. debug is 20, info is 30, so debug calls run and go nowhere.

Set LOG_LEVEL=debug in .env.local and restart. The level is read when the logger is created, so a running process will not pick up the change on its own.

How do I keep passwords and tokens out of my logs?#

Use the redact option, which takes the paths you never want written:

export const logger = pino({
  redact: ['password', 'req.headers.authorization', '*.token'],
});

Anything matching comes out as "[Redacted]" while the rest of the object is untouched, and the wildcard form catches the same key wherever it is nested. This is worth setting up on day one, because structured logging makes it far easier to accidentally log a whole user object than console.log ever did.

Where to go next#

At this point you have structured logs with real levels, one logger module the whole app shares, readable output while you develop, and a correlation id that follows a request wherever it goes.

The obvious next question is where those JSON lines should end up once they leave your server, since a terminal that scrolls away is not much of an archive. Shipping logs to a hosted destination is its own topic with its own set of gotchas, and it's the subject of a follow-up post. 🚀

Keep reading#

• Why Your Next.js Deploy Fails on Render
• Deploy a Next.js App with Render.com
• How to Restart Your Node App Without Nodemon

It’s easy to assume that somewhere on the server there’s a database containing your username next to your password. After all, how else would the website know whether you’ve entered the correct one?

The surprising answer is that, on a well-designed system, your password is never stored in a form that anyone can read, not even the company that owns the website.

Your password is transformed, not stored#

Instead of saving your password directly, the server runs it through something called a hash function. You can think of a hash as a digital fingerprint. It always produces the same output for the same password, but it’s designed to work in only one direction.

For example, if we take the password:

myPassword123

and hash it, we get something that looks like this:

a336f671080fb420c27461fcf4f2c8d1d87b8a5f6d6f8b5f8f13c2b7d5ad7168

That long string of seemingly random characters is what gets stored in the database, not your actual password. Modern applications typically use dedicated password hashing algorithms such as bcrypt or Argon2, but the basic idea is the same: the password is transformed into a value that can’t realistically be reversed.

The next time you log in, the server hashes the password you entered again and compares the new hash with the one stored in the database. If they match, you entered the correct password, even though the server never needed to know what your password actually was.

And once you’re through that door, your password isn’t checked again on every page — the site remembers you with a cookie, which exists precisely because the early web had no memory between page loads.

Then how does password reset work?#

This was the question that confused me the first time I learned about password hashing.

If a website doesn’t actually know my password anymore, how can it send it back to me when I click Forgot Password?

The answer is that it can’t.

A properly designed system never emails your existing password because it doesn’t have access to it. Instead, it generates a temporary, time-limited token that proves you requested a password reset. After you choose a new password, the old hash is discarded and replaced with a new one.

That’s also why receiving your original password in an email should immediately raise a red flag. It usually means the website stored it in plain text or used an insecure method to protect it.

Good security is often about storing less#

One of the things I enjoy most about software engineering is discovering ideas that seem counterintuitive at first.

Most people assume security is about building stronger walls around sensitive information. While that’s certainly part of it, an even better approach is to avoid storing information you don’t actually need.

It’s the same shape of idea as why an invalid card number fails instantly: the best move often isn’t doing the work more securely or more quickly, but arranging things so the work never has to happen.

A website doesn’t need to know your password after you’ve signed up. It only needs a reliable way to verify that the password you enter later is the same one you originally chose.

That small design decision dramatically reduces the damage a data breach can cause. Even if someone steals the database, they won’t find a list of everyone’s passwords waiting for them.

Sometimes the smartest engineering decision isn’t protecting more data—it’s making sure you never keep it in the first place.

Keep reading#

• Why Invalid Card Numbers Fail Instantly
• Environment Variables with Dotenv — keeping secrets out of your own codebase

At first glance, it feels as though the website is checking your card with your bank in real time. After all, how else could it know that the number is invalid?

The surprising part is that, most of the time, it doesn’t contact anyone.

Instead, your browser performs a simple mathematical check that has been around for decades.

It’s checking the structure, not the card itself#

Credit card numbers aren’t just a random sequence of digits. The final digit is calculated from all the previous ones using the Luhn algorithm, a checksum formula designed to catch common typing mistakes.

The algorithm is named after Hans Peter Luhn, an IBM engineer who developed it in 1954. More than 70 years later, it’s still used by every major credit card network to detect common typing errors.

When you enter your card number, your browser runs the algorithm locally. It processes the digits, performs a few simple calculations, and determines whether the number follows the expected pattern.

If it doesn’t, the form already knows something is wrong.

No request is sent to the bank.

No payment provider is contacted.

The entire check happens on your own device and usually finishes in less time than it takes to blink.

Why bother checking before sending the request?#

Imagine every payment form immediately contacted the payment provider every time someone accidentally pressed the wrong key.

That would mean millions of unnecessary requests every single day.

Instead, websites filter out obviously invalid numbers before they ever leave your browser. It’s faster for the user, reduces unnecessary network traffic, and saves payment providers from processing requests that were never valid to begin with.

Only after a card number passes this initial validation does the payment process continue.

That doesn’t mean the card is real, active, or has enough funds. It simply means the number is structured correctly.

A clever design hiding in plain sight#

One of the things I enjoy most about software engineering is discovering solutions like this. They’re rarely complicated, yet they solve real problems remarkably well.

Most users assume the validation is happening somewhere in a distant data center. In reality, it’s often nothing more than a lightweight mathematical check running directly in the browser.

It’s a good reminder that not every performance improvement comes from faster servers or more powerful hardware.

Sometimes the smartest solution is simply avoiding work that never needed to happen in the first place.

How does the Luhn algorithm work?#

The Luhn algorithm performs a few simple calculations on the digits of a card number to check whether its structure is valid. Starting from the right, every second digit is doubled.

If doubling a digit produces a number greater than 9, 9 is subtracted from the result. Once every digit has been processed, they’re all added together. If the final sum is evenly divisible by 10, the card number passes the check.

It’s important to remember that this doesn’t verify whether the card is real, active, or has enough available funds. It simply confirms that the number follows the expected mathematical pattern, allowing websites to catch typing mistakes before sending a payment request to the server.

Keep reading#

• How Password Hashing Works
• Why are internet cookies called cookies?

If you’re trying to get your first job, it’s hard not to let those headlines get to you. You spend months learning JavaScript, React, or Python, only to read that companies will soon generate everything with AI.

I understand why people are worried. AI is improving at an incredible pace, and pretending nothing is changing would be unrealistic.

What I don’t agree with is the conclusion that junior developers simply won’t be needed anymore.

The role is changing, not disappearing#

I use AI almost every day now. Sometimes it saves me half an hour. Sometimes it helps me understand a library I’ve never worked with before. Other times it confidently generates code that looks convincing but contains subtle bugs that only become obvious once you actually understand the problem.

That’s probably the biggest lesson AI has taught me so far.

Generating code isn’t the difficult part anymore. Knowing whether that code is correct, maintainable, secure, and actually solves the problem is where the real work begins.

People often describe junior developers as if their only purpose is to write small features or fix simple bugs. If that were true, then yes, AI would make many of those tasks much faster.

But that has never been the full picture.

A junior developer is learning how software is built inside a real company. They’re learning how to understand a codebase they didn’t write, how to communicate with teammates, how to ask good questions, how to investigate bugs, how to respond to code reviews, and how to make better decisions over time.

Those aren’t skills you download overnight. They’re developed by working with other engineers, making mistakes, and gradually building experience.

Every senior developer started somewhere#

One thing I rarely hear people mention is a simple question.

If companies stop hiring junior developers today, where exactly will senior developers come from five years from now?

Every experienced engineer was once the person asking basic questions during code reviews. Every tech lead was once the developer trying to understand why their pull request needed twenty changes before it could be merged.

Experience isn’t something you can skip. It’s accumulated through hundreds of small decisions, failed ideas, production incidents, and conversations with other developers.

AI can certainly accelerate that learning process, but it doesn’t replace it.

The first job will probably become harder#

This is the part where I think the conversation should be more honest.

I do think AI will make it harder to land that first job.

If an experienced developer can complete routine work twice as fast with the help of AI, a company may decide it needs fewer people doing that kind of work. That naturally reduces some of the opportunities that junior developers relied on in the past.

But saying that entry-level hiring becomes more competitive is very different from saying junior developers disappear altogether.

Companies still need engineers who understand their systems, products, customers, and internal processes. They also need people who can grow into senior engineers over the next five or ten years. Hiring only experienced developers forever isn’t a realistic strategy for most engineering teams.

The developers who adapt will have the advantage#

If I were starting my career today, I wouldn’t ignore AI, and I definitely wouldn’t be afraid to use it.

I’d use it to explain concepts I don’t understand, review my code, suggest improvements, and help me explore unfamiliar technologies. At the same time, I’d make sure I understand why the generated solution works instead of copying it blindly.

That ability is becoming a skill in its own right.

The developers who stand out over the next few years won’t necessarily be the ones who write every line of code manually. They’ll be the ones who know when AI is helping, when it’s making incorrect assumptions, and when the right answer is to ignore its suggestion completely.

The industry is changing, just as it has many times before. New tools have always shifted the way we work, but they’ve rarely eliminated the need for people who understand how software is built.

I don’t think junior developers are disappearing.

I think the expectations are rising, the competition is increasing, and the learning curve is changing. That may make the journey more challenging than it was a few years ago, but it doesn’t make the role any less important.

After all, every senior developer the industry will need five years from now has to start somewhere.

Keep reading#

• Am I Too Old to Learn Coding?
• What is Scrum? 101 Guide For New Developers
• Best Job Sites for Web Developers
• Why I Stopped Memorizing Docker Commands

The funny thing is that I quickly found myself opening Google over and over again.

“How do I rebuild the containers?”

“Was it --build or --force-recreate?”

“How do I remove the volumes again?”

At first, I found it a little frustrating. I’ve been a developer for years, so surely I should know these commands by heart by now.

Then it hit me.

I don’t use Docker every single day.

At work, I spend most of my time building features, reviewing pull requests, fixing bugs, discussing ideas with the team, and trying to understand business requirements. Docker is just one of many tools I use. Some weeks I barely touch it, while other weeks I use it constantly.

Why would I expect myself to remember commands that I only need once every few weeks?

The best developers don’t memorize everything#

For a long time I believed experienced developers had incredible memories. I imagined senior engineers sitting at their keyboards, effortlessly typing every Git command, every Docker option, every Linux flag, without ever opening a browser.

Working alongside experienced developers completely changed that perception.

People Google things all the time.

They read documentation.

They search old Slack messages.

They copy commands from previous projects.

The difference isn’t that they remember everything. The difference is that they know what they’re looking for and they understand why they’re using it.

That distinction is much more important than memorization.

Once I accepted that, I stopped trying to build a perfect memory and started building better notes instead.

Whenever I found myself searching for the same command twice, I added it to a personal cheat sheet. Not every Docker command—just the ones that were genuinely useful for the way I work. Duke went through exactly the same thing and published his, if you want a starting point: Docker & Docker Compose Cheat Sheet.

Over time, that little document became one of the most valuable resources I had. Every time I returned to a side project after a few weeks away, I didn’t have to search the internet again. Everything I actually needed was already there.

Understanding beats memorization#

Interestingly, the cheat sheet also revealed something about my own workflow.

I wasn’t forgetting Docker because Docker was complicated.

I was forgetting commands because they weren’t the important part.

The important part was understanding what was happening.

Once you understand the difference between rebuilding an image, recreating a container, removing a volume, or simply restarting a service, looking up the exact command becomes a twenty-second task instead of a stressful experience.

That’s something I wish someone had told me much earlier in my career.

Programming isn’t about carrying thousands of commands around in your head.

It’s about building mental models.

If you understand how the pieces fit together, the syntax is just a detail. Documentation exists for a reason, and even experienced developers rely on it more often than people realize.

So if you’re learning Docker and you find yourself repeatedly searching for the same commands, don’t take it as a sign that you’re failing.

Build your own reference instead.

Write down the commands you actually use. Add a short note explaining why you use each one. Keep improving it every time you learn something new.

A year from now, you probably won’t remember every Docker command.

And that’s perfectly okay.

You’ll have something much more valuable: a workflow that lets you get back to solving real problems instead of trying to prove how much you can memorize.

Keep reading#

• Docker & Docker Compose Cheat Sheet
• Husky Hooks: The Easy Way to Improve Your Project Workflow
• Will AI Replace Junior Developers?

Yes. Absolutely. And here’s why.

What is curl?#

curl (Client URL) is a command-line tool for transferring data using network protocols — most commonly HTTP and HTTPS. It has been around since 1998, ships on virtually every Unix-based system, and is available on Windows. It requires no GUI, no account, no setup. You open a terminal and you run it.

That simplicity is precisely why it remains irreplaceable.

The AI Argument — and Why It Doesn’t Replace curl#

Let’s address the obvious: AI tools are genuinely good at generating curl commands. You describe what you want, and a model will produce a well-structured command. That’s useful. But there’s a trap here that catches a lot of developers.

When AI generates a curl command for you, you still need to understand what it’s doing.

Consider this scenario: an AI tool generates an API call with an Authorization: Bearer header. Your request returns a 401 Unauthorized. Is the token expired? Is the header name wrong? Is the endpoint expecting a different format? Is the request being blocked before it even hits your application? You cannot audit that without understanding what curl is sending and what the server is returning.

AI accelerates the writing. It does not replace the reading.

Understanding curl means you can:

• Verify what an AI-generated command is actually doing before you run it in production
• Audit requests — check headers, payloads, authentication schemes, and encoding
• Catch security issues — misrouted credentials, accidental plain-HTTP calls, exposed tokens in query strings
• Reproduce and isolate bugs precisely, without UI noise

In 2026, the developers who get the most value from AI tooling are the ones who can critically evaluate the output. curl is one of the tools that lets you do that for HTTP.

Simple Debugging — Your First Line of Defence#

The most common use of curl is also the most underrated: quick sanity checks.

Is the server up? Is the endpoint responding? Is the response what you expect?

curl -i https://api.yourapp.com/health

The -i flag (short for --include) tells curl to include the response headers in the output. In one command, you get the HTTP status code, response headers, and body. No browser. No Postman. No waiting for a frontend to render. Just raw, unambiguous output.

You can try this right now against a real public endpoint built for exactly this purpose:

curl -i https://httpbin.org/get

You’ll see something like this in your terminal:

HTTP/2 200
date: Wed, 18 Mar 2026 08:03:11 GMT
content-type: application/json
content-length: 253
server: gunicorn/19.9.0
access-control-allow-origin: *
access-control-allow-credentials: true

{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/8.7.1",
    "X-Amzn-Trace-Id": "Root=1-69ba5c3f-0f5b955166ab5fd523bff65c"
  },
  "origin": "31.152.0.126",
  "url": "https://httpbin.org/get"
}

Notice what you’re reading: the status line (HTTP/2 200), every response header the server sent, and then the JSON body below. The body itself echoes back what headers you sent — which is useful when you want to verify curl is attaching the right Authorization or Content-Type header to your request.

httpbin.org is a free, public testing service. You can use it to test GET, POST, headers, authentication, redirects, and more — no account needed.

This is invaluable when debugging in environments where you have no GUI — a Docker container, a remote server, a CI pipeline, a production incident at 2am.

When something breaks, curl is how you rule out the network layer, the server, and the endpoint in under ten seconds.

QA and API Testing — Beyond the Happy Path#

QA engineers and backend developers both reach for curl when testing API contracts. It lets you construct exact requests — control every header, set the method, define the body, specify the content type — and observe exactly what comes back.

Here’s a POST request with a JSON body:

curl -X POST https://api.yourapp.com/v1/goals \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your_token_here" \
  -d '{"name": "House down payment", "targetAmount": 50000, "targetDate": "2027-06-01"}'

This is readable, shareable, and reproducible. You can paste it into a bug report, into a Slack message, into a GitHub issue. Anyone with a terminal can run it exactly as written and see exactly what you saw.

That reproducibility is something GUIs struggle to provide cleanly. curl commands are self-documenting. They are also scriptable — you can put them in shell scripts to automate repetitive QA workflows.

Inspecting Headers — Where Bugs Actually Hide#

A significant class of production bugs live in HTTP headers, not in response bodies. CORS errors, misconfigured caches, wrong content types, missing security headers — none of these show up clearly in a browser’s response body. You need to look at the headers.

curl gives you the full picture with -v (verbose mode):

curl -v https://httpbin.org/headers

* Host httpbin.org:443 was resolved.
* IPv6: 64:ff9b::3653:e965, 64:ff9b::36d2:2394, 64:ff9b::22eb:43ee, 64:ff9b::3402:3c33, 64:ff9b::20c3:2e3f, 64:ff9b::6432:e5a4, 64:ff9b::3417:5e26, 64:ff9b::20c0:1c5b
* IPv4: 32.192.28.91, 54.83.233.101, 54.210.35.148, 100.50.229.164, 52.23.94.38, 52.2.60.51, 34.235.67.238, 32.195.46.63
*   Trying [64:ff9b::3653:e965]:443...
* Connected to httpbin.org (64:ff9b::3653:e965) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=httpbin.org
*  start date: Jul 20 00:00:00 2025 GMT
*  expire date: Aug 17 23:59:59 2026 GMT
*  subjectAltName: host "httpbin.org" matched cert's "httpbin.org"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M03
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://httpbin.org/headers
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: httpbin.org]
* [HTTP/2] [1] [:path: /headers]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /headers HTTP/2
> Host: httpbin.org
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/2 200
< date: Wed, 18 Mar 2026 08:06:07 GMT
< content-type: application/json
< content-length: 172
< server: gunicorn/19.9.0
< access-control-allow-origin: *
< access-control-allow-credentials: true
<
{
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/8.7.1",
    "X-Amzn-Trace-Id": "Root=1-69ba5cef-25ce2a403835b096102690f0"
  }
}
* Connection #0 to host httpbin.org left intact

Verbose output shows you:

• The full request headers sent by curl
• The TLS handshake details
• The response status line
• Every response header returned
• The response body

You can immediately see whether Cache-Control is set correctly, whether Access-Control-Allow-Origin is present, whether the server is returning application/json or accidentally serving text/html for error responses. These are the kinds of details that matter and that most GUI tools obscure behind tabs and dropdowns.

curl Teaches You HTTP#

This is the deeper argument. Learning curl is not really about the tool — it is about what the tool forces you to confront. Every flag in curl maps to an HTTP concept:

• -H / --header → HTTP headers
• -X / --request → HTTP methods (GET, POST, PUT, PATCH, DELETE)
• -d / --data → request body
• -i / --include → response headers
• -L / --location → following redirects
• -b / --cookie → cookie handling
• -u / --user → HTTP Basic Authentication

When you learn curl, you learn HTTP. You develop an accurate mental model of the request/response cycle that abstract clients hide from you. That model makes you a better API designer, a better debugger, and a better reviewer of AI-generated code.

Who Should Learn curl?#

• Backend developers — to test endpoints during development without spinning up a frontend
• Frontend developers — to isolate whether
• a bug is in the API or in the client code
• QA engineers — to write reproducible test cases and regression scripts
• DevOps and platform engineers — to probe services, check health endpoints, and diagnose network-level issues
• Anyone using AI tools — to verify and audit what the AI is generating

The Bottom Line#

curl is not glamorous. It has been around for nearly three decades. It has no UI, no drag-and-drop, no AI suggestions built in. And it is still, in 2026, one of the most useful things you can have in your toolkit.

It is fast, available everywhere, scriptable, and honest. It shows you exactly what is on the wire. In a world where AI can generate HTTP calls but cannot tell you whether those calls are correct for your specific situation, that honesty matters more than ever.

Learn curl. Not instead of modern tools — but alongside them. Use it to debug, to test, to audit, and to build the kind of intuition about HTTP that no GUI can give you.

The terminal is not going anywhere. Neither is curl.

Keep reading#

• Docker & Docker Compose Cheat Sheet
• Express.js Server with TypeScript
• What Is a Cron Job? Simple Guide for Beginners

The shiny features of working remotely#

Below, we’ll explore why working remotely is such an excellent option — one that offers freedom and flexibility that we can benefit from.

The liberty to live life your way#

Rolling out of bed, throwing on your fluffy sportswear, sidestepping the strict office 👠 dress code. Drinking the first cup ☕ of coffee in your cozy place, listening to music, and eating this amazing lemon cake you made yesterday, you know, the one with the strawberries on top.Your long-awaited chance to start the healthy diet you’ve wanted, free from distractions and street food, has finally arrived, too. It’s a win-win situation, for both work and health, admit it! In addition, no worries about running outside in the morning ☔ rain or wasting time in 🛵 traffic. And guess what? Dealing with upset faces and angry looks for delays is thankfully one less thing to worry about. It really feels like living inside an amazing 🌌 dream. Isn’t it?

Building your working environment#

One of the most exciting parts of working remotely is the chance to design your own “coding land”, avoiding difficult coworkers and the constant 📢 noise of an open office. An extra-large desk, exclusively for you, and huge 🖥 monitors with mood lighting. On top of that, the comfy chair that provides a massage to the back and makes debugging 🐞 less painful. It looks like you are the first one to appear in the credits of a science fiction movie 🎬 ✨. What a futuristic, inspiring world! Isn’t this a dreamy place to work?

Plus, do you need a change from this scenery? I doubt it, but let’s say that you need. With just a laptop and wifi, you could join meetings from a cabin 🏡 in the woods or fixing bugs and pushing commits under the trees by the 🏞 river. Well, as far as I can tell, that’s a real perk! But be careful and stay focused if you stare too long at the water, your ideas may jump in instead of 🌼 blooming on your screen, or even worse, your 💻 laptop decides to take a dive and go with the flow! 🌊

The flexibility you enjoy out in the world#

To make matters even better, what about this fantastic option to create your daily program as you always wish? You can eventually arrange this appointment with the 🩺 doctor you haven’t been able to reach for ages, since afternoons are always booked up.

Remote work allows you to go wherever suits you. You can take long walks in the park, which brings more joy and laughter into your life. Additionally, you can fill your day with sports, whether 🚴‍♀️ individual or ⚽ team-based. Sports can relax you and energize you at the same time. Plus you balance the solitude working from home as team-based sports surround you with companionship, friendship, and a sense of belonging.

And what a miracle! Join the 🛒 supermarket at 9 o’clock in the morning, shopping while whistling around alone, avoiding these never-ending lines. Do not pretend that this way of life doesn’t seem dreamy, too?

Let’s be honest, the pros are definitely appealing, but is it all sunshine and rainbows? 🌈✨ Perhaps it’s time to flip the script and see the other side before your dream becomes a nightmare, after all, every rose has its thorn.

The hidden bugs of pajama Life#

Below, we’ll analyze why working remotely can quickly turn into a disaster. Once you get freedom, every day will be an unstoppable battle to stick to a schedule and soon chaos will become your constant company.

The unbeatable alarm clock#

Rolling out of bed… Ops!! You do not have to! You are planning your daily program now! All these must…, must… are not really necessary anymore! Let’s roll over and return to the dreamland for a few more minutes! Suddenly…. Oh my God! What time is it? Where am I? What about all these deadlines at work? Yes, work is still in the game, or at least this is what you wish 💸 for. The most significant mistake we make when we lose the “Boss“, the one who is always hovering over and keeping us focused and in line. No discipline! No focus! No program!

The constant parade of distractions#

Working remotely can also lead to an endless lack of focus. Your fluffy, warm bed on a cold 🌨 day. Another 🎞 episode of your favorite series, and just when you’re finally deep in your code, the laundry machine decides to announce—loudly and proudly—with a nonstop “bip-bip-bip” 🔔 that it’s done. You finally sit back down at your desk, only to find your cat has claimed it as their personal 👑 throne, demanding attention at the exact moment you need to focus.

And just when you manage to reclaim your keyboard, “ding-dong” the doorbell rings because the delivery guy is here with yet another package 📦 from that “one last 🤣 online order.” By the time you get back to your screen, you’ve completely forgotten what bug you were even fixing in the first place.

Coworkers but not connected#

Besides that, your colleague’s status still shows as offline/away, making it very difficult to get in touch. Jumping into their desk and asking a quick question is no longer an option, remember? So, all signs indicate that a former common day “at work” can now take ages, so you can grow a beard while waiting. A 30-second, straightforward question at the office can quickly turn into an hour or even longer 😫 of back-and-forth messages.

And just like that, this coworker, who was once known as “the office weirdo“, appears to be the perfect fit for you. It seems like you’re experiencing the sense of missing someone for the first time and loneliness hangs in the air like a heavy 🌫 fog.

The isolation factor & living with system errors#

Another crucial aspect we must pay attention to is detachment, and one of the biggest challenges of remote work. At first, everything seemed ideal. Finally, alone! My life, my rules! Then it is slowly creating distance not only from coworkers but also from the sense of belonging to a team. Soon, this silence can start to feel heavy, and even the cat can’t bridge the weird sense of emptiness.

Excessive isolation can easily lead to an unbalanced life, where work begins to dominate and personal well-being is neglected. Your daily schedule is now destroyed and this can be extremely harmful. Much like running on buggy code, it eventually crashes. Without clear boundaries, stress, 😰 exhaustion and lower productivity will be your besties. These awful “burnout syndrome” (a state of physical and mental exhaustion) and “impostorism or impostor syndrome” (the nagging feeling that you are never doing enough or not good enough at what you do) will knock on your door without hesitation.

Remote work – Bottom line#

Whether working remotely is a good choice depends on the person. The balance between the benefits and drawbacks ultimately depends on personal circumstances. What about you? Have you ever worked remotely or considered doing so? Do you agree with these points? Are these benefits and challenges in your mind? Do you believe this kind of work is the right fit for you? What makes you feel that way? What are your thoughts right now? Recognizing how these factors align with your own goals and answering the key questions above is essential before making your final decision about whether to work remotely or not. And for those who are already working remotely, these questions can help you understand if this setup trully works for you.

Having the option to work from anywhere can be a dreamy scenario, but it only works if you manage to stay disciplined and focused, striking the right ⚖️ balance between life and work. Good routines and rules are crucial. Frankly, this is the time of your life when 📅 planning matters more than ever.

Think of it as your compass to enjoy all the freedom without losing your 🎯 direction. Just remember: whether you’re in an office, at home, or somewhere outside, the job still needs to be done, and no amount of pajamas or the gentle “murmur” of the flowing river will change that. After all, the bills 💵have been paid.

Keep reading#

• Developer Burnout: Signs and Recovery
• How To Decide If Programming Is Right For You?
• Best Job Sites for Web Developers

In my day-to-day (9–5) work, I don’t use Docker extensively beyond the basic up and down commands, so some of the more advanced or less frequent commands tend to get rusty over time. That is a very normal place to end up, and it’s the argument for not memorising Docker commands at all and building a workflow you can look things up in instead.

While refreshing my Docker and Docker Compose knowledge, I decided to collect all the commands I actually use and put them into one place. Think of this post as a personal cheat sheet—useful for quick debugging, reminders, or getting unstuck when something isn’t behaving as expected. Hopefully, it helps you too. 😊

Docker Compose Commands#

Docker Compose allows you to define and run multi-container applications using a single configuration file, making local development and orchestration much easier.. These are the commands I use most.

Starting Services#

These commands are used to start one or more services defined in your docker-compose.yml file, either in the foreground or background.

Start all services defined in docker-compose.yml:

docker compose up

Start in background (detached mode) – you get your terminal back:

docker compose up -d

Start services and force a rebuild of images (useful after changing a Dockerfile or dependencies):

docker compose up --build

Start specific service only:

docker compose up -d service-a

or start multiple services at once:

docker compose up -d service-a service-b

Stopping Services#

Use these commands to stop running containers, with options to either keep or completely remove them.

Stop all services (containers are stopped but not removed):

docker compose stop

Stop and remove containers (this is what you usually want):

docker compose down

Stop, remove containers and volumes ⚠️ Warning: This deletes persisted data such as databases.

docker compose down -v

Stop specific service:

docker compose stop service-a

Restarting Services#

Restarting services is useful after configuration changes or when a container becomes unresponsive.

Restart all services:

docker compose restart

Restart specific service:

docker compose restart service-a

For Node.js apps, you might also want file-watching inside your container using Node’s built-in --watch flag.

Viewing statuses#

These commands help you quickly check which services are running and their current state.

List running containers for this project:

docker compose ps

List all containers (including stopped):

docker compose ps -a

Docker commands#

In addition to Docker Compose, these core Docker commands are useful for inspecting and interacting with individual containers.

Executing Commands in Containers#

These commands let you access a running container directly, which is especially helpful for debugging and inspecting the runtime environment.

Using an interactive shell:

docker exec -it container_name bash

If bash is not available (for example, in Alpine images), use sh instead:

docker exec -it container_name sh

These commands let you enter a running container with an interactive shell, so you can inspect files, run commands, and debug things directly from inside the container.

Cleanup commands#

Docker can accumulate unused containers, images, and volumes over time—these commands help keep your system clean.

Remove stopped containers, images or volumes:

docker container prune

docker image prune

docker volume prune

or in case you need something more generic

docker system prune --volumes

which removes all unused resources, including volumes.

Removing Containers by Name Prefix#

While setting up my project, I found some containers from old projects that i had probably forgotten to cleanup. Instead of removing them one by one, because they were a lot, I tried to find a command that removes all of them, by using their prefix (needless to say they were sharing the same prefix). The following command removed all containers with the prefix si:

docker rm -f $(docker ps -aq --filter "name=si_")

Viewing Logs#

Logs are often the first place to look when something isn’t working. These commands help you inspect service output, debug errors, and monitor behavior in real time.

docker compose logs
docker compose logs -f service-a # -f keeps streaming logs in real time
docker compose logs --tail=100 # Only the last 100 log lines

So if you wanted to see logs for a specific container, in real time you could use

docker compose logs -f --tail=100 <container-name>

Copy Files From Container#

docker cp container_name:/path/in/container ./local-path

docker-compose vs docker compose#

You may see Docker Compose used in two different ways:

• docker-compose
• docker compose

They do the same thing, but they’re not the same tool.

docker-compose (Legacy)#

• Older, standalone CLI
• Installed separately
• Common in older projects and tutorials

docker-compose up -d

docker compose (Recommended)#

• Built into the Docker CLI
• Installed by default with modern Docker
• Actively maintained and recommended

docker compose up -d

Which One Should You Use?#

Existing projects: stick with whatever the project already uses

New projects: use docker compose

Setting up a new project? You might also want to automate git hooks, check our husky hooks intro guide to learn how.

Quick Reference Card#

This section provides a compact overview of the most commonly used Docker and Docker Compose commands for quick access.

╔═══════════════════════════════════════════════════════════════╗
║                 DOCKER COMMANDS QUICK REFERENCE               ║
╠═══════════════════════════════════════════════════════════════╣
║ COMPOSE                                                       ║
║   docker compose up -d          Start in background           ║
║   docker compose down           Stop and remove               ║
║   docker compose logs -f api    Follow service logs           ║
║   docker compose up --build     Rebuild and start             ║
║   docker compose exec api sh    Shell into service            ║
╠═══════════════════════════════════════════════════════════════╣
║ CONTAINERS                                                    ║
║   docker ps                     List running                  ║
║   docker ps -a                  List all                      ║
║   docker stop name              Stop container                ║
║   docker rm -f name             Force remove                  ║
║   docker exec -it name sh       Shell into container          ║
╠═══════════════════════════════════════════════════════════════╣
║ IMAGES                                                        ║
║   docker images                 List images                   ║
║   docker rmi name               Remove image                  ║
║   docker build -t name .        Build image                   ║
║   docker pull name:tag          Pull from registry            ║
╠═══════════════════════════════════════════════════════════════╣
║ LOGS & DEBUG                                                  ║
║   docker logs -f name           Follow logs                   ║
║   docker logs --tail 100 name   Last 100 lines                ║
║   docker inspect name           Full container info           ║
║   docker stats                  Resource usage                ║
╠═══════════════════════════════════════════════════════════════╣
║ CLEANUP                                                       ║
║   docker system prune           Remove unused                 ║
║   docker system prune -a        Remove all unused             ║
║   docker volume prune           Remove unused volumes         ║
║   docker system df              Check disk usage              ║
╚═══════════════════════════════════════════════════════════════╝
```

Do you have any Docker or Docker Compose commands that have saved you in tricky situations, or ones you use every day? Feel free to share them—we’d love to expand this cheat sheet with more real-world examples.

Keep reading#

• Why I Stopped Memorizing Docker Commands — the case for keeping a sheet like this one
• Beginner’s Guide to Environment Variables with Dotenv
• Why Every Developer Should Still Know curl in 2026

Let me help you make sense of it all.

This post builds on the one you (hopefully) already read: Javascript testing for beginners: A simple, practical introduction. If not, it’s a good starting point to understand why testing matters in the first place. Here, we’ll talk about what tools are out there, why they exist, and how to choose the right one for your project.

Why so many testing tools?#

The short answer is: because testing needs can be very different. Some developers need to test just one small function. Others need to simulate how a user clicks buttons on a real webpage. Some need to test backend logic or APIs. And some want all of that together.

Different tools are created to solve different testing problems. Let’s look at the main ones you’ll hear about.

What is a testing framework?#

Before going further, let’s clear something up. When people say “testing framework” or “testing library,” they sometimes mix up terms. In this post, we’ll use them loosely. Don’t worry too much about definitions.

But just so we’re on the same page:

• A testing framework usually provides the structure: how to describe a test, run it, and report results.
• A testing library might focus on one specific part of the testing process (like simulating user actions or helping with mocking).

Now let’s see what each popular tool actually does.

Jest: The default for many projects#

Jest is probably the first tool you’ll hear about in Javascript testing. It’s widely used, especially in React projects. And for good reason—it comes with most things you need built in: test runner, assertion library, and mocking tools.

• You can write simple tests using test() and expect().
• You can mock functions easily (see what a mock is if you’re unsure).
• It works out of the box with many setups.

A basic test in Jest looks like this:

import { sum } from './math';

test('adds two numbers', () => {
  expect(sum(2, 3)).toBe(5);
});

Jest is great for unit tests, which are explained more deeply in Integration and unit tests: How to choose the right one?. But it also supports more advanced setups.

Still, Jest isn’t perfect for every case.

Vitest: Fast and Vite-Friendly#

If you’re using Vite, you might prefer Vitest. It’s a newer test runner that works very similarly to Jest but is built for speed and modern dev setups.

It supports:

• ES modules by default
• Fast startup thanks to Vite integration
• Very similar API to Jest, so switching isn’t too hard

If you’re just starting and you already use Vite for your project, Vitest is a great alternative. It feels lighter and quicker, especially for frontend apps.

Testing Library (RTL): For testing UI like a real user#

React Testing Library (often called RTL) is a library for testing user interfaces. It doesn’t replace Jest—it works with Jest.

RTL helps you simulate how users actually interact with your app:

• Clicking buttons
• Typing in inputs
• Checking if the right text shows up

Instead of testing if a certain component method was called, you test what the user sees. This makes your tests more realistic.

It follows a rule: “The more your tests resemble the way your software is used, the more confidence they can give you.”

Mocha, Chai, Sinon: The Classic Trio#

Before Jest became popular, many Javascript projects used this combo:

• Mocha for running tests
• Chai for writing assertions
• Sinon for creating mocks and spies

These tools are still good and used in some backend or legacy projects. They give you more flexibility, but also more setup.

For example, to run tests with Mocha and Chai, you’ll usually need to install them separately and configure them more manually.

If you’re just starting, you don’t need to go this route unless you’re joining a project that already uses them.

What about Mocks, Spies, and Stubs?#

You’ll hear these words a lot when testing. Here’s what they mean in simple terms:

• A mock is a fake function that replaces a real one during testing. It lets you test what happens without calling the real thing.
• A spy is a function that records if and how it was called, but still lets the real function run.
• A stub is like a mock but with more control—you can decide what it returns.

If you’re confused, check the glossary entries for mock and spy.

These tools are helpful in unit testing, when you want to isolate just one part of your code. For example, you might want to check that a function called another one, but without actually doing what the second one does.

What should you use as a beginner?#

Here’s a simple suggestion:

• Start with Jest. It’s well-documented, easy to set up, and covers most use cases.
• If you’re using Vite, try Vitest instead.
• If you’re building user interfaces, add Testing Library to test what the user sees.

You don’t need everything at once. Focus on learning how to write a few tests. You’ll naturally learn the tools better as you write more code.

A quick example: Putting it together#

Let’s say you have a small function like this:

export function greetUser(name) {
  return `Hello, ${name}!`;
}

A simple unit test using Vitest would be:

import { describe, it, expect } from 'vitest';
import { greetUser } from './greet';

describe('greetUser', () => {
  it('greets by name', () => {
    expect(greetUser('Anna')).toBe('Hello, Anna!');
  });
});

You could use Jest instead—the code would almost be the same. This test checks the return value, no mocking needed.

Later, if your function becomes more complex (calls an API, uses another function), you might use a mock to isolate the behavior. You can then write more detailed tests, like we discuss in Integration and unit tests: How to choose the right one?.

Final thoughts#

Don’t feel like you need to master every testing tool at once. Testing is a skill you build slowly. Start small, use a simple tool like Jest or Vitest, and practice writing real tests.

If you’re ever stuck on what kind of test to write, go back to Javascript testing for beginners and Integration and unit tests: How to choose the right one? to refresh the theory.

The tools are just tools—they’re here to help you write better, safer code. And soon, you’ll start to feel that they do.  🥳

You change a small piece of logic, and something unrelated breaks. You fix that, and another issue appears somewhere else. At that point, many beginners feel stuck. They know something is wrong, but they don’t have a reliable way to understand what changed or why.

This is where testing becomes useful.

Javascript testing is not about writing perfect code or preventing every bug. Especially for beginners, testing is about building confidence and clarity. It gives you a way to check that your code behaves the way you think it does, and it gives you fast feedback when that behavior changes.

This guide introduces Javascript testing in a practical, beginner-friendly way. It focuses on understanding the ideas first, without pushing tools or complexity before they make sense.

What is Javascript testing?#

Javascript testing is the practice of writing code that checks other code.

A test runs part of your Javascript program and verifies that the result matches what you expect. If the result is correct, the test passes. If it’s not, the test fails and shows you that something is wrong.

Most tests are built around very simple expectations. You might expect a function to return a specific value, handle invalid input gracefully, or behave consistently when called multiple times. Testing gives you a repeatable way to verify those expectations instead of relying on manual checks.

Testing is part of a broader idea known as software testing, which exists across all programming languages. Javascript testing applies the same principles to Javascript code, whether it runs in the browser, on a server, or inside a larger application.

The key benefit of testing is not automation alone. It’s trust. When you have tests, you don’t have to wonder whether something still works. You can check.

Why Javascript testing matters for beginners#

Many beginners believe testing is something you add later, once you are “good enough” at Javascript. In reality, testing is often most helpful when you are still learning.

When you write tests, you are forced to be precise about what your code should do. That process often exposes misunderstandings early. A test might fail not because your code is broken, but because your assumption about how something works was incorrect.

Without tests, debugging tends to rely on trial and error. You log values, refresh the page, and hope you notice what went wrong. With tests, failures give you direct signals. They tell you that something changed and help narrow down where the problem lives.

Testing also makes change safer. Beginners often avoid refactoring because they’re afraid of breaking something they already fixed. Tests reduce that fear by giving you quick feedback when behavior changes.

How Javascript testing works at a basic level#

At a basic level, Javascript testing follows a simple pattern.

You provide some input, run the code you want to test, and then check the result. That final check is done using something called an assertion. An assertion compares what actually happened with what you expected to happen and decides whether the test should pass or fail.

To make this more concrete, here’s a very small example using Jest.

Imagine you have a simple function that adds two numbers:

export const add = (a, b) => {
  return a + b;
};

Now you want to test that this function works as expected. A basic Jest test might look like this:

import { add } from './add';

test('adds two numbers correctly', () => {
  expect(add(2, 3)).toBe(5);
});

In this example:

• test defines a test case
• add(2, 3) runs the code being tested
• expect(add(2, 3)).toBe(5) is the assertion

The assertion checks whether the actual result matches the expected result. If add(2, 3) returns 5, the test passes. If it returns anything else, the test fails.

You don’t need to understand every detail of the syntax right away. What matters is the idea: tests describe expected behavior and automatically verify it.

Types of Javascript testing you should be aware of#

Javascript testing includes different approaches, but beginners don’t need to use all of them immediately.

The most common starting point is unit testing. Unit tests focus on small, isolated pieces of code, usually individual functions. They are fast to run, easy to understand, and easier to debug when something goes wrong.

Other testing types exist, such as integration testing and end-to-end testing. These focus on how different parts of an application work together or how the entire application behaves from a user’s perspective.

One common question beginners ask is whether to focus on unit tests or integration tests first, and how to choose between them.

As a beginner, it’s enough to understand that these testing types exist and serve different purposes. You can explore them gradually as your projects grow in size and complexity.

Javascript testing tools and why they exist#

To run tests, you need a testing tool. A Javascript testing tool provides a way to execute your tests, make assertions, and show clear feedback when something fails.

At a basic level, testing tools take care of the repetitive work. They find your test files, run them, and report which tests passed or failed. This lets you focus on writing and understanding tests instead of building your own testing system from scratch.

Different tools exist because they solve slightly different problems.

Some tools, like Jest and Vitest, are all-in-one solutions. They include a test runner, an assertion system, and helpful features like watching for file changes. These tools are often a good starting point for beginners because everything works together out of the box.

Other tools focus on specific parts of the testing process. For example, Chai is an assertion library that helps you express expectations clearly, while Sinon is commonly used for creating mocks and spies when you need more control over how code behaves during tests.

In frontend-focused projects, especially those using frameworks like React, you may also encounter React Testing Library (RTL). Its goal is to help you test components in a way that reflects how real users interact with them, rather than testing internal implementation details.

It’s important to understand that you don’t need all of these tools at once. Many beginners start with a single, integrated tool and add others only when a specific need appears. The concepts behind testing matter far more than the number of libraries you use.

Testing tools exist to support learning and confidence. They should make testing feel easier, not heavier.

Not sure what tool to start with? I broke down the main ones like Jest and Vitest in a separate post: Javascript Testing Tools Explained, so you can pick without the overwhelm.

How testing changes the way you write Javascript#

Over time, testing influences how you approach writing code.

When you write tests, you naturally start thinking in terms of inputs and outputs. You tend to write smaller, clearer functions because they are easier to test. This leads to code that is easier to read, reason about, and maintain.

Tests also act as a form of documentation. They show how your code is expected to behave in real situations, which is helpful when you return to a project later or share it with others.

Some developers take this further by writing tests before writing code, a practice often called test-driven development. You don’t need to follow this approach strictly, but understanding it helps put testing into a professional context.

Common beginner worries about testing#

It’s normal to feel unsure when starting with testing. Many beginners worry about writing tests the wrong way or not testing enough.

The truth is that imperfect tests are still useful. Testing is a skill that improves with repetition. Early tests may feel awkward, but they still provide feedback and build understanding.

Avoiding testing because it feels unfamiliar only delays that learning. Progress matters more than getting everything right.

Final thoughts#

You don’t need a large project to begin testing. One function is enough.

Write a test. Let it fail. Fix the code. Run the test again and see it pass. That small loop is where learning happens.

As you gain experience, you can add more tests, improve structure, and adopt better practices. But the foundation remains the same: define expected behavior and verify it automatically.

Javascript testing is not about rigid rules or unnecessary complexity. It’s about clarity, confidence, and understanding how your code behaves over time.

For beginners, testing provides structure in a learning process that can otherwise feel chaotic. It helps you move from guessing to knowing, and from hesitation to confidence.

This post is meant to be a foundation. You don’t need to master everything at once. Testing will grow with you, quietly supporting your progress as your skills develop.

Keep reading#

• Javascript Testing Tools Explained
• Integration vs Unit Tests: How to Choose
• Husky Hooks: Improve Your Git Workflow

Let’s take a classic example.

You need a <Modal />. Your UI library already has a <Modal />.

So you open a file and write the imports, and suddenly you’re staring at something like this:

import { Modal } from "@heroui/react";
import { Modal } from "./my-components/Modal";

You see? You’re not the only one thinking Modal is a great name for a component about… well, a modal! In my case, I liked the name, but the developers building the HeroUI library also liked it.

Now you have a small issue: how are you going to denote that a modal is one of yours, or that it’s imported from your UI library?

In this example you’re probably thinking, “Well, maybe I’ll just rename one.” Obviously. Maybe <HeroModal />. Maybe <MyModal />. It works, JavaScript has no issues, TypeScript stops complaining, and you move on.

The problem with this approach is that your code may start feeling noisy after a while. Not broken, but slightly uncomfortable. You might see different files using different aliases, which isn’t the best approach. This increases your cognitive load because you have to remember things instead of intuitively understanding them.

That’s usually when people think the issue is naming.

It’s not.

What’s actually happening is that two completely different ideas are being treated like they’re the same thing.

A library modal is just a tool. It renders a dialog, handles focus, animates, and gets out of the way.

A modal in your app has meaning. It shows up for specific reasons. It follows product rules. It has opinions.

Once you see that difference, naming stops being a guessing game.

To avoid all this headache, the best thing you can do is stop for a bit, think about your approach, and decide what naming convention—a pattern, if you’d like—will help you intuitively understand what’s going on in your app without having to scroll up to your imports every time you see a component used.

Naming convention 1: Your app owns “Modal”, the library is the “Base”#

This is the easiest convention, the one you probably thought about first. The idea behind this is:

• Your app gets to use the “clean” name Modal
• The UI library gets a more technincal name: ModalBase

Example

import { Modal as ModalBase } from "@heroui/react";

Then inside your component’s implementation would be:

function Modal(props) {
  return <ModalBase {...props} />;
}

Other examples for naming your components using this convention could be

<ModalBase />

<BaseModal />

<HeroModal /> // (library-prefixed)

<ModalCore />

<UIModal />

<ModalRaw />

<RawModal />

Pros#

• ✅ Everyone on your team can use <Modal /> without worrying about where it came from.
• ✅ If you ever change your UI library, you only change this wrapper, not your whole codebase.
• ✅ Great for beginners because it keeps things simple and consistent.

Cons#

• ❌ If your wrapper grows too much, it can become “magic”. Teammates may not be able to understand why the modal has more complex logic implementation
• ❌ You must be disciplined with naming

Naming convention 2: Name your modals based on what they actually do#

In this case you skip the generic name and instead name your modals based on what they are doing. This is helpful for large codebases, not small side projects.

Examples of that could be:

<EditProfileModal />

<DeleteAccountModal />

<InviteUserModal />

<SettingsModal />

<ShareModal />

<ConfirmActionModal />

<FeedbackModal />

Pros#

• ✅ Very clear meaning – you know what <DeleteAccountModal /> does just by reading it.
• ✅ Great for beginners – easier to understand than a generic <Modal /> everywhere.

Cons#

• ❌ Can repeat logic – if all modals need the same props or behavior, you might duplicate code.
• ❌ Too many similar names – if you have lots of modals, the list can get long and harder to scan.

Naming convention 3: Use prefix or suffix to show ownership#

If the word Modal confuses you because you are not sure where it came from, which is a valid point, you could ignore using the word Modal by itself and instead decide on a good suffix/prefix identifier.

For your UI library component:

<AppModal />

<ProjectModal />

<MainModal />

<CoreModal />

<ClientModal />

<CustomModal />

<ETModal /> // Prefixing your modal with your app's initials e.g Energy Tracker app

For your App component:

<HeroModal />

<LibModal />

<UIModal />

<ModalLib />

Pros#

• ✅ Very explicit – you can tell at a glance which modal is from your app vs the library.
• ✅ Works well in mixed environments – e.g. multiple UI libraries, monorepos, shared packages.

Cons#

• ❌ Names get longer – <AppModal />, <HeroModal /> are not as clean as <Modal />.
• ❌ Can become inconsistent – if people invent new prefixes (<BaseModal />, <CoreModal />, <MainModal />) without a rule.

Naming conventions that usually cause trouble#

Most teams try at least one of these at some point.

MyModal sounds harmless but doesn’t mean anything to anyone else.

CustomModal stops being descriptive the moment you have more than one.

Library-branded names everywhere tie your feature code to a vendor, even when it shouldn’t care.

Versioned names like Modal2 or NewModal are usually a sign that a decision was postponed, not solved.

All of them work… until they don’t.

A simple question that keeps things clean#

When naming feels hard, this question usually cuts through the noise:

Is this a basic UI building block, or does it express actual product behavior?

If it’s a tool, name it like one. Example: <ModalBase />, <InputPrimitive />, <ButtonCore />.

If it’s intent, name it like intent. Example: <EditProfileModal />, <CreateProjectForm />, <DeleteAccountModal />.

That’s the whole trick. You’ll know you’ve landed in a good place when your imports start feeling calm again:

Wrapping up#

Naming might look like a small detail, but it affects how your whole project feels. Usually when I’m building a project and it’s time to decide on a UI library, I don’t want to spend time trying to identify names — I just start using whatever the import gives me and continue.

The problem is that after a while I usually find myself needing to refactor because my app is getting more complex. You might say, “Well, it’s fine, you’re following the simple-now, refactor-later idea,” and you might be right. There’s a principle in programming, called YAGNI, that says you shouldn’t build complex systems just in case. You build infrastructure when you know you will need it soon.

This applies directly to naming conventions. If you’re building a small side project just for fun, go ahead and use the UI library names like <Modal /> and skip the wrappers.

But if you’re building an app you plan to present, monetize, or seriously grow, then stop for a moment, decide on your conventions, and then continue. The time you spend choosing now will be far less than the time you’ll lose later dealing with refactors and headaches.

If you’re just getting started with app development, naming conventions are one of those topics that only start to matter after your environment is properly set up. If you’re still at that stage, you might find these guides useful before diving deeper into UI architecture: – How to install Git on macOS – How to install Homebrew on macOS – How to install npm on macOS – How to install PostgreSQL on macOS – How to install Java on macOS

What are overlay effects?#

A CSS overlay effect is a powerful technique for placing an extra layer on top of your web content, typically an image or a background, to enhance its appearance or improve readability.

This effect allows you to create various visual enhancements, such as darkening an image or adding a color tint.

You can achieve overlays using the CSS background-color and background-image properties, enabling you to apply stunning visual effects to images. With these properties, you can easily modify the look and feel of your content, making it more engaging and visually appealing.

Let’s dive into an example to see how the CSS overlay effect works.

Basic HTML and CSS setup for a CSS overlay effect#

First, we need to create an HTML element to hold our image and assign it a class. This class will contain all the necessary CSS rules to achieve the desired overlay effect.

<div class="overlay-container"></div>

Next, we write the CSS for our class, setting a background image without repetition. This ensures the image fits nicely within a 400x600px box. With this setup, we can easily apply overlay effects or make further adjustments as needed.

.overlay-container {
  width: 400px;
  height: 600px;

  background-image: url('your-image-url-here');
  background-repeat: no-repeat;
  background-size: cover;
}

At this stage, this is how our image appears on the screen.

Using pseudo-elements for the CSS overlay effect#

A common technique for creating overlay effects is pseudo-elements (::before and ::after). To get this effect working, we have to prepare our class by setting position: relative. Then, we apply position: absolute to the ::before pseudo-element. This ensures that ::before is positioned relative to its parent — the overlay container.

We also use the content: "" declaration to make sure the pseudo-element is generated. In this case, the content remains empty since we want the image to be visible underneath.

Additionally, we set width: 100%; and height: 100%; to ensure the ::before pseudo-element covers the entire area of its parent container, completely overlaying the image.

.overlay-container {
  ...
  position: relative;
}

.overlay-container::before {
  position: absolute;
  content: "";
  width: 100%;
  height: 100%;
}

🔖 For the time being, nothing has changed on our screen; we just made the appropriate preparations for our effect. Let’s continue.

Applying the CSS overlay effect#

Overlay effects come in various types, each adding a unique touch to our images. The CSS property that helps us to create this effect is background-image.

Below, I’ve created different variations for you to explore. 👩‍💻 Enjoy!

Using a linear gradient for the overlay effect#

In the following CSS code snippet, you can see that the background-image property is set to linear-gradient(...), creating a multi-color overlay effect with different transparency levels. This produces a smooth gradient overlay from top to bottom with shades of teal, yellow, and purple that make the perfect match for our image.

.overlay-container::before {
  ...
  background-image: linear-gradient(
    rgba(0, 255, 255, 0.3),
    rgba(255, 255, 0, 0.2),
    rgba(155, 0, 155, 0.2)
  );
}

Using a radial gradient for the overlay effect#

We continue with a more creative approach. Here, radial-gradient(...) creates a unique overlay effect using a circular pattern. It transitions from shades of light gray to dark gray, adding a subtle yet eye-catching touch to the image.

.overlay-container::before {
  ...
  background-image: radial-gradient(
    rgba(255, 255, 255, 0.1),
    rgba(128, 128, 128, 0.2),
    rgba(0, 0, 0, 0.6)
  );
}

Creating a rainbow CSS overlay effect#

Another vibrant and playful effect is the rainbow gradient. Often used for decorative purposes, this effect adds bright, joyful colors to the image, creating a fun and lively vibe. 🌈✨

When you apply this gradient as a background, it creates a smooth transition of colors from purple to red, mimicking the colors of a rainbow (ROYGBIV). The use of semi-transparent alpha values gives a soft blending effect between the colors, creating a visually appealing and harmonious overlay.

.overlay-container::before {
  ...
  background-image: linear-gradient(to bottom left,
    rgba(148, 0, 211, 0.5), rgba(75, 0, 130, 0.3),
    rgba(0, 0, 255, 0.2), rgba(0, 255, 0, 0.2),
    rgba(255, 255, 0, 0.3), rgba(255, 127, 0, 0.3),
    rgba(255, 0, 0, 0.3)
  );
}

In this example, I changed my image to make the outcome clearer, adding a colorful vibe to create a playful atmosphere.

Adding a solid color CSS overlay effect#

You are always free to use a single color as an overlay. In that case, we will apply the background-color CSS property to the ::before pseudo-element.

.overlay-container::before {
  ...
  background-color: rgba(220, 135, 135, 0.2); /* pale pink */
}

In this example, I kept the second image to make the outcome clearer. I’ve given it a softer, more romantic feel, where the pale pink color with the slight see-through effect adds a charming and gentle mood.

🌼 Hope you found my post interesting and helpful. Thanks for being here! 🌼

Keep reading#

• Using CSS Opacity for Transparency
• Introduction To The Powerful CSS Blur Effect
• What You Need to Know About CSS Color Methods

The hidden side of coding isn’t about writing fast or showing off clever tricks. It’s about slow care, patience, and the quiet effort to make something work just a little better today than it did yesterday.

The Art of Reading Code#

Reading code is an underestimated skill. Writing feels creative, it’s your ideas that are taking form. Reading, on the other hand, is about patience. You step into someone else’s logic and try to follow their philosophy. To clean up. To improve.

Sometimes you find brightness: clear approaches, smart patterns and neat solutions. Other times, it’s a labyrinth of chaos. But reading teaches you how others think and how decisions impact the project’s direction. You learn to recognize what makes code clear or messy, and you start borrowing small habits from others that make your own work stronger. All these make you grow!

The more you read, the more you understand that programming is a discussion between people’s minds and habits. With every new project, your knowledge and experience expand, and clarity follows.

Naming Things#

Naming looks simple. You’re just labeling today a class, a variable or a function tomorrow. But is that true? Good names require empathy.

When you name something, you’re trying to communicate with the next person who reads your code. You’re creating hints about what matters. A good name can make code self-explanatory. A bad one turns every future action into a guessing game.

Most of us have seen both ends of that scope, but a beautiful, clear function that tells you exactly what it does just by reading it is what we all need. Naming is one of those quiet acts of kindness in programming. No one thanks you for it, but everyone benefits.

The Battle with Bugs#

Every developer knows the sinking feeling of a bug that just won’t leave you. You change one line, and suddenly five other things break. Time passes. Coffee cools. The sun is going down and you are wondering if you chose the right profession. And just like that, there it is! One missing semicolon, a false variable, a condition you ignored.

Debugging isn’t just about fixing errors. It’s about understanding how systems behave. You start to see patterns, predict where problems might hide, and learn to remain peaceful when everything seems impossible. In time, you realize that every frustrating bug is really a teacher. Forcing you to slow down and gain a better understanding of how programming works.

And most of the time, that understanding feels more pleasing than the fix itself.

The Value of Maintenance#

In the tech world, there’s a heavy emphasis on building new things. That sounds exciting only if you aren’t the one fixing what’s broken. Maintenance work is like the ‘behind-the-scenes’ side of development, but it’s the heart of what keeps products alive.

Maintaining a codebase means respecting its history. You observe the fingerprints of every developer before you and instead of pulling everything down, you learn to adapt it. To make changes that keep things running smoothly.

Good maintenance is about discipline. It’s a long game, and those who play it well are the steady force of every successful project that stands the test of time.

The Patience Behind Progress#

Technology moves fast, but real mastery takes time. The quiet work of reading, naming, cleaning, and fixing bugs is what helps someone grow from just coding into building with purpose. It’s the key to see problems not as blocks in your way, but as parts of a bigger picture.

Solving problems is not always about speed. Patience can bring you pleasure. Sometimes, staying calm when nothing works is a huge victory.

All these good practices lead to quiet wins. They help you stay grounded, build confidence, reduce chaos, and prevent your future selves from burnout and impostor syndrome, which often tries to take over.

In the end, that’s what makes programming more than just a technical skill. It’s an act that depends on your own patience and creativity. In the code you write and in the way you treat the already existing code that surrounds it. In this invisible work that keeps it all running.

Keep reading#

• Made Easy With Reusable Code – Why Classes Matter
• Developer Burnout: Signs and Recovery
• How To Decide If Programming Is Right For You?

Outline of the border-image-slice CSS property#

Let’s see our property more analytically. First, you pick a visual source and then decide where to “slice” it. After that, CSS uses those pieces to sketch the border. Kind of like cutting a picture into a nine-patch grid and placing it around a box. We have 4 corners, 4 sides, and the main content. Only 8 of them actually showed up and used for borders, the corners and the sides. The 9th slice, which is the main part of the element, is optional and it usually carries our content.

A few critical points about those pieces:

• Corners: Depending on the value, they may not stretch (value 1), they just sit there like little anchors, or they may stretch (higher or more values).
• Sides: Stretch or repeat, depending on your border settings. They control most of the visual essence.
• Center: The middle part usually isn’t drawn as part of the border at all—it’s ignored unless you explicitly choose to fill it.

Practical examples: How border-image-slice works#

To better understand how this property works, we first need to insert an image with a width and height of 300px. Next, we’ll apply properties like object-fit: cover, background-size: cover, and background-position: center to keep the image centered and fully visible without distortion. 🔖 These properties are only here so we can clearly see the image at this stage — they aren’t required for the next steps. Finally, we add the source of our image.

<div class="image"></div>

.image {
  width: 300px;
  height: 300px;

  object-fit: cover;
  background-position: center;
  background-size: cover;

  background-image:  url(https://images.unsplash.com/photo-1553526777-5ffa3b3248d8?ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D&auto=format&fit=crop&q=80&w=987);
}

With our image set up, we can continue and see how border-image-slice handles different inputs.

This CSS property can take one to four values. – One value: uses the same slice for every side. – Two values: set the first for top and bottom, and the second for left and right. – Three values: apply the first for the top, the second for both left and right and the third for the bottom. – Four values: follow the standard CSS direction: top, right, bottom, left. With so many options, there is plenty of room to create some truly great-looking border effects.

Setting the value: 1#

Let’s start with value 1. First, we need to add a 20px border but transparent. This gives us the space the image-based border will later occupy, without showing the standard solid border. The image also has to be set as the border image source — border-image-slice has nothing to slice without it.

Then, we set border-image-slice to 1. In this way, the browser takes a very thin section, just one pixel wide, from each edge of the image and stretches it along the borders. As a result, we have only stripes.

.image {
  ...
  border: 20px solid transparent;
  border-image: url(https://images.unsplash.com/photo-1553526777-5ffa3b3248d8?ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D&auto=format&fit=crop&q=80&w=987);
  border-image-slice: 1;
}

Setting one value#

We continue following the same tactic, but this time instead of 1 we use a value of 100. By doing this, the browser cuts a 100-pixel-wide section from each edge of the image and uses those slices to form the new borders. In that way, we are closer to our initial image as we use a wider section of it.

.image {
  ...
  border-image: url(...); /* the same image as above */
  border: 20px solid transparent;
  border-image-slice: 100;
}

Setting two values#

Next, we will use two values, 1 100, to see how different slice sizes affect the borders. The first value (1) applies to both the top and bottom, creating very thin slices, close to line-like borders. The second value (100) applies to both the left and right, creating wider slices that maintain more of the image’s details.

.image {
  ...
  border-image: url(...); /* the same image as above */
  border: 20px solid transparent;
  border-image-slice: 1 100;
}

Setting three values#

Moving forward, it’s time to see the results when using three values. The first value (150) applies to the top, the second value (80) to the left and right and finally the third value (5) to the bottom. As we can observe again, the higher the value, the closer to the image’s characteristics.

.image {
  ...
  border-image: url(...); /* the same image as above */
  border: 20px solid transparent;
  border-image-slice: 150 80 5;
}

Setting four values#

Our final option is to use four different values, one for each side of our element. The values apply in a clockwise direction – top, right, bottom, left. That creates an uneven but interesting border effect.

.image {
  ...
  border-image: url(...); /* the same image as above */
  border: 20px solid transparent;
  border-image-slice: 50 80 120 150;
}

Playing with border-image-slice feels a bit like trimming a photo into fancy frames — every small tweak shifts the mood of the border in surprising ways. What do you think? Are you ready to try it out yourself? Be my guest and have fun! 😃

Keep reading#

• CSS Gradient Borders with border-image
• CSS Border Styles Explained
• clip-path: inset() Explained

Border effect explanation setting linear-gradient#

We’ll begin by creating a box with a 150px width and height that temporarily has a solid 5px black border. This is the box we’ll use to experiment with different gradient border effects and make it pop! 🥳

<div class="box"></div>

.box {
  width: 150px;
  height: 150px;
  border: 5px solid;
}

With our box in place, we can make things more interesting by replacing the simple black border with a color 🍭 splash of CSS gradients.

• First, we need to add the transparent value to the border.
• Next, we continue with the gradient. I decided to start with the linear-gradient and use three colors (magenta, cyan, orange). Feel free to use as many colors as you want.
• In the final step, we set border-image-slice to 1. In that way, the browser uses the whole gradient evenly on all sides of the border.

The browser doesn’t know how to spread the gradient across the border area. Without the border-image-slice property, the gradient won’t appear at all. It is essential to add it as it will activate and display the gradient border.

.box {
  ...
  border: 5px solid transparent;
  border-image: linear-gradient(magenta, cyan, orange);
  border-image-slice: 1;
}

It’s good to know that the border-image-slice property can take up to four values, each one responsible for how to cut (slice) the gradient we use as a border.

More analytically:

border-image-slice: 1; simply put the whole gradient evenly on all sides

border-image-slice: 20; it cuts 20 (px or percentages, depending on what you use) from each edge to make the border

border-image-slice: 20 30; the same as above but the first value is for top and bottom, the second for left and right

border-image-slice: 20 30 10; the first value is for top, the second for left and right and the third for bottom

border-image-slice: 20 30 10 5; finally, the first value is for top, the second for right, the third for bottom and the fourth for left

🔖 When we use a gradient, we usually just write 1 because a gradient isn’t a picture with pixels or edges to slice. It smoothly fills the space, so there’s nothing to “cut”. The value 1 simply tells the browser to use the whole gradient for the border.

More border effect ideas with linear-gradient technique and border-image-slice: 1#

Below, I included a few more examples to help you see how changing the gradient can completely transform the look of a border, making the concept clearer and easier to follow. 😃

Flipping the colors: The reverse linear-gradient#

Colorful linear gradients that flow from top to bottom or the reverse way are like creating amazing color bands that wrap around the box.

.box {
  ...
  border: 5px solid transparent;
  border-image: linear-gradient(to top, magenta, cyan, orange);
  border-image-slice: 1;
}

Smooth side-to-side color flow with linear-gradient#

Colors travel from one side to the other, giving the border’s box a bright, balanced look.

Firstly, from left to right

.box {
  ...
  border: 5px solid transparent;
  border-image: linear-gradient(to right, magenta, cyan, orange);
  border-image-slice: 1;
}

Then, from right to left

.box {
  ...
  border: 5px solid transparent;
  border-image: linear-gradient(to left, magenta, cyan, orange);
  border-image-slice: 1;
}

Playing with diagonal directions#

A diagonal direction gives the sense of a wavy, moving effect. Plus, changing the angle, you can create a more dynamic look.

.box {
  ...
  border: 5px solid transparent;
  border-image: linear-gradient(45deg, magenta, cyan, orange);
  border-image-slice: 1;
}

Color loops: The repeating linear-gradient technique#

With repeating gradients, you can build patterns that literally look like an impressive dancing effect or all these amazing neon light effects. How cool is that!? 😎

.box {
  ...
  border: 5px solid transparent;
  border-image: linear-gradient(45deg, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange, magenta, cyan, orange);
  border-image-slice: 1;
}

Moreover, we are free to experiment with the other two (radial-gradient and conic-gradient) CSS gradients as well. So, let’s dive into some more examples and discover how different gradient ideas come to life.

Border effects with different border-image-slice values#

Radial gradient for spinning border effects#

Now, let’s see what would happen if we use the same gradient, in this case, the radial-gradient, with many different values on border-image-slice. For these examples, I used cyan, pink and violet. 🎨 ✨

In the first example, we maintain the value 1 while in the second, we replace it with a value of 50. The border-image-slice: 1; applies the entire gradient, spreading the colors smoothly around the border. With this transition, the gradient stays wide and soft.

.box {
  ...
  border: 5px solid transparent;
  border-image: radial-gradient(cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet);
  border-image-slice: 1;
}

The border-image-slice: 50; applies a small piece of the gradient. Since it’s using only a part of the gradient’s color range, the colors repeat more often and look like stripes that are spinning around.

.box {
  ...
  border: 5px solid transparent;
  border-image: radial-gradient(cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet, cyan, pink, violet);
  border-image-slice: 50;
}

To sum up, increasing the slice value tells the browser to take a smaller “slice” of the gradient and reuse it around the border. As a result, with a smaller slice, we have more repetition and eventually stronger striping.

Conic gradient for more complex border effect#

Next, let’s see what would happen if we use the same gradient, in this case, the conic-gradient, but different values on border-image-slice. For these examples, I changed the colors and used black, orange, magenta, and black again. 🎨 ✨

🔖 A small detail to keep in mind is that starting and ending with the same color (in this case, black) helps to keep the transitions soft and seamless.

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black, orange, magenta, black);
  border-image-slice: 1;
}

Conic-gradient with repeating pattern#

In this case, with a 1 value it uses almost the entire conic gradient around the border. The colors flow smoothly and evenly, creating a soft circular blend with gentle transitions.

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta,black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black);
  /* all around the same value */
  border-image-slice: 1;
}

On the other hand, with a value 30 it takes a smaller portion of the gradient and stretches it around the border. The border starts showing clearer color sections with mild curves and slight breaks at the corners.

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta,black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black);
  /* all around the same value (30) */
  border-image-slice: 30;
}

Finally, with a value of 60 it uses a very small wedge of the conic gradient and repeats it. As a result, the border shows strong, repeating color bands or striped details, especially near the corners.

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta,black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black);
  /* all around the same value (60) */
  border-image-slice: 60;
}

In this case, we use two values: 1 60. The result is a creative mix of two effects. The first value (1) applies to the top and bottom borders. Due to this we have a smooth and gentle look with wide color transitions. The second value (60) applies to both the left and right borders. Because of that, the effect is a tighter and more striped pattern as the gradient slice we use is smaller and repeated more often.

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta,black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black);
  /* top & bottom - left & right */
  border-image-slice: 1 60;
}

Our final example takes four values: 1 60 60 1. This setup makes our border appear asymmetric, calm, and energetic at the same time. More analytically, the first value (1) is for the top border and uses almost the entire gradient. The second and the third values (60 60) are for the right and bottom borders and use a smaller slice (tighter pattern). While the last value (1) is for the left border and uses almost the entire gradient again. Due to these values, we have smooth and continuous top and left borders, while the right and bottom are striped.

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta,black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black, orange, magenta, black);
  /* top - right - bottom - left */
  border-image-slice: 1 60 60 1;
}

Conic-gradient with color stops#

Furthermore, we can control the color stops by using percentages, allowing us to decide exactly where the colors start and end each time.

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black 75%, orange 75%, magenta 80%, black 85%,  black 90%, magenta 95%, orange 100%);
  border-image-slice: 1;
}

.box {
  ...
  border: 5px solid transparent;
  border-image: conic-gradient(black 0%, black 5%, magenta 5%, magenta 10%, black 10%, black 15%, magenta 15%, magenta 20%, black 20%, black 25%, magenta 25%, magenta 30%, black 30%, black 35%, magenta 35%, magenta 40%, black 40%, black 45%, magenta 45%, magenta 50%, black 50%, black 55%, magenta 55%, magenta 60%, black 60%, black 65%, magenta 65%, magenta 70%, black 70%, black 75%, magenta 75%, magenta 80%, black 80%, black 85%, magenta 85%, magenta 90%, black 90%, black 95%, magenta 95%, magenta 100%);
  border-image-slice: 1;
}

The results we observe when utilizing all these specific values above on the border-image-slice CSS property concerns only a box of 150 pixels in width and height. It is critical to adjust the values if you have different dimensions.

Take into consideration that gradients with the 1 value look better in square shapes, as the color flow fits perfectly within equal sides.

Experimenting with gradient borders opens the door to an endless palette of styles — from soft pastel outlines that frame content elegantly to bold, vibrant strokes that command attention. The key lies in balance: using color transitions and subtle motion to enhance, not overpower, the user experience. Whether you’re styling buttons, containers, or entire sections, CSS gradient borders are a reminder that even the smallest design detail can carry a playful spark — proof that borders don’t just separate elements, they can also bring them to life.

Keep reading#

• The border-image-slice CSS Property
• CSS Border Styles Explained
• CSS Conic Gradient Made Easy

In this guide, we’ll go step by step:

• Check if Java is already installed (so you don’t install it twice by mistake)
• Learn what a JDK kit is and why most developers use it
• Install Java on a Mac using either Homebrew or the official Oracle download
• Set up your environment so the java command works anywhere in your terminal
• Verify the installation, uninstall if needed, and fix common issues

Whether you’re new to Java or just coming from another language like JavaScript, this guide will give you a clear path to getting Java up and running on macOS.

Check if Java is Already Installed#

Before installing Java, it’s worth checking if it’s already on your Mac. Maybe you’re not on your personal machine, or you installed it months ago for a side project and completely forgot.

To check if Java is already installed:

1. Open your Terminal
2. Type java -version
3. If Java is installed, you’ll see something like:

OpenJDK version 11.x

If it’s not installed, you’ll get a message like:

The operation couldn’t be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.

If you see the “Unable to locate” message, don’t worry — just continue with this guide to install Java on your Mac.

What is a JDK?#

If this is your first programming language, or if you’re like me, coming from another one — in my case, Javascript — you might not know much about the Java ecosystem. And honestly, you don’t really need to at first, right?

Still, because of assumptions, you might expect the installation to be as simple as running brew install java. But when you look it up, you’ll quickly see that the recommended way is to install a JDK instead. Before we continue, let’s take a quick look at what that actually is.

JDK – Java Development Kit is an open-source implementation of Java, maintained by big tech companies such as Oracle, Red Hat, and others.

When we refer to an open-source implementation, it simply means software built according to official rules. In this case, the rules come from the Java SE Specification.

So what does the JDK provide? It contains:

• Compiler – turns your .java files into an executable form called bytecode.
• Runtime (JVM) – executes that bytecode on any computer (Windows, Mac, Linux, etc.).
• Standard library – a huge set of built-in tools to help you out with your code.

It essentially has everything you need to use Java on your machine. The JDK is considered an essential tool for developers working with Java, and the OpenJDK project and Oracle distribute it.

Install Java on Mac#

You can install Java on macOS in two main ways:

1. Install Using Homebrew – quick and beginner-friendly
2. Install by Downloading from Oracle

If you’re new to Java or simply want the fastest setup, the Homebrew method is the best choice. (We have a separate post that walks you through installing Homebrew if you don’t have it yet.)

In this guide, we’ll use the Homebrew method.

To find out which is the latest version of Java, you can visit this page.

Install Java using Homebrew#

To install Java using Homebrew:

1. Update Homebrew Open your terminal and run: brew update This makes sure you’re working with the latest package list.
2. Install OpenJDK 21 After updating, run: brew install openjdk@21
3. Verify installation Open your terminal and run:

java -version

At the time of writing this guide, version 21 is the latest long-term support (LTS) release. If you want to install a different version, just replace 21 with the version number you need (for example, openjdk@17).

Optional: Read More About the Package You can check out the official Homebrew formula page for OpenJDK here.

Set JAVA_HOME Environment Variable#

After installing OpenJDK, you could have tried to verify the installation and found out that you still get

The operation couldn’t be completed. Unable to locate a Java Runtime.
Please visit http://www.java.com for information on installing Java.

In that case, you will need to add the Java home directory to your PATH. Since we installed OpenJDK@21, the command to add this to our PATH is

echo 'export PATH="/opt/homebrew/opt/openjdk@21/bin:$PATH"' >> ~/.zshrc

You’ll also see this message in the Homebrew installation logs for OpenJDK, near the end of the process.

What this command essentially does is prepend the existing list of paths with the directory where OpenJDK is installed. So when you ask it to run a java program, it will search first there.

If you installed a different version, change the version accordingly to the command above.

Verify Installation#

To verify our installation regardless of the method we used we should type java --version. By now you should be seeing

➜  ~ java -version
openjdk version "21.0.8" 2025-07-15
OpenJDK Runtime Environment Homebrew (build 21.0.8)
OpenJDK 64-Bit Server VM Homebrew (build 21.0.8, mixed mode, sharing)

Uninstalling Java (Homebrew)#

If you want to remove a specific version of OpenJDK installed via Homebrew, run:

brew uninstall openjdk@21

Checking Installed Versions#

To see all the Java versions (and other packages) you currently have installed, run:

brew list --versions

You might see something like this:

...
openjdk@17 17.0.12
openjdk@21 21.0.4
...

This means you have both Java 17 and Java 21 installed on your system.

Choosing an IDE for Java#

Now that you’ve installed Java, the next step is picking an Integrated Development Environment (IDE) to support your learning. An IDE helps you compile code, catch mistakes, and debug programs more easily — making your path to mastering Java smoother.

Some popular free choices include:

• IntelliJ IDEA Community Edition, published by JetBrains. This is my personal recommendation, since it’s beginner-friendly and offers a free edition.
• Eclipse, maintained by the Eclipse Foundation
• NetBeans, maintained by the Apache Foundation

Pick one of these tools, set it up, and you’ll be ready to start coding your very first Java programs with confidence!

Troubleshooting Common Issues#

Below are some common issues you might face when installing or using Java on macOS. If you’re dealing with a different problem and haven’t figured out the solution, drop it in the comments — we’ll try to help you out. Also, if you’ve solved a tricky Java issue yourself, share it in the comments so other readers can benefit too.

Wrong Java Version Running#

Cause: Multiple Java versions are installed, and the wrong one is first in your PATH. Fix: Check which Java is being used

which java

Then adjust your PATH so the version you want comes first. You can do that by typing:

export PATH="/opt/homebrew/opt/openjdk@<version-you-want>/bin:$PATH"

brew install fails#

Cause: Homebrew may be outdated or missing.

Fix: Update Homebrew:

brew update

If Homebrew is not installed, see our homebrew installation guide.

java Command Not Found#

Cause: OpenJDK is installed but not linked to your environment.

Fix: Link the installed version so the java command is available:

brew link --force --overwrite openjdk@21

If you installed a different version, replace 21 with that version number.

Keep reading#

• How to install Homebrew – MacOS for beginners
• How to Install npm on MacOS
• MacOS Shortcuts – Cheatsheet for New Users

For those of you looking for a TLDR answer: No! You are not too old! But I’m quite sure that doesn’t fully convince you—so let me explain.

My Late Start in Web Development#

Here’s a short story about me, just so you know we might have been walking a similar path.

I’m not 100% a tech person. I didn’t study Computer Science or anything related when I finished school. I started working in a completely different field—sales in supermarket goods. At some point, I went on to take an MSc in Information Systems, a program designed for non-tech people. It had no coding lessons related to web development.

I discovered web development while browsing sites like Coursera and edX—and I loved it. I was in my mid-30s at the time, and I asked myself the same question: Am I too old to learn coding? Let me tell you what I found out.

By the way, I’ve been working as a web developer for the past 7 years. So yes—there are success stories out there, and yours can definitely be one of them too!

You’re Not Starting from Zero#

This is 100% true—you’re not starting from zero. You might be thinking, “But I have no experience with programming. How can that be true?” Well, even if you’re new to coding, programming is about more than just writing code.

While you’ll focus on technical skills when learning for a job, that’s only part of what you’ll need to succeed in tech. Like any job, being a good developer also depends on other important skills, such as:

• Soft skills – How you communicate and work with your team.
• Product skills – How well you understand product requirements and how they should be built.
• People skills – How you interact with clients and stakeholders (the people asking for new features).
• Organizational skills – Coding isn’t just about typing code. It’s also about planning your work, breaking it into smaller tasks, staying focused, and delivering on time. Most teams do this through a framework with its own vocabulary, so it’s worth knowing what scrum is before your first sprint planning rather than during it.
• Life balance skills – Avoiding burnout, keeping a healthy routine, getting enough rest—these all matter too.

You might think this sounds like a lot—but it’s all true. If you want to grow into a great developer, you’ll need to develop more than just technical knowledge.

From what I’ve seen, the best developers aren’t always the ones who know every new framework or advanced technique. They’re often the ones who are humble, reliable, and great team players.

So if you feel like you have nothing to offer—think again! You already have experience, even if it’s not from the tech world.

• If you’ve been a taxi driver, you’ve learned how to stay patient and handle people in all situations.
• If you’re a mother, you’ve mastered multitasking and managing emotions—skills that come in handy at work too, especially with your managers!
• If you’ve been a gardener, you probably have a great eye for detail and know how to focus on repetitive tasks.

Every job teaches you something valuable. So now that we’ve cleared that up — you are skilled, let’s talk about age…

Too Old Compared to What?#

This is one of the most common — and most unrealistic — comparisons: “Am I too old?” Too old compared to who?

Are you 15? Then yes, you’re older than a 5-year-old. Are you 65? Then sure, you’re older than someone who’s 30.

But here’s the real question: You know who you’re younger than? The version of you a few years from now. I mean you can choose to start learning now—whether you’re in your teens, your 40s, or your 70s. Or you can wait… and reach your 30s, 60s, or 90s having never started.

So what’s the difference between the version of you who starts learning and the one who doesn’t?

Time will pass either way (Even Gandalf doesn’t help here).

Both versions of you will grow older. But only one will arrive at that next age with a new skill—or even a new career.

So why not start your path right now? Of course, you could avoid it. You could push it away.

What’s the Alternative?#

Well, there is one—and it’s a bit grim. I asked myself the same thing when I was wondering, “If I’m too old, what does that really mean?” The answer? You can just wait—wait until death comes sometime in the far future.

Don’t fight for your dreams! Just don’t!

Yes, do nothing. Don’t fight for your dreams. Don’t live the life you want. Don’t start learning and keep learning until you have no energy left. Just stay where you are and let time pass. Eventually, your journey will end.

Does that sound like something you would actually do? No, right? Because in reality, there is no real alternative. You either try — or you don’t. You could try and realize it’s not something you enjoy. Or you could find out it’s something that changes your life — because it turns out to be something you truly love doing.

The Learning Curve: Yes, It’s Real – and Beatable#

Ok, now we’re getting somewhere. But is it hard? Will you have tough times? Will you make it through?

Well, I have to be honest — being a programmer is a great profession to be in. Some of its advantages are:

Continuous learning—which can sometimes feel like a disadvantage too.

Great compensation, especially if you’re working fully remote.

Remote flexibility—wherever your laptop goes, you can go.

But it’s not all sunshine. Like any career, programming has its own set of challenges. In my opinion, the two most challenging aspects are the steep learning curve and impostor syndrome.

You might want to reflect a bit before diving in and ask yourself: Is programming really for me? If you’re unsure, don’t worry—we’ve got you covered with a post comparing its pros and cons in more detail.

Let’s talk about the learning curve first. It’s steep. You will feel overwhelmed—sooner or later. That depends on your personality, energy, and life situation. If you’re going through a tough period, it may hit harder.

Why is it so steep? Because there’s so much to learn—and even while learning, you may catch yourself thinking, I don’t know enough. Let me stop you right there: you will never know everything. And that’s perfectly normal.

When I first started, that exact fear hit me hard—How will I ever learn it all? Then I came across a tweet that changed my perspective. It went something like this:

Beginner programmers are anxious because of their uncertainty. Senior programmers find peace in the fact that they’ll never be certain.

That moment was eye-opening for me. I realized: this is just the nature of the game. No one knows everything—and that’s OK. The only thing that truly matters is to show up, keep learning, and keep having fun.

If you can combine fun with perseverance, you won’t lose — I promise.

But even if you’ve got the patience and the motivation to start… is there still a chance this might not work out?

What’s the Worst That Could Happen?#

Let’s be honest—there’s always a worst-case scenario. It might look different for each of you, but I’ll try to cover a few common ones that apply to many people starting this journey.

What If You Love Coding but Still Can’t Get a Job?#

Yes, this is a tough one. I’ve seen it happen, and I’ve been there myself. Let me tell you how I dealt with it.

When I first started applying for jobs, all employers saw on my CV was: sales, sales, and more sales. No one trusted me because I had no experience. Classic case of “no experience, but no way to get it either.”

At that point, I saw two possible options:

• Get a non-paid internship
• Start building a portfolio with real projects (like websites for friends, local businesses, or anything you can find)

For me, the internship route worked. I landed a 6-month unpaid internship that offered the chance for paid work afterward. Financially, it was a tough decision. But I took it—and it changed everything.

Suddenly, my CV didn’t just say “sales.” It showed real web development experience. The next time I applied for a job, I imagine employers were thinking, “Well, if he managed to work in one company, maybe he can work for us too.”

The day I started that internship was a great one.

What If You Try Coding and Don’t Like It?#

This is another real possibility. Not everything is for everyone. Maybe you love the thrill of the first lessons, but later you feel overwhelmed, bored, or just not that into it.

There are two ways this can go:

• You’re just hitting a tough spot and need to push through
• Or you’ve genuinely discovered that coding isn’t for you

If it’s the second one, that’s perfectly fine. You’ve now stopped wondering, “Am I too old to learn coding?”—because you’ve answered a more important question: “Is coding for me?”

And honestly, that’s a win too. Knowing what’s not for you is just as important as finding what is. Now you can move on to your next adventure, with no regrets—because you tried.

Ready to Start? Let’s Talk About Where to Begin#

So, now that you’re (hopefully) feeling more confident—not because there’s nothing to fear, but because you’re ready to commit even with those fears—where do you start?

Well, I can only speak for web development, not every path in programming.

Think of coding like becoming a doctor—there are many different specializations, and no one can explain them all at once. Don’t like that comparison? Try this: imagine walking into a chocolate shop for the first time. How do you figure out what you like? Simple—you start tasting.

From my point of view, the fastest route to getting a developer job is through frontend development.

In case you don’t know, a frontend developer is the person who builds what users see and interact with on a website. I believe it’s the quickest path because you can learn a few core building blocks and start seeing results fast. You’ll be able to create things, show them to potential employers, and feel a sense of progress early on.

This means faster feedback, less overwhelm, and a shorter path to your first job.

Once you’ve moved past the age question, the next step is figuring out if programming fits your personality. Learn how to decide if programming Is right for you.

Ready to start looking for your first role? Check out some of the Best Job Sites for Web Developers.

The clip-path: inset() is a way to restrict the visible area of an element by “pushing in” its sides from the element’s bounding box. This function doesn’t create a new shape as every element’s box is rectangular (and it can be a square if the width and height match), it just “trims” the existing one. The result is always a four-sided shape with right angles, which can be either a rectangle or, in special cases, a square.

Now, let’s proceed with a more detailed analysis and try out this amazing tool. For better understanding, I have prepared some practical examples for you. This is our “working area” for today! 👷‍♀️ 🏗 👷‍♂️

Clip-path: inset() function explained#

First things first. What does this mean? Well.. We need a rectangular or a square shape in order to work with clip-path: inset() CSS property.

The following code snippet and image illustrate how we create a simple black square with 200px width and 200px height.

/* square */
.square-shape {
  width: 200px;
  height: 200px;
  background-color: black;
  }

Inset accepts up to four values, each controlling how far the sides are pushed inward.

So, how about analyzing the different cases based on these values, and then proceeding with examples?

• One value: it applies to all four sides
• Two values: the first one is for top & bottom, while the second is for left & right
• Three values: the first one is for top, the second for left & right and the third for bottom
• Four values: the first one is for top, the second for right, the third for bottom and finally the fourth value is for the left side (clockwise, the same order as margin and padding).

We can now proceed with our examples. The code snippets and images that follow display these four cases.

First case – One value

.square-shape {
  ...
  clip-path: inset(50px);
  }

NOTE: ⬜ The gray color is used only for clarity, to distinguish the initial square from the clipped one. In practice, this part would be cut out (hidden).

Second case – Two values

.square-shape {
  ...
  clip-path: inset(20px 30px);
  }

.square-shape {
  ...
  clip-path: inset(20px 30px 10px);
  }

.square-shape {
  ...
  clip-path: inset(20px 40px 10px 30px);
  }

Making your elements smooth with rounded corners#

Apart from cropping, inset() allows you to round the corners of the clipped shape as well. This is achieved by adding the optional round keyword, followed by a radius value, which functions similarly to the border-radius CSS property. By utilizing it, we can transform the sharp corners into rounded ones.

As previously with the inset(), round takes up to four values, too.

• One value: it applies to all corners the same value
• Two values: they applied diagonal, the first one is for top-left & bottom-right corners, while the second is for top-right & bottom-left corners
• Three values: the first one is for the top-left corner, the second goes diagonally and is applied to both the top-right & bottom-left corners, and the third for the bottom-right corner
• Four values: the first one is for the top-left corner, the second for the top-right, the third for the bottom-right, and finally the fourth value is for the bottom-left corner (clockwise).

We move forward with our examples. The following code snippets and images display these four cases.

First case – One value

.square-shape {
  ...
  clip-path: inset(50px round 25px);
  }

.square-shape {
  ...
  clip-path: inset(50px round 0px 25px);
  }

.square-shape {
  ...
  clip-path: inset(50px round 0px 25px 10px);
  }

.square-shape {
  ...
  clip-path: inset(50px round 0px 25px 10px 20px);
  }

Apart from pixels, all values can also be written in percentages. The two units, px and %, can even be combined.

The following examples, along with their code snippets and images, illustrate these cases.

Using percentages as values

.square-shape {
  ...
  clip-path: inset(25% round 0% 25% 5% 10%);
  }

.square-shape {
  ...
  clip-path: inset(25% round 10px 30% 5% 60px);
  }

Well, something like a 🍋 lemon is here!! Cool, hug!?

Clip-path inset function – manipulating images#

Images can also be clipped, revealing only part of them, by simply utilizing the clip-path: inset() CSS property.

Below, we have an image of a bicycle 🚴‍♀️ out in nature. 🏞 Let’s say that we want to isolate the bicycle and display it within a rounded shape, pretty much like a frame. ✨

Depending on our prefrences, we cut away the unnecessary parts. First, our initial square image turns into a rectangle. After that, we add the round with a value of 50% which gives the remaining part a smooth, nicely rounded shape.

NOTE: To make things more straightforward, I’ve prepared an image with colored code and overlays 🎨 ✂ showing which values correspond to the parts we cut away.

.image {
  ...
  clip-path: inset(47px  14px  7px  20px  round 50%);
  }

Now we see just the bicycle kept in view, while everything else is clipped out. Exactly the effect we want to achieve.

Voila!! There we have it! Our final updated image!! 🥳 Ready to be styled even more with all those amazing CSS properties!

Keep reading#

• clip-path: circle() Explained
• Clip-path For Quick Polygons – Ready Code-To-Copy
• CSS Folded Corner Effect with clip-path

The clip-path accepts several values: circle(), ellipse(), polygon(), and inset(). These values define the shape of the clipping path applied to an element and we utilize them depending on the shape we want to create each time. Specifically, in today’s post, we will learn how to clip an element into a triangle shape by setting the clip-path: polygon().

Clip-path polygon() function explained#

It’s time to continue and focus on our triangles. Let’s proceed with the example I prepared and see how this special tool works. 🪄 Below we have a black square. We used to create squares by setting the width and height CSS properties, but for today, let’s see how we can replace them with the clip-path property.

Take a look below. I begin with a ⬛ square, making it easier to understand our function as squares (boxes) are the most familiar shapes in CSS. Then I will transform this square into a 📐 triangle. The color code shows how we position the square along both the X-axis and Y-axis. The colored points on the corners represent the clipping region.

🖇 Despite having three magenta points and one green point, for now, all points behave the same. The differentiation of the green point will be meaningful later and hold significance for the following stages in our work.

Each pair of values inside the clip-path: polygon() function represents a point, and all these points together define a clipping region.

Create right triangles#

Now, let’s see how we can transform it into a triangle. The square has four corners (points) while the triangle has three corners. Depending on the type of triangle we want to create, we need to cut the corresponding corner. In my example, I create a right triangle. I cut the top-right corner (100% 0%). As you can see in the following image, cutting this corner, we have the triangle we need.

What do you think? It looks good! Isn’t it? 😎 With just a simple line of code!

🔖 I opted to clip the top-right corner (100% 0%). Alternatively, it would also be correct to clip the top-left corner (0% 0%), the bottom-right corner (100% 100%), or the bottom-left corner (0% 100%). All these clippings yield the same result, so you can choose the one that best fits your preferences. Additionally, you can use transform: rotate to adjust the orientation as needed.

With our triangles now in place, let’s explore how we can move them along both axes and discover the variety of triangles we can create.

Create isosceles triangles#

We move forward by keeping the initial design where we cut the top-right corner (100% 0%). We will work with this triangle.

To start, I’ve chosen to create isosceles triangles. This involves first focusing on the remaining top-left corner and then on the remaining bottom-right corner. Don’t worry and don’t feel confused, we’ll clear everything up. As mentioned above, the code and diagrams for clarity are ready!

As you can see below, we maintain the bottom corners as they are, and we change the remaining top-left corner, where we move it right to 50% along the X-axis. By doing so, we transform our right triangle into an isosceles triangle.

clip-path: polygon(
           50% 0%,
           100% 100%,
           0% 100%);

This right triangle can give us one more isosceles triangle. We maintain the top-left and bottom-left corners, and we change the bottom-right corner by moving it up to 50% on the Y-axis.

clip-path: polygon(
           0% 0%,
           100% 50%,
           0% 100%);

Create acute triangles#

We continue with the acute triangles. Once again, we maintain the bottom corners as they are, and we change the remaining top-left corner. Here, we have two cases. First, we move it right to 15% along the X-axis, while in the second case, we move it right to 85%. By doing so, we transform our right triangle into acute triangles. Depending on our preferences.

clip-path: polygon(
           15% 0%,
           100% 100%,
           0% 100%);

clip-path: polygon(
           85% 0%,
           100% 100%,
           0% 100%);

Another approach is to work with the bottom-right corner and adjust the values on the Y-axis. Let’s see how our triangle will become then. I move the bottom-right corner first up to 35% and then up to 65%.

clip-path: polygon(
           0% 0%,
           100% 35%,
           0% 100%);
           /* OR */
clip-path: polygon(
           0% 0%,
           100% 65%,
           0% 100%);

🔖 The values I use to create the triangles are indicative. Feel free to choose any value that suits your preferences and requirements. 😃

Create obtuse triangles#

Finally, it’s time to work with the bottom-left corner. We leave the top-left and bottom-right corners unchanged while modifying the values of the bottom-left corner. Initially, I adjust the X-axis value, shifting the corner right to 20%. Next, I adjust the Y-axis value, moving the corner up to 80%.

clip-path: polygon(
           0% 0%,
           100% 100%,
           20% 100%);

clip-path: polygon(
           0% 0%,
           100% 100%,
           0% 80%);

Keep reading#

• Clip-path For Quick Polygons – Ready Code-To-Copy
• CSS Arrow Shapes with clip-path
• clip-path: circle() Explained

The clip-path property allows us to cut ✂ an element to a shape of our choice by specifying a series of points. It takes many values, but in our case, we will use the clip-path: polygon() function. I’ll briefly note circle(), ellipse(), and inset() which are the rest of the functions. In this post, we will analyze how we can create navigation signs only.

Clip-path: polygon() function explained#

It would be an excellent start to examine the syntax of this amazing tool. Below I’ve illustrated the code along with explanatory diagrams. The first one shows how we can make a square setting the clip-path: polygon() function. We used to create square shapes ⬛ by simply setting the width and height CSS properties. However, I opted to use the clip-path to utilize its familiarity and improve clarity. 😎 I used colored code to show you how we measured on both the axis-X and axis-Y. Each pair of values represents a point, with the first value indicating the horizontal position and the second value indicating the vertical position. Then an image accompanied the code and display a series of colored points illustrate how we form our visual element.

“Clip-path is extremely flexible. We can create any shape we desire from scratch, but we can also apply it to existing shapes and create transformations of our choice”.

The second case shows how we can transform the square into a directional sign that points to the top. Again, the clip-path: polygon function is defined by coordinates relative to the element’s bounding box, but this time it is a bit harder. 🤯 Don’t worry, I am here to clarify for you! 🤓

• It starts at the top-middle (50% 0%).
• Then it moves diagonally down and right (70% 25%).
• From there, it continues straight down (70% 100%) where it turns diagonally again for two times in a row.
• First up and left (50% 75%), then down and left (30% 100%).
• Finally, it moves straight up (30% 25%) where it completes its movements.

These one-direction moves enable you to create complicated shapes by strategically placing each point to outline the desired polygonal form. This method allows for precise control over the path of the shape, facilitating the design of visually appealing and geometrically complex elements on web pages.

Ready-to-copy code snippets#

Below, I have prepared ready-to-copy code for directional signs. Feel free to use it everywhere you need. Enjoy! 🎊

Directions#

Ready code and explanation diagrams for directions.

Direction to Up#

clip-path: polygon(
           50% 0%,
           70% 25%,
           70% 100%,
           50% 75%,
           30% 100%,
           30% 25%);

Direction to Down#

clip-path: polygon(
           30% 0%,
           50% 25%,
           70% 0%,
           70% 75%,
           50% 100%,
           30% 75%);

Direction to the Left#

clip-path: polygon(
           25% 30%,
           100% 30%,
           75% 50%,
           100% 70%,
           25% 70%,
           0% 50%);

Direction to the Right#

clip-path: polygon(
           0% 30%,
           75% 30%,
           100% 50%,
           75% 70%,
           0% 70%,
           25% 50%);

🔖 We are always free to skip all these signs and create just one, 😇 to show only one direction, then we can rotate it until it aligns with our preferences.

Arrows#

Ready code and explanation diagrams for arrows.

Arrow up#

clip-path: polygon(
           50% 0%,
           100% 25%,
           75% 25%,
           75% 100%,
           25% 100%,
           25% 25%,
           0% 25%);

Arrow down#

clip-path: polygon(
           25% 0%,
           75% 0%,
           75% 75%,
           100% 75%,
           50% 100%,
           0% 75%,
           25% 75%);

Arrow to the left#

clip-path: polygon(
           25% 0%,
           25% 20%,
           100% 20%,
           100% 80%,
           25% 80%,
           25% 100%,
           0% 50%);

Arrow to the right#

clip-path: polygon(
           75% 0%,
           100% 50%,
           75% 100%,
           75% 80%,
           0% 80%,
           0% 20%,
           75% 20%);

Points#

Ready code and explanation diagrams for points.

Point up#

clip-path: polygon(
           50% 0%,
           100% 25%,
           100% 100%,
           0% 100%,
           0% 25%);

Point down#

clip-path: polygon(
           0% 0%,
           100% 0%,
           100% 75%,
           50% 100%,
           0% 75%);

Point left#

clip-path: polygon(
           25% 0%,
           100% 0%,
           100% 100%,
           25% 100%,
           0% 50%);

Point right#

clip-path: polygon(
           0% 0%,
           75% 0%,
           100% 50%,
           75% 100%,
           0% 100%);

Keep reading#

• Clip-path For Quick Polygons – Ready Code-To-Copy
• CSS Triangles with clip-path
• clip-path: circle() Explained

Clip-path CSS property supports several shapes. Depending on the shape we want to create we have the following options: circle(), ellipse(), inset(), and polygon(). In today’s post we’ll spend time on clip-path: polygon() as this enables us to clip an element into a polygon shape.

Clip-path polygon() function explained#

To illustrate the clip-path: polygon() CSS property I chose to start with a square, as it is the most common type of polygon. Below, we can see the code marked with colors. Each pair of values, inside the parentheses, symbolizes a point. In our case, we have four pairs of values, hence we have a shape with four points (square). The four color points represent the clipping area and display how we position the square on both axes X and Y.

/* square */
clip-path: polygon(
           0% 0%,
           100% 0%,
           100% 100%,
           0% 100%);

Below is ready-to-copy code for polygons. Feel free to use it wherever you need! 🤗

Create pentagon#

/* pentagon */
clip-path: polygon(
           50% 0%,
           100% 40%,
           80% 100%,
           20% 100%,
           0% 40%);

/* pentagon oriented downward */
clip-path: polygon(
           20% 0%,
           80% 0%,
           100% 60%,
           50% 100%,
           0% 60%);

Create hexagon#

/* hexagon vertical */
clip-path: polygon(
           25% 0%,
           75% 0%,
           100% 50%,
           75% 100%,
           25% 100%,
           0% 50%);

/* hexagon horizontal */
clip-path: polygon(
           50% 0%,
           100% 25%,
           100% 75%,
           50% 100%,
           0% 75%,
           0% 25%);

Create heptagon#

/* heptagon */
clip-path: polygon(
           50% 0%,
           90% 20%,
           100% 60%,
           75% 100%,
           25% 100%,
           0% 60%,
           10% 20%);

/* heptagon oriented downward */
clip-path: polygon(
           25% 0%,
           75% 0%,
           100% 40%,
           90% 80%,
           50% 100%,
           10% 80%,
           0% 40%);

Create octagon#

/* octagon */
clip-path: polygon(
           30% 0%,
           70% 0%,
           100% 30%,
           100% 70%,
           70% 100%,
           30% 100%,
           0% 70%,
           0% 30%);

Create nonagon#

/* nonagon */
clip-path: polygon(
           50% 0%,
           83% 12%,
           100% 43%,
           94% 78%,
           68% 100%,
           32% 100%,
           6% 78%,
           0% 43%,
           17% 12%);

/* nonagon oriented downward */
clip-path: polygon(
           32% 0%,
           68% 0%,
           95% 23%,
           100% 57%,
           85% 87%,
           50% 100%,
           15% 87%,
           0% 57%,
           5% 23%);

Create decagon#

/* decagon */
clip-path: polygon(
           50% 0%,
           80% 10%,
           100% 35%,
           100% 65%,
           80% 90%,
           50% 100%,
           20% 90%,
           0% 65%,
           0% 35%,
           20% 10%);

Adjust polygon rotation for simplicity#

To make things easier, we are free to create only one type of shape at a time and adjust its direction by customizing its orientation. For instance, as demonstrated below, we can use a decagon shape, which is the last shape we created above, and modify its degrees through the transform: rotate() CSS property. In that way, we set the orientation according to our preferences.

More specifically:

• In case 1, we notice our decagon rotating 90 degrees to the right
• In case 2, with the use of a negative value, our decagon moves anticlockwise and rotates 90 degrees to the left
• In case 3, it rotates 180 degrees to the right, resembling a downward orientation

🔖 Pay attention to how the colorful dots shift from one place to another, updating their positions each time we change the rotating value. 🥳

/* case 1 */
transform: rotate(90deg);
/* case 2 */
transform: rotate(-90deg);
/* case 3 */
transform: rotate(180deg);

Keep reading#

• CSS Triangles with clip-path
• CSS Arrow Shapes with clip-path
• clip-path: circle() Explained

A great tool for creating unique layouts, applying image effects, and designing custom shapes. CSS supports several shapes for clip-path, including circle(), ellipse(), inset(), and polygon()—each giving you different ways to shape your content and hide any parts you don’t need. 🪄

In today’s post, we’ll focus on the circle() ⚫ function and explore how it works. 🧐 Let’s dive in!

The circle() function#

The circle() function is one of the simpler ways to create circles by clipping an element into a rounded shape with a radius of our preference based on the element’s smaller dimension (width or height, selecting the smaller one, ensuring the circle fits within the element). Traditionally, we can use pixels px and percentages % to define the dimensions and the position of the circle. Otherwise, we can just utilize the handy center keyword, which is responsible for positioning our circle.

Below, we see the starting setup we’ll use to explore this awesome CSS property. It shows a dark grey square, with a width and height of 200px. Also, a small white dot marks its center. This allows us to visualize exactly how the circle is positioned. The square is placed on an axis to make things even clearer. This helps explain both positioning and how the circle will be clipped inside it (inside the square element). 📐 😃

The circle(radius at axis-X axis-Y) function using pixels and percentages#

It defines a circular clipping area using two values: the radius of the circle and its center point. We set the radius to 100px wide or 50% of the element’s width, and we positioned it 100px from the left and 100px from the top of the element or 50% 50%, which places the circle right in the element’s center. Everything outside the circle will be invisible. This creates a circle that is perfectly centered within the square.

.circle {
      /* circle(radius at axis-X axis-Y) */
clip-path: circle(100px at 100px 100px);
}
              /* OR */
.circle {
   /* circle(radius at axis-X axis-Y) */
clip-path: circle(50% at 50% 50%);
}

Now, let’s try to cut ✂ a smaller circle. Maybe with a radius of 80px. How would our code and circle look now? Check out the updated code snippet below.

We’re still cutting out a specific shape, a circle, from the element, but this time the circle is smaller (radius of 80px or 40% of the element’s width), though it is centered at the same spot as before (100px from the left and 100px from the top or 50% 50%). That means the circle stays perfectly centered within the square.

.circle {
clip-path: circle(80px at 100px 100px);
}
              /* OR */
.circle {
clip-path: circle(40% at 50% 50%);
}

🔖 Bear in mind that we can combine pixels with percentages, too. E.g. clip-path: circle(80px at 50% 50%);

Using % instead of pixels, it makes our shapes responsive and adjusts to the size of our elements each time. In that way, our designs are more flexible and adaptable to different screen sizes.

The circle(radius) function#

Another way to create circles using clip-path is the circle(%). It clips the element into a perfect circle with a radius of our preference. Additionally, since you do not specify a position, it centers by default at 50% 50% (50% horizontally and 50% vertically).

Below, we have two examples. The first one has a radius of 50%, while the second has a radius of 40%, allowing for easy comparison with the previous examples.

.circle {
clip-path: circle(50%);
}
      /* OR */
.circle {
clip-path: circle(40%);
}

The circle(radius at center) function using the ‘center’ keyword#

It defines a circular clipping area using the radius and the keyword center. Using this method, we create a circle with a 100px radius perfectly 🎯 centered inside the element. Anything outside that circle will be hidden.

🔖 Note that setting the center it is the same as writing 50% 50%, maintain a cleaner and clearer code. ✨

.circle {
  clip-path: circle(100px at center);
}
            /* OR */
.circle {
clip-path: circle(50% at center);
}

Likewise, if we create a smaller circle.

.circle {
  clip-path: circle(80px at center);
}
            /* OR */
.circle {
clip-path: circle(40% at center);
}

clip-path: circle() VS border-radius#

Now, let’s see why we are utilizing the clip-path instead of simply relying on the border-radius CSS property. As we mentioned earlier, when setting the clip-path, we deal with two main values: the radius, similar to what border-radius offers, and the positioning, which is particularly important if we want to create a circle that is not 🎯 centered within the element.

Let’s create our circle again, with a radius of 80px or 40% (depending on your preferences – if you use px or %). Next, position it, but not in the center of our element (50% 50%).

🔶 If we want the visible part to be closer to the top side, we keep axis-X at 50%, but we change the axis-Y from 50% to 40%. 🔶 If we want the visible part closer to the left side, we keep the axis-Y at 50%, but we will change the axis-X from 50% to 40%.

.circle {
     /* circle(radius at axis-X axis-Y) */
  clip-path: circle(80px at 50% 40%);
}
              /* OR */
.circle {
  clip-path: circle(40% at 50% 40%);
}

.circle {
   /* circle(radius at axis-X axis-Y) */
  clip-path: circle(80px at 40% 50%);
}
              /* OR */
.circle {
  clip-path: circle(40% at 40% 50%);
}

Setting clip-path instead of border-radius gives us the privilege to focus on any part of our element we prefer, not just the center. A really useful method, especially when working with images 📸 and you want to keep a part of the image that is not necessarily at the center.

Let’s examine another case. What do you think? Are we able to vanish 🎩🐇 a whole piece of our circle and keep only a small part if needed? Let’s see the following code snippet. We position the center of the circle at zero (0%) on both axis. This means that the center of our circle will be placed at the top-left corner of the initial element, as that’s the point where both axes X and Y begin.

.circle {
clip-path: circle(80px at 0% 0%);
}
              /* OR */
.circle {
clip-path: circle(40% at 0% 0%);
}

Take a closer look at the image below. Since the circle is positioned at the element’s top-left corner, only the 🕞 quarter of the circle that fits within the element’s bounds will be visible, all the rest, that is extended beyond the element’s boundaries, will not be displayed at all. Cool hug! 😎

Apply clip-path to images#

Now it’s the perfect time to analyze how we can utilize clip-path with images. A clever way to control their shape and also ‘cut out’ and leave in view only a specific part of the image.

In the following example, we’re working with an image that contains four avatars, each placed in one of the image’s corners: top-left, top-right, bottom-left, and bottom-right. The image is divided into four equal parts, with one avatar in each. By using the clip-path: circle() function, we can focus on just one avatar at a time.

First, we apply clip-path: circle() to cut out the top-right part of the image, revealing only the avatar placed there. Then, we do the same for the top-left corner to show the avatar in that section. We repeat this process for the bottom-left and bottom-right parts as well, effectively isolating each avatar with a circular crop.

Depending on the visual balance and spacing, you can choose 45% (blue 🔵 border) to match the exact size of the avatar or go with 50% (green 🟢 border) to include a bit of extra white space from the image background for a more relaxed look. 🌈 😎

To target and isolate each avatar at the top of the image:

🔶 For the top-left avatar, we place the circle’s center at 25% 25%. This moves the circle’s center closer to the top-left side of the image.

🔶 For the top-right avatar, we set the position at 75% 25%. This turns the focus to the top-right area of the image.

Adjusting these percentages gives you fine control over what part of the image stays visible, allowing you to highlight exactly what you want.

.circle {
    /* circle(radius at axis-X axis-Y) */
clip-path: circle(45% at 25% 25%);
}
              /* OR */
.circle {
clip-path: circle(50% at 25% 25%);
}

.circle {
    /* circle(radius at axis-X axis-Y) */
clip-path: circle(45% at 75% 25%);
}
              /* OR */
.circle {
clip-path: circle(50% at 75% 25%);
}

Below we can see the final results for the two avatars. The first image displays only the first avatar while the second presents only the second one. All the rest of the avatars will be hidden. Pretty cool, right?

This technique allows us to pinpoint and display specific parts of the image. Then, with the necessary positioning, we put this specific part of the image in our desired place. 😃 ✨

Keep reading#

• Clip-path For Quick Polygons – Ready Code-To-Copy
• clip-path: inset() Explained
• CSS Folded Corner Effect with clip-path

A good percentage of internet users often portray cookies as harmful. Mostly because people feel that someone is tracking their behavior while visiting a site — and yes, to some extent, this is true. But have you ever stopped to wonder: why are internet cookies called cookies? Why not use some other kind of delicacy? Like tarts or donuts? 🤭

The Legacy of Montulli’s Internet Cookies#

To fully answer why are internet cookies called cookies, we need to start with Lou Montulli, one of Netscape’s founding engineers.

In 1994, Montulli introduced browser cookies as a technical solution to a frustrating problem: websites had no memory. Each time you loaded a new page, the website had no idea who you were or what you’d done moments earlier — it couldn’t remember if you had logged in, or what items you’d placed in your shopping cart. This limitation made building useful, user-friendly web experiences nearly impossible.

Montulli’s solution was simple. He stored small pieces of data in your browser. These allowed websites to “remember” things between visits and page loads. This idea — storing small amounts of information to improve the user’s experience — became a turning point in the history of the web.

But why are internet cookies called cookies and not something else? Montulli himself has explained that while he was brainstorming, he recalled a term from his college days in computer science: “magic cookies.”

As mentioned in Montulli’s blog post

I had heard the term “magic cookie” from an operating systems course from college. The term has a somewhat similar meaning to the way Web Cookies worked and I liked the term “cookies” for aesthetic reasons. Cookies was the first thing I came up with and the name stuck.   

Lou Montulli

Many say Montulli also drew inspiration from fortune cookies 🥠 — little treats containing small hidden messages. Similarly, browser cookies contain small packets of information about the user. However, Montulli clarified that the fortune cookie analogy was secondary; the real naming influence came from established computing terminology.

Magic cookies, LSD, and Unix users#

The term “magic cookie” existed long before internet cookies, and understanding this connection helps clarify why are internet cookies called cookies today.

In programming, systems often pass a magic cookie — a small piece of data — between each other as a kind of identifier or token. The recipient doesn’t care what’s inside the cookie. Programmers took this idea from early computing.

The term magic cookie appears in the Unix Programmer’s Manual. It helps explain how functions like ftell() and fseek() track file positions using seemingly random numbers. To many programmers, these cookies felt like magic because they just worked.

ftell returns the current value of the offset… It is measured in bytes on UNIX; on some other systems it is a magic cookie, and the only foolproof way to obtain an offset for fseek.   

Unix documentation

Montulli liked the term “cookies” partly because of this existing technical jargon and partly because of its playful, light-hearted sound.

For added flavor, some point to the 1970s hacker culture, Unix communities, and counterculture comics like Odd Bodkins by Dan O’Neil. In these circles, magic cookies were tokens with mysterious, sometimes surreal, properties — much like the arbitrary bits of data passed between systems.

So, when asking why are internet cookies called cookies, the answer is clear. It comes from a blend of technical tradition, playful naming, and Montulli’s own preferences.

The Cookie Monster Connection 🍪#

It’s hard to discuss cookies without mentioning Cookie Monster from Sesame Street. He devours cookies mindlessly. Browsers behave in a similar way, silently gobbling up cookies in the background. This connection is mostly playful. Still, it helped reinforce the idea of “cookies” being small, harmless, and consumed without much thought. That light-hearted image made the term easier for people to accept at the time.

Why Are Internet Cookies Called Cookies? — A Quick Recap#

• Lou Montulli introduced browser cookies in 1994 to give websites “memory.”
• He drew on the existing programming term “magic cookies” as inspiration.
• The term “cookies” was already familiar in tech, playful, and non-threatening.
• Fortune cookies served as a fitting metaphor but weren’t the primary reason.
• Why are internet cookies called cookies? Because it combines tech history with simplicity and charm.

While researching for this post, I stumbled upon an insightful Youtube video discussing hidden heroes like Montulli created by Netguru. I recommend giving it a watch as it delves deeper into Montulli’s journey in pioneering the first-ever cookies.

If you’re into history-related programming trivia, you might also enjoy this post about the origin of the word “bug” in programming. It’s another quirky and surprising piece of tech history that shows how language shapes the tech world we live in today.

Keep reading#

• How Password Hashing Works
• Why Invalid Card Numbers Fail Instantly

I switched to macOS from Ubuntu Linux, and honestly the first week was humbling. Muscle memory I’d built over years suddenly did nothing, or worse, did the wrong thing. So this started as my own notes, and it grew from there.

🔑 First, learn to read the symbols#

Before the shortcuts themselves, this one thing trips up almost everyone. Apple writes shortcuts using symbols rather than words, and menus in every app use them. Once you can read them, you can discover shortcuts on your own just by opening a menu.

So when a menu shows ⇧⌘4, that reads as Shift + Command + 4. That’s it — that’s the whole trick.

🔄 Basic Editing macOS Shortcuts#

✍️ Moving around text quickly#

These are the ones that made the biggest difference to my daily typing, and they’re rarely in beginner lists. They work in almost every text field on macOS, including most code editors.

If you came from Windows, note that Home and End don’t behave the way you expect on a Mac. Command + Left and Command + Right are what you actually want.

The Option key has a second job worth knowing about too: held on its own it types special characters rather than moving the cursor, which is how you get the copyright symbol and friends — © is Option + G, ™ is Option + 2.

👨‍💻 Developer – Focused macOS Shortcuts#

In Safari, DevTools only appears once you enable the Develop menu: Safari → Settings → Advanced → Show features for web developers. This catches out a lot of people who assume the shortcut is broken.

💻 Productivity macOS Shortcuts#

📸 More on screenshots#

Screenshots have more depth than the two shortcuts above suggest, and this is genuinely worth two minutes of your time:

• Command + Shift + 3 — the entire screen.
• Command + Shift + 4 — drag to select a region.
• Command + Shift + 4, then Space — the cursor becomes a camera; click any window to capture just that window, with a tidy drop shadow. This is the one I use for blog posts.
• Command + Shift + 5 — opens the full capture toolbar, including screen recording and a timer.

Add Control to any of these to copy the result to your clipboard instead of saving a file to the Desktop. So Control + Command + Shift + 4 selects a region and puts it straight on the clipboard, ready to paste.

🪟 Window and app management#

The distinction between Command + W and Command + Q matters more on macOS than on Windows. Closing the last window of an app usually doesn’t quit it — the app stays running, which is why you sometimes see apps in the Dock you thought you’d closed. If you’re wrestling with a window that won’t leave full screen, there’s a dedicated guide to exiting full screen on Mac.

📁 Finder shortcuts worth knowing#

That first one — Command + Shift + period — is essential for developers. It toggles hidden files, which is how you actually see .env, .gitignore and .zshrc in Finder. I looked for this for an embarrassingly long time.

The last one solves something that confused me for weeks: macOS has no “Cut” for files. You copy with Command + C, then paste-as-move with Command + Option + V.

🔤 Other Useful Shortcuts#

🔁 Coming from Windows? Start here#

If you’re switching rather than starting fresh, this table probably saves you the most time. Most of the pain is that Ctrl became Command, but a handful genuinely differ.

⚙️ Make your own shortcuts#

Once the built-in ones feel natural, you can assign your own to any menu item in any app. It’s buried, so here’s the path:

System Settings → Keyboard → Keyboard Shortcuts → App Shortcuts → +

Pick the app, type the menu item’s name exactly as it appears in the menu, then press the key combination you want. The exact-match part is the bit everyone gets wrong — “Save As…” with the three-dot ellipsis character will not match if you typed three full stops.

Frequently asked questions#

Why doesn’t my F-key do anything?#

By default the top row controls brightness, volume and so on. Hold fn to use them as real F1–F12 keys, or flip the default in System Settings → Keyboard → “Use F1, F2, etc. keys as standard function keys”.

Where do my screenshots go?#

To the Desktop by default, named with the date and time. Press Command + Shift + 5 and use the Options menu to change the destination — mine goes to a dedicated folder so the Desktop stays clean.

Is there a way to see an app’s shortcuts?#

Yes, and it’s the best habit to build: just open the app’s menus. Every command that has a shortcut shows it on the right using the symbols from the table at the top of this post. That’s why learning ⌘⌥⇧⌃ first pays off — after that, every app documents itself.

Since I’m still fairly new to macOS after switching from Ubuntu Linux, I’ve been collecting these shortcuts to help myself — and hopefully to help you too.

Keep reading#

• How to Type the Copyright Symbol on Mac — the Character Viewer shortcut above, put to work
• How to Close a Full Screen on Mac
• How to install Homebrew – MacOS for beginners

Introduction: Why use Husky hooks in your project?#

Husky is a great tool to help you out when working on a project and being proactive. It can catch problems before they are committed and make it into your codebase.

How? By running scripts like tests or linters when committing or pushing your code. It’s a simple way to enforce code quality.

But why not just use native Git hooks or a CI tool like CircleCI or GitHub Actions, you might wonder… and honestly, that’s a fair question — I asked the same thing when I first came across Husky.

The answer really comes down to when you want to catch issues in your code, and whether you’re comfortable setting up native Git hooks or working with a team where shared, versioned hooks make more sense.

Do you want to wait for your CI tool to run all steps just to tell you a test failed or a semicolon was missing? Or would you rather know right away, before even pushing your code? ⚡

What are you waiting for if you’d like to catch issues immediately? 🚀 Let’s go ahead and install Husky and learn more about this cool tool! 🛠️🐶

Installing and initializing Husky in your project#

Installing Husky is straightforward; you just type in your terminal

npm install --save-dev husky