DEV Community: A. Moreno

Things You Notice After Inspecting 100 Websites

A. Moreno — Sat, 07 Mar 2026 23:33:16 +0000

At some point every front-end developer develops a strange habit: opening the inspector on random websites.

You visit a page, press F12, and suddenly you're not looking at the content anymore. You're looking at the layout, the scripts, the fonts, and the questionable CSS decisions someone probably made late at night.

After inspecting enough sites, patterns start to appear. Different companies, different stacks, different design teams. Yet many things end up looking surprisingly similar under the hood.

Here are a few things you start noticing after inspecting a lot of websites.

Everyone Uses the Same Layout Tricks

No matter how unique a website looks visually, the layout underneath is usually built with the same few tools.

Most modern sites rely heavily on:

Flexbox for alignment
CSS Grid for structured layouts
A lot of div elements

Example:

.container {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

Even complex landing pages often boil down to nested flex containers and a few grid layouts.

The design may look unique, but the layout mechanics are usually very familiar.

There Is Almost Always More CSS Than Necessary

Another thing that becomes obvious quickly: unused CSS.

Large websites often ship styles that are never applied to anything on the page. This usually happens because projects evolve over time.

Common causes include:

Legacy styles that were never removed
Components that are no longer used
Automatically generated utility classes

If you scroll through the styles panel in developer tools, it is common to find thousands of lines of CSS where only a small portion is actually active on that page.

This kind of technical debt slowly accumulates as projects grow.

Fonts Are Doing a Lot of Heavy Lifting

Typography is a huge part of modern web design, and you notice that quickly when inspecting network requests.

Many websites load multiple font files just to render text.

Typical patterns include:

Several font weights
Multiple font formats
Fonts loaded from external CDNs

Example:

font-family: "Inter", system-ui, sans-serif;

What looks like simple text on the screen can involve multiple network requests behind the scenes.

Analytics Scripts Are Everywhere

Open the Network tab on almost any site and you will likely see at least one analytics script loading.

Common examples include tracking scripts, tag managers, and marketing integrations.

Sometimes a simple landing page loads several third-party scripts before anything meaningful appears on the screen.

From a developer perspective, this can be surprising. The visible page might be simple, but the background activity can be extensive.

Many Websites Are Built With the Same Stack

Another interesting discovery is how often the same tools appear across different websites.

You might inspect ten completely different sites and still encounter the same technologies repeatedly.

Some very common patterns include:

React-based front-end applications
Static deployments on modern hosting platforms
Utility-first CSS frameworks

Once you start recognizing these patterns, identifying the stack behind a site becomes easier.

Developer Tools Become Your Second Pair of Eyes

Inspecting websites changes the way you browse the web.

You stop seeing pages as static designs and start noticing the structure underneath them.

Margins, layout containers, font loading strategies, network requests. Everything becomes part of the experience.

And sometimes the most valuable insight is simply realizing that even large, professional websites are built with the same fundamentals you use every day.

What I Learned

Inspecting websites is one of the simplest ways to learn more about front-end development.

You do not need a complex project or a large codebase. Just open developer tools, explore the DOM, check the styles, and see how things are built.

The more sites you inspect, the more patterns you start recognizing.

And once you see those patterns, the web starts to feel a lot less mysterious.

AI Is Taking Jobs. So What Should Developers Do?

A. Moreno — Wed, 25 Feb 2026 22:21:56 +0000

Let’s be honest. AI is changing the industry fast. Tasks that used to take hours can now be done in minutes. Code gets generated instantly. Documentation writes itself. Simple bugs are fixed by a prompt.

And yes, some roles are already being reduced or reshaped because of it.

It’s easy to panic. It’s easy to think, “What if I get replaced?” But that question alone is the wrong focus. The better question is: “How do I evolve with this?”

AI is very good at patterns. It’s good at repetition. It’s good at generating predictable solutions. But software development has never been only about writing code. It’s about understanding problems, making trade-offs, communicating with people, and building systems that survive real-world complexity.

The developers who are at risk are not the ones who use AI, it’s the ones who ignore it or rely on it blindly.

If you treat AI as a shortcut to avoid learning, you weaken yourself. If you treat it as a tool to accelerate learning, you become stronger. There’s a big difference.

You still need to understand architecture. You still need to know why something works. You still need debugging skills, system thinking, and the ability to question output. AI can generate code, but it doesn’t carry responsibility. You do.

The industry is not eliminating developers. It’s eliminating certain types of tasks. The repetitive ones. The purely mechanical ones. That means the value is shifting upward — toward critical thinking, design decisions, product understanding, and business awareness.

So what should you focus on?

Learn how systems work, not just syntax.
Understand infrastructure basics.
Improve communication skills.
Practice reading and reviewing code critically.
Use AI daily, but don’t let it think for you.

Staying optimistic doesn’t mean ignoring reality. It means adapting to it. Every major technological shift has created fear before creating opportunity. Developers who adapted to the web survived. Those who adapted to mobile survived. Those who adapted to cloud survived.

This is just another shift.

Your job is not to compete with AI. Your job is to become the kind of developer who knows how to work with it; strategically, responsibly, and intelligently.

The future still needs developers. It just needs better ones.

"I Messed Up My Resume. What Now?" This Is How to Fix It.

A. Moreno — Wed, 25 Feb 2026 21:55:10 +0000

At some point, most developers realize something uncomfortable:

Your resume doesn’t actually reflect your level.

Maybe it’s outdated. Maybe it’s bloated with tools you barely used. Maybe it undersells what you’re actually good at. Or worse, it tries too hard to sound impressive and ends up sounding generic.

I recently went through a full resume cleanup. Here’s what I learned.

1. Stop Listing Everything You’ve Ever Touched

Early in your career, it feels impressive to list:

Every framework
Every editor
Every tool
Every cloud service
Every browser

But a long skills list does not equal seniority.

A strong resume is selective. It shows what you can defend in a technical conversation. If you wouldn’t feel comfortable answering deep questions about it, it probably shouldn’t be in your main skills section.

Less noise. More signal.

2. Organize Skills Like an Engineer

Instead of dumping tools in a paragraph, group them clearly:

Front-end Development
APIs & Integration
Performance & Optimization
Tools
Design

This makes your resume scannable. Recruiters spend seconds on the first pass. Structure matters.

Also, avoid obvious items. Nobody needs to know you can use Chrome DevTools or VS Code. That’s assumed.

3. Responsibilities Are Not Impact

This is a common mistake:

"Developed web applications using JavaScript and CSS."

That’s expected. That’s the job.

Instead, shift the tone toward ownership and outcomes:

Designed and delivered responsive applications
Improved performance and maintainability
Structured scalable component systems
Optimized user experience and loading times

You don’t need fake metrics. You need clarity and intent.

4. Don’t Inflate Your Stack

It’s tempting to position yourself as an expert in everything: React, Angular, AI, cloud, DevOps.

If something is not your core strength, present it accurately:

Working knowledge
API integration
Familiar with

Precision builds credibility. Overstatement destroys it.

5. Align the Title With Reality

Your title should match your strongest value.

If your real strength is CSS architecture, JavaScript structure, and UX implementation, own that. You don’t need to label yourself as something broader just because it sounds better.

Clarity beats hype.

6. Fix the Visual Hierarchy

A resume is a UI problem.

If the layout is messy, duplicated, or inconsistent, it signals lack of attention to detail. As developers, that’s not the message we want to send.

Clean structure:

Name
Title
Contact
Summary
Skills
Experience
Education

Simple. Predictable. Professional.

What We Have Learnt..

If your resume feels off, don’t just tweak it. Re-evaluate it.

Ask yourself:

Does this reflect what I’m actually good at?
Does it sound intentional?
Can I defend everything listed here?

A strong resume isn’t longer.

It’s clearer, sharper, and more honest.

And sometimes, fixing it isn’t about adding more.

It’s about removing what doesn’t belong.

Failing an Interview Is Not the End

A. Moreno — Tue, 23 Dec 2025 03:19:43 +0000

Failing a technical interview hurts. No matter how much experience you have or how much you studied, when things go wrong your mind starts spiraling. “Maybe I’m not good enough”, “maybe I don’t belong here”, “others know more than me”. Everyone goes through this.

But failing an interview does not mean you failed as a developer. It means you discovered a gap in your knowledge. And even if it feels awful in the moment, that is valuable information.

Every question you couldn’t answer points directly to what you should study next. Every exercise that blocked you highlights an area to improve. Interviews, uncomfortable as they are, tend to be very honest mirrors of your strengths and weaknesses.

The Good Side

The good side is that interviews give you clarity. They cut through the noise and show you exactly what matters in the real world. Instead of guessing what to study next, you now have concrete topics to work on.

They also build resilience. Each failed interview makes the next one a little less scary. You learn how to explain yourself better, how to think under pressure, and how to recover when you get stuck.

What really matters is what you do after. Review what went wrong, study with intention, and try again. Most developers who seem “really good” today have a long list of failed interviews behind them.

Failing an interview does not define you. Giving up does. Keep studying, keep applying, and keep moving forward. The next one can go much better.

The People Who Make You a Better Developer

A. Moreno — Tue, 04 Nov 2025 00:12:20 +0000

Here’s something I wish I’d learned earlier: in tech, your growth isn’t just about the tutorials you watch, the courses you buy, or the number of commits you push. It’s about the people you surround yourself with. The truth is, good friends in tech can change your trajectory faster than any “10x productivity” tool ever could.

When I first started out, I thought learning to code was a solo grind. Just me, my laptop, and hours of Stack Overflow tabs. I figured that if I just worked hard enough, I’d eventually “make it.” But then I started meeting other developers — at meetups, on Discord, through open-source projects — and something clicked. The conversations, the code reviews, the random “hey, have you tried this library?” moments did more for my skills than weeks of isolated studying ever did.

The best kind of friends in tech are the ones who challenge you just enough. They don’t compete with you; they push you. They’ll call out your bad habits (“stop hardcoding that already”), share their favorite tools, and celebrate your wins even when theirs are different. It’s the kind of dynamic where you both want to see each other succeed, and somehow, you both do.

And it’s not just about professional growth. The tech world can get lonely — especially if you’re working remote or switching between projects all the time. Having friends who get it makes all the difference. The ones who understand what burnout feels like. The ones you can message at 2 AM when your code refuses to run, not for help, but just to vent. Those are the people who make this career sustainable.

Over time, these friendships evolve. You’ll start seeing your friends’ influence in your code, your problem-solving style, even your attitude toward failure. You’ll start realizing that collaboration isn’t just a skill — it’s a mindset. Tech moves too fast for any of us to figure everything out alone. So we share knowledge, trade feedback, and lift each other up when we’re running on empty.

And funny enough, those connections often lead to the best opportunities. A friend recommends you for a job. Another pulls you into a project. Someone you helped debug a CSS nightmare months ago becomes your teammate. None of it is forced or “networking” — it’s just genuine relationships that naturally pay off over time.

So if you’re early in your journey, don’t just focus on learning frameworks or grinding LeetCode. Go to that local dev meetup. Join that niche open-source Discord. Offer to help someone who’s stuck on a problem. The code will always be there, but it’s the people you grow with who’ll make you a developer worth working with — and a person worth remembering.

When You Want to Change the World with AI but Don’t Even Know What an API Is

A. Moreno — Tue, 14 Oct 2025 03:54:34 +0000

Every company wants a piece of the AI pie right now. You can’t open LinkedIn without seeing someone proudly announcing their “AI-powered solution” or “AI-driven transformation.” But if you look behind the curtain, many of these companies barely have a stable backend — let alone the infrastructure to train or integrate machine learning systems.

It’s not that AI isn’t useful. It’s that a lot of organizations treat it like a magic wand. They want to automate, optimize, and revolutionize — all without fixing the basic issues that have been holding them back for years. Missing documentation, outdated servers, chaotic codebases, and managers who still think GitHub is a social network. Yet somehow, the plan is to “fully integrate AI” by Q4.

AI isn’t a shortcut. It’s a multiplier. If your processes are efficient, your data clean, and your teams communicate well, AI can make things incredible. But if your foundation is weak, it’ll just multiply the chaos. You’ll spend more time debugging hallucinations and misaligned outputs than actually improving anything.

The truth is, most companies don’t need to “implement AI” — they need to modernize their systems, train their people, and understand what problems they’re actually trying to solve. An AI tool won’t fix a broken workflow, unclear leadership, or bad product vision.

So before you start pitching your “AI revolution,” make sure your team understands the basics — what an API is, how your data flows, and why good infrastructure matters. Because the smartest model in the world can’t save you from bad management.

Many of these so-called “AI transformations” start with a flashy announcement but end with a forgotten repo and a few dusty PowerPoint slides. The enthusiasm fades once the team realizes that training a model isn’t as simple as clicking a button. You need data pipelines, consistent schemas, version control, monitoring, and — most importantly — people who know what they’re doing. That’s not something you can fake with a press release.

It’s ironic how often you’ll find executives talking about predictive analytics when they don’t even have proper data storage policies. Or teams struggling with legacy codebases that are older than some of their interns, while being told to “just integrate AI” on top. It’s like trying to install a rocket engine on a tricycle — the ambition is there, but the structure isn’t.

The real opportunity isn’t in adding “AI” to everything. It’s in building the kind of technical culture that can support it. That means documentation, continuous integration, testing, and architecture that doesn’t collapse under a simple update. It means investing in education — not just in AI tools, but in how software actually works behind the scenes.

Companies that understand this end up building sustainable innovation. They don’t chase trends — they prepare for them. By the time everyone else is scrambling to “implement AI,” they already have the foundation ready. Their engineers can actually focus on meaningful applications instead of duct-taping prototypes that will never see production.

At the end of the day, AI isn’t about looking futuristic — it’s about being ready for the future. And readiness doesn’t come from buzzwords or rushed integrations; it comes from discipline, process, and understanding. You can’t automate what you don’t understand. And if you don’t know what an API is, maybe it’s not time to change the world just yet.

Good Practices Now That Your Future Senior Self Will Thank You For

A. Moreno — Fri, 26 Sep 2025 22:02:33 +0000

When you’re starting out as a developer, it’s easy to focus only on getting the code to work. But if you want to make life easier for your future self (and for your teammates), there are a few habits worth building early. These small things stack up over time, and by the time you’re a senior dev, they’ll feel second nature.

Write Clear Commit Messages

“Fix bug” or “update code” isn’t helpful when you’re trying to understand history months later. A good commit message should explain why the change was made, not just what you changed.

Document as You Go

You don’t need to write novels, but jotting down why you made certain decisions will save you from relearning them later. A short README, a comment explaining a tricky function, or even an ADR (architecture decision record) goes a long way.

Learn to Read Before You Write

Before you add more code, spend time understanding what’s already there. Most of your career will be reading and maintaining existing code — not writing brand new features from scratch. Get good at navigating codebases early.

Consistency Beats Cleverness

Clever code might impress your current self, but clear and consistent code helps your future self (and your teammates). Stick to team conventions, follow style guides, and aim for readability over brilliance.

Automate the Boring Stuff

If you notice yourself repeating the same manual steps — setting up environments, running tests, formatting code — take time to automate it. Scripts and tools may feel like overkill now, but they save hours (and mistakes) in the long run.

Start practicing these habits today, and your future senior self will silently thank you. Or maybe loudly, when you realize debugging your own code from last year is… surprisingly painless.

Don’t Fear the Command Line

A. Moreno — Wed, 10 Sep 2025 01:26:20 +0000

If you’re a front-end developer, the command line might feel intimidating at first. Black screen, white text, no buttons, no friendly UI. But here’s the truth: learning just a handful of commands can make your life much easier.

You don’t need to become a Linux wizard. You just need to know enough to move around, run scripts, and fix small issues without relying on your editor’s UI.

Isn't it Scary?

No. You'd be surprised! All you need is knowing the basics and some time to get familiar with the command line.

Here are a few essentials to start with:

cd project-folder → move into a folder
ls (or dir on Windows) → list the files in your current folder
npm install → install your project dependencies
git status → check what’s happening in your Git repo

Let’s put this together in a real-world example. Imagine you just cloned a project from GitHub:

    git clone https://github.com/username/project.git
    cd project
    npm install
    npm start

With just those four commands, you’ve downloaded the code, installed dependencies, and launched the project. No menus, no guessing, just speed.

The more you use the command line, the less scary it feels. Over time, you’ll realize it’s actually faster than clicking through endless menus — and you’ll start to prefer it.

Be Brave!

Don’t fear the command line. Learn a little, practice often, and soon it’ll feel like second nature.

The Bug That Taught Me More Than Any Tutorial

A. Moreno — Tue, 26 Aug 2025 00:26:13 +0000

We all have that one bug — the kind that drains your time, patience, and sanity. I recently ran into one, and honestly, it taught me more than any tutorial ever did.

How It Started

I was working on a feature that should’ve been simple: fetching data from an API and showing it on screen. The tutorial I followed covered exactly this. But when I ran my app, the data just wouldn’t show up. No errors, no warnings — just empty placeholders.

The Usual Steps

I checked my API endpoint — it worked perfectly in Postman. Then I looked at my fetch request headers and payload. I triple-checked the state updates and rendering logic. Everything seemed fine. I even cleared my browser cache, just in case. Still, no data.

The Unexpected Culprit

After hours of banging my head against the wall, I slowed down and reread the tutorial — this time paying attention to the small details I had skimmed. That’s when I realized the bug wasn’t in my code but in how I was handling asynchronous state updates.

In React, state updates don’t happen immediately. If you try to access the state right after setting it, you might get stale or empty data. I was logging the state right after updating it, expecting the new value, but React hadn’t updated it yet.

What I Discovered

Patience and paying attention to details beat rushing through tutorials. Tutorials can show you what to do, but they often skip the why.
Understanding your tools really matters. Knowing how React schedules state updates saved me from going in circles.
Debugging is one of the best ways to learn. That bug pushed me to dig into the docs and experiment, instead of blindly copying code.

Lesson Learned

At first, that bug felt like a huge setback. But it ended up being one of the best learning experiences I’ve had. Sometimes the hardest problems don’t just test your skills—they sharpen them.

So next time you hit a wall, don’t just fix the bug. Step back, dig deeper, and let it teach you something new.

Thanks for reading! If you’ve ever had a bug that totally changed how you think about coding, I’d love to hear about it in the comments.

Stop Overcomplicating Responsive Design: A Simple Approach

A. Moreno — Wed, 06 Aug 2025 05:59:07 +0000

Responsive design doesn't have to be complicated. After working on real-world projects, I've found that most layouts can be made responsive with just a few practical techniques. You don't need fancy frameworks or hundreds of breakpoints. You just need to master the basics.

Here's how I keep things simple:

1. Use Percentage Widths and Max-Width

Instead of hardcoding pixel widths, use percentages. Combine them with max-width to avoid elements stretching too much on large screens.

    .container {
        width: 100%;
        max-width: 1200px;
        margin: 0 auto;
    }

2. Flexbox and Grid Are Your Best Friends

For most layouts, Flexbox and CSS Grid can handle alignment and spacing without extra wrappers or CSS hacks.

Use Flexbox for one-dimensional layouts (rows or columns).
Use Grid for two-dimensional layouts (rows and columns).

    .flex-row {
        display: flex;
        gap: 1rem;
    }

    .grid-layout {
        display: grid;
        grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
        gap: 1rem;
    }

3. Media Queries: Start Simple

You don't need a media query for every device. Start with a mobile-first approach and add a few breakpoints where the layout actually breaks.

    @media (min-width: 768px) {
        .sidebar {
            display: block;
        }
    }

Focus on behavior, not device sizes.

4. Don’t Forget `object-fit` and `aspect-ratio`

For images or videos that need to maintain proportions, these two CSS properties are life-savers.

    img {
        width: 100%;
        height: auto;
        object-fit: cover;
        aspect-ratio: 16 / 9;
    }

Work Smarter not Harder

Responsive design is not about memorizing every CSS trick. It's about using flexible layouts, sensible breakpoints, and letting the browser do the heavy lifting. Master these fundamentals, and you'll handle 90% of responsive layouts with ease.

Stuff You Need to Know If You Plan to Become a Technical Writer

A. Moreno — Thu, 10 Jul 2025 04:06:46 +0000

Ok let me get straight to the point — I've been working as a technical writer for a while now, and if you're thinking of getting into it, I'll give you a quick rundown of what you'll actually need — not just the stuff they mention in job descriptions.

1. You Have to Know the Tech

No, you don’t have to be a senior developer. But you do need to understand how things work. You should be comfortable reading documentation, looking at code, and maybe even running the software locally.

2. Clear Writing Beats Fancy Writing

Forget flowery language. The goal is clarity. Think:

“Click this button”
“Run this command”
“Here’s what happens next”

If a beginner can’t follow your writing, it’s not done yet.

3. Ask Annoying Questions

You’ll often document features that aren’t fully built or explained. Don’t be afraid to ask developers:

“What does this return?”
“What’s the default behavior?”
“What happens if it fails?”

You’re not bothering them — you’re making sure users don’t have to.

4. Version Control Is Your Friend

You’ll likely write in Markdown and push docs to GitHub or GitLab.
Basic Git commands like these go a long way:

    git status
    git pull
    git add .
    git commit -m \“Update docs\”
    git push

5. Stay Organized

You’ll deal with multiple files, folders, edits, reviews, changelogs, deadlines — all at once.
Make sure you can keep track of what you’re writing and why. Even a simple checklist helps.

Are We There Yet?

Being a technical writer is about bridging the gap between the builder and the user. You don’t need to know everything, but you do need to be curious, clear, and collaborative.

If that sounds like you, you’re already on the right path.

3 Ways to Center a Div in CSS (That Actually Work)

A. Moreno — Sat, 28 Jun 2025 00:28:59 +0000

Let’s be honest — centering a div shouldn’t be this complicated. But if you’ve ever Googled it, you’ve probably run into dozens of answers, and not all of them are reliable.

Here are 3 modern, reliable ways to center a div — both horizontally and vertically — that I use all the time in real-world projects.

1. Using Flexbox

CSS

.parent {
  display: flex;
  justify-content: center; /* horizontal */
  align-items: center;     /* vertical */
  height: 100vh; /* or any height you need */
}

HTML

<div class="parent">
  <div class="child">I'm centered!</div>
</div>

Why it works: Flexbox is made for alignment. This combo centers the child perfectly inside the parent.

2. Using Grid

CSS

.parent {
  display: grid;
  place-items: center;
  height: 100vh;
}

HTML

<div class="parent">
  <div class="child">I'm centered!</div>
</div>

Why it works: place-items: center is shorthand for centering both horizontally and vertically. Clean and powerful.

3. Margin Auto (Horizontal Only)

CSS

.child {
  width: 200px;
  margin: 0 auto;
}

HTML

<div class="child">I'm centered horizontally!</div>

Why it works: When you set a fixed width and apply margin: auto, the element centers itself in its container — but only horizontally.

Bonus: Absolute Positioning (Old but Gold)

CSS

.parent {
  position: relative;
  height: 100vh;
}

.child {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

When to use it: If you're stuck with older layout styles and can't use Flexbox or Grid — this still gets the job done.

Wrap-Up

If you're building modern layouts, Flexbox and Grid are your best tools. You’ll see them everywhere — from simple forms to full page layouts.

Stop fighting CSS. Use one of these, and center with confidence.

DEV Community: A. Moreno

Things You Notice After Inspecting 100 Websites

Everyone Uses the Same Layout Tricks

There Is Almost Always More CSS Than Necessary

Fonts Are Doing a Lot of Heavy Lifting

Analytics Scripts Are Everywhere

Many Websites Are Built With the Same Stack

Developer Tools Become Your Second Pair of Eyes

What I Learned

AI Is Taking Jobs. So What Should Developers Do?

So what should you focus on?

This is just another shift.

"I Messed Up My Resume. What Now?" This Is How to Fix It.

1. Stop Listing Everything You’ve Ever Touched

2. Organize Skills Like an Engineer

3. Responsibilities Are Not Impact

4. Don’t Inflate Your Stack

5. Align the Title With Reality

6. Fix the Visual Hierarchy

What We Have Learnt..

Failing an Interview Is Not the End

The Good Side

The People Who Make You a Better Developer

When You Want to Change the World with AI but Don’t Even Know What an API Is

Good Practices Now That Your Future Senior Self Will Thank You For

Write Clear Commit Messages

Document as You Go

Learn to Read Before You Write

Consistency Beats Cleverness

Automate the Boring Stuff

Don’t Fear the Command Line

Isn't it Scary?

Be Brave!

The Bug That Taught Me More Than Any Tutorial

How It Started

The Usual Steps

The Unexpected Culprit

What I Discovered

Lesson Learned

Stop Overcomplicating Responsive Design: A Simple Approach

1. Use Percentage Widths and Max-Width

2. Flexbox and Grid Are Your Best Friends

3. Media Queries: Start Simple

4. Don’t Forget object-fit and aspect-ratio

Work Smarter not Harder

Stuff You Need to Know If You Plan to Become a Technical Writer

1. You Have to Know the Tech

2. Clear Writing Beats Fancy Writing

3. Ask Annoying Questions

4. Version Control Is Your Friend

5. Stay Organized

Are We There Yet?

3 Ways to Center a Div in CSS (That Actually Work)

1. Using Flexbox

2. Using Grid

3. Margin Auto (Horizontal Only)

Bonus: Absolute Positioning (Old but Gold)

Wrap-Up

4. Don’t Forget `object-fit` and `aspect-ratio`