The reason these scams work is that we’re desperate for a job and willing to take steps that we believe will improve our chances of getting hired. That means our guard is down. I’ve been targeted several times and almost became a victim myself. If you’ve fallen victim to one, don’t be ashamed. These fraudsters are really good at what they do.

The hook

The most common scam right now is the “Executive Resume” rewrite. While it takes a couple of different forms, the general approach is:

1. A fake recruiter messages you about a job that you’re a great fit for. The JD is a very close match to your profile. There’s a reason for this: they generated it based on your profile. If it matches you a little too closely, be on high alert.

2. They ask for your resume.

3. You provide your resume, and they respond by recommending that you work with their “executive resume writer” to position your resume before presenting you to the hiring manager.

That’s the hook. A legitimate recruiter would never do this. That’s your first red flag.

This is not to say that every person offering optimization or resume services is a scammer, but there are some steps you can take to protect yourself and separate legitimate offers from fraudsters.

How to catch a scammer

When vetting professional opportunities or business partners online, establishing the counterparty's true identity is the first line of defense against fraud. Scammers routinely rely on anonymity and fabricated credentials, making a rigorous background check essential before any formal commitments or financial transactions take place.

1. Ask for official contact information, including a business email address and business phone number.

2. Check the email address. Is it linked to a business account? If it’s a Gmail account, that’s a red flag.

3. Validate the business phone number. If they refuse to provide one, that’s a red flag. If they provide one, Google it. Is it a US phone number linked to a legitimate business? If not, be cautious. Then call it to verify. A scammer typically won’t provide contact information like a phone number that can be easily linked back to them.

4. Validate the LinkedIn profile. Pull a copy of the profile picture and reverse image search it. Is it from a stock photo site? If so, that’s a red flag. Does it link to more than one profile? If so, they may be impersonating someone else. Does the profile have a lot of followers? If they only have a few, be careful; it could be a fake or recently created account.

5. Finally, ask for a reference. Are they willing to provide one? If so, before you hand over any money, check the reference. If they refuse, that’s another red flag.

If ANY of these steps don’t check out, don’t hand over your money. Real professionals welcome due diligence, while bad actors rely on pressure tactics and obscurity to bypass it. By diligently applying these tactics you will protect yourself from becoming their next victim.

If you catch a scam account on LinkedIn, report it.

When UI state changes, the attributes that describe that state need to change with it — otherwise assistive tech gets out of sync with the UI.

Example: A validated text field shouldn’t always announce an error.

Bind aria-invalid and aria-describedby to the validation state so the error message is only associated when it’s real (see screenshot for example in Vue.js).

Same idea for expand/collapse (aria-expanded), busy submits (aria-busy / disabled), and live regions (aria-live) for async results.
Rule of thumb: if the visual UI changes, check whether the accessibility tree needs an update too.

<input
   id="name"
   :aria-invalid="!invalid"
   :aria-describedby="!invalid ? "name-error" : undefined"
/>
<span v-if="!invlaid" id="name-error">
   Name must have at least 5 characters.
</span>

While the file is written in Markdown, you DO NOT need to be an engineer to use it. If you use AI for any purpose, you can add one to the root of your primary work directory on your computer and either symlink or hardlink to it from any other work directory and customize it for your own purposes (more on this in a moment).

If you do not want to write the instructions manually because you are not comfortable writing Markdown, you can prompt your agent with the rules you want to add, and it will add them in Markdown for you. If you are not a developer who works inside of an IDE and wish to manually customize the rules, then just open up the file in Notepad or another simple text editor, type out the instructions in Markdown, and save it with the .md extension.

For those of you using Claude, you can alternatively use a Claude.md to serve the same purpose; however, an AGENTS.md will be picked up by any LLM you are using, so I recommend using that instead. If you prefer to use Claude.md and are using the Claude Code app in your terminal, you can have Claude generate the default Claude.md by typing /init in the terminal inside of the root of your work folder. This will generate the baseline file that you can then customize. If you use the Claude desktop app, you can tell Claude to reference it in the project’s Custom Instructions sidebar; type: “Always read and prioritize the style rules laid out in the attached Claude.md file.”

If you work out of multiple project directories and want to manage all your instructions in a single file, you can ask Claude (or whatever LLM you use) to symlink each project to the root AGENTS.md file for you: “Claude, I have added an Agents.md (or Claude.md) file to the current root directory with the instructions I want you to use moving forward. I need you to symlink that file to all of my project folders in this working directory.”

Alternatively, if you do not like symlinks, you can place a blank AGENTS.md in the root of each project directory and add a hard link inside of it that points to the primary AGENTS.md in the project root. With this symlink or hard link in place, you will only need to edit the AGENTS.md in the project root, and the changes will apply to each project or working directory!

Note that in general, if you open your projects from the project root as your workspace, the agent should be able to reference the AGENTS file without needing the symlinks or agents files in each project; however, if you open the individual projects as the workspace root, you will need the hard link or symlink in place. To save yourself time moving forward, you can also add the instruction “Whenever creating a new project directory for me, add a new AGENTS.md to it and link it to the source of truth Agents file for me.”

For example:

/Projects  
  AGENTS.md <-- primary agents file with instructions (if you work out of this directory, you won't need an AGENTS.md in every project folder  
      /Project1  
      /Project2

If you are like me, you probably have an issue with the cumbersome and robotic language AI uses in its responses. Adding a Personality & Communication ruleset in your AGENTS.md is an excellent way to address this. While it will not perfectly humanize the response, it will at least be less verbose and stick to more common language.

This is mine:

## Personality & Communication
- **Be direct:** State the primary answer or core conclusion in the very first sentence. Avoid introductory filler like "Sure, I can help with that" or "Here is the information."
- **Eliminate verbosity:** Keep sentences short and use the active voice.- **Maintain a natural, human tone:** Speak like a helpful, clear-headed peer. Avoid overly formal corporate jargon, rigid academic phrasing, or robotic disclaimers.
- Bold paths; bullets over walls of text.- If unclear what to build, ask one short question before coding.

When crafting your AGENTS file, try to keep your AGENTS file below 250 lines. Excessively long rule sets will create increased latency in the responses and burn more tokens. Keep it tight and actionable.

Below is my full, primary AGENTS.md as a Vue.js/TypeScript engineer. Feel free to copy as much of it as you think is relevant to your needs, or use it as a starter for your own stack.

Happy prompting!

## Projects AGENTS.md (canonical)

Source of truth for `/Users/dannygibas/Projects`.

**Scope:** Greenfield stack rules apply to **new projects only**. Do not rewrite existing apps (styles, READMEs, aliases, structure) unless D asks. Vue rules → Vue apps. React apps → local patterns + shared sections (comms, secrets, change control, DoD).

**New apps:** Symlink this file as root `AGENTS.md` (`../AGENTS.md` or `../../AGENTS.md`). For public GitHub demos, a short pointer file is fine if a symlink looks messy.

---

## Personality & Communication

- **Be direct:** State the primary answer or core conclusion in the very first sentence. Avoid introductory filler like "Sure, I can help with that" or "Here is the information."
- **Eliminate verbosity:** Keep sentences short and use the active voice.
- **Maintain a natural, human tone:** Speak like a helpful, clear-headed peer. Avoid overly formal corporate jargon, rigid academic phrasing, or robotic disclaimers.
- Keep explanations under 3 sentences. Skip teaching standard APIs (`map`, `ref`, etc.) unless it prevents a hidden bug.
- Bold paths; bullets over walls of text.
- If unclear what to build, ask one short question before coding.

---

## Change Control

- **Stay on request:** Only what the latest ask requires. No drive-by cleanups, renames, restyles, or extra files unless D asks.
- Ask before behavior/API changes or refactors.
- In an already-approved file: typos, type fixes, and obvious bugs are OK without re-asking.
- Ask before touching vendor config, `.env` / mocks, or DB seeds.
- Match existing patterns; get approval before changing them.
- Never commit or push unless D asks.

---

## Secrets & Git

- Never commit secrets. Gitignore `.env` / `.env.*` (allow `.env.example`).
- Secrets only in local `.env` / `.env.local`.
- New projects: ship `.env.example` with `VITE_*` placeholders.

---

## New Project Layout

| Path                       | Purpose                |
| -------------------------- | ---------------------- |
| `src/components/`          | UI only                |
| `src/composables/`         | `use*` reactive logic  |
| `src/types/`               | Types / unions         |
| `src/stores/`              | Pinia — only if needed |
| `src/utils/` or `src/lib/` | Plain helpers          |
| `src/assets/`              | Imported assets        |

---

## Stack (new projects)

- TypeScript, strict null checks; prefer type files.
- **Tailwind v4** + `@tailwindcss/vite`. No vanilla/inline CSS unless a third-party lib needs it (ask first).
- Existing / a11y–API drills: match the repo (scoped CSS OK).
- Components = display; logic in composables.
- Native HTML + Tailwind first — ask before UI kits (Headless, Radix, Vuetify, etc.).
- Vue Router only when there is more than one real route.
- Ask before adding npm deps.
- Prefer `const` over `let`.
- API URLs from `import.meta.env.VITE_*` — never hardcode; never use `process.env` in Vite client code.
- New projects: configure `@` → `/src` in **vite.config + tsconfig**. Do not invent `@/` mid-edit in repos that lack it.

**Theme tokens:** Define in `@theme` / Tailwind config. Utilities OK if they map to tokens. **No raw hex in SFCs.**

```css
@theme {
  --color-background: #f7f7f7;
  --color-foreground: #1a1a1a;
  --color-border: #d4d4d4;
  --color-success: #15803d;
}

Consider the following use case.

You are developing the front end for a banking app. A user is expecting to always see an accurate account balance when they deposit or withdraw funds. While the backend is the ultimate source of truth for the balance, the front end is responsible for requesting updates to the balance and displaying the results of these requests accurately to the user.

In a banking app without concurrency management, the following situation might occur.

An account holder opens their banking app and observes a balance of $100 in their checking account. They deposit an additional $100 from a check, expecting a new balance of $200. While the deposit is still in flight they try to move the anticipated balance of $200 to their savings account. Due to excessive latency at a data center the transfer request hits the database before the deposit request and they get an insufficient funds error as a result.

What we need is a way to manage the concurrency of the requests. There are a few different design patterns to handle this, including optimistic and pessimistic locking. There is also sequentialization via mutex locking, which is the design pattern that this article addresses.

Lets look at how we can handle the example above via the mutex pattern in TypeScript:

class AsyncLock {
  private disableNext: Promise<void>;

  constructor() {
    this.disableNext = Promise.resolve();
  }

  // force async task to wait in line
  async acquire(): Promise<() => void> {
    let release!: () => void;
    const currentLock = this.disableNext; // assign private reference to the most recent promise created
    this.disableNext = new Promise<void>((resolve) => {
      // create a new promise for the next request in queue
      release = resolve;
    });
    await currentLock;
    return release;
  }
}

// how to use AsyncLock
const lock = new AsyncLock();
let balance = 100;

type TransactionType = "withdraw" | "deposit";

async function updateBalance(
  amount: number,
  transactionType: TransactionType
): Promise<void> {
  const release = await lock.acquire(); // wait in line
  try {
    console.log(`Reading balance... Current: $${balance}`);
    await new Promise((r) => setTimeout(r, 50)); // simulate database delay
    if (transactionType === "withdraw" && balance >= amount) {
      // withdraw
      balance -= amount;
      console.log(`Withdraw: $${amount}. Current: $${balance}`);
    } else if (transactionType === "deposit") {
      // deposit
      balance += amount;
      console.log(`Deposit: $${amount}. Current: $${balance}`);
    } else {
      console.log("NOP");
    }
  } finally {
    release(); // let the next task run by calling the resolve method on the current promise
  }
}

updateBalance(100, "deposit"); // deposit $100 into checking
updateBalance(200, "withdraw"); // transfer (withdraw) $200 to savings

Let’s break down the example.

When you execute new AsyncLock() , JavaScript creates a brand new locking object. this.disableNext = Promise.resolve(); initializes with a resolved promise on creation, allowing the first request in the queue to process immediately. Every time a function calls lock.acquire() it needs to know what the current state of the lock chain is. this.disableNext allows the code to look at the shared state stored on that specific lock instance. It reads the previous promise ( currentLock ) and then overwrites this.disableNext with a new pending promise. Because this points to the persistent lock instance, the next function that calls lock.acquire() will see that updated promise and wait in line behind it. When the current process completes it will call release() which will resolve the current (in flight) promise and allow the next request in line to proceed.

The result is a lock that queues the requests in a predictable and controllable order. A follow-up request can never supersede the previous and your UI will remain synced with the resolving request order. Any number of concurrent requests can be queued and will process First In — First Out (FIFO). The use of a JavaScript Class and the this keyword ensures that the disableNext state is shared across instances. That makes the mutex design pattern an excellent choice for managing concurrency across shared states in JavaScript applications where high performance is necessary and deadlocking additional requests must be avoided.

We know the problems with vibe coding are many. Stateless sessions lead to the loss of structural decision-making, and inconsistent design patterns develop. It becomes a spaghetti time bomb. Silent gaps arise because the LLM pays little attention to things like input sanitation, race conditions, and telemetry. Team coordination is effectively impossible when vibe coding puts each engineer into solo sessions with no clearly defined rules and coordinated objectives. PRs tend to become nightmarish, with thousands of lines of code to review while trying to understand the AI's intent.

Engineers end up feeling disconnected from the engineering process and more like AI babysitters at the end of the day.

But there is a two-part alternative that I fell in love with that solves those issues, and so can you. They are spec-driven agentic orchestration and vertical story slicing.

Spec-Driven Development (SDD) puts engineers back in the driver's seat with the agent riding shotgun. SDD helps you engineer solutions with forethought, collaborate as a team, research, and plan before the agent writes a single line of code.

Hair of the dog.

While there are several spec-driven workflows out there, I am going to address OpenSpec in this article as this is the workflow that I prefer due to its lightweight and versatility. The nice thing about the OpenSpec workflow is that it works great with both greenfield and brownfield products and you can introduce it into your workflow (and repo) at any point in the product lifecycle.

The OpenSpec Structure.

Before I discuss the individual artifacts of the OpenSpec workflow, let’s take a look at the directory organization of OpenSpec in a repo.

├── .openspec/
│   ├── config.yaml          # Framework rules, schema configurations, and linter settings
│   └── agent.md             # System prompt instructing the AI assistant how to use OpenSpec
├── project.md               # The Project Constitution: Global context (Tech stack, architecture rules)
├── specs/                   # 1. THE SOURCE OF TRUTH (Durable specifications)
│   ├── auth/
│   └── orders/
└── changes/                 # 2. THE DELTA CHANGES (Transactional task folders)
    └── change-042-add-filter/
        ├── proposal.md      # High-level business intent ("The What")
        ├── specs/           # Granular acceptance requirements
        ├── design.md        # Technical architecture blueprints ("The How")
        └── task.md          # Atomic checklist for the AI agent execution layer

The specs directory is the source of truth right at this time in your repo. It contains the system’s baseline logic for each completed and archived feature or domain. The agent regularly references the specs directory to maintain context across the system for new features or spec deltas and is shared across engineering because it is located right in the repo. When you are completed with a feature and archive it, the agent safely merges the spec deltas into the spec directory, and they become part of the source of truth.

The changes directory contains the artifacts for the feature or bug you are currently working on. Each change includes its own proposal.md, design.md, tasks.md, and a spec directory that contains one or more spec.md delta files. Each change should typically reflect a vertical slice of the feature which segues us nicely into…

Vertical Slicing.

Before starting the SDD workflow, the product owner should break the feature down into stories and stories into slices — structural verticals based on business value and domain components. From an Agile perspective, stories may contain multiple vertical slices. Stories that cross domains and/or cannot be completed in a single sprint should be broken into smaller manageable verticals, and each vertical should become a spec delta in the SDD workflow. Slice-based product management isn’t part of the OpenSpec framework, but it does make SDD much more manageable from a team and QA perspective.

Slicing is a verbose topic, and there are plenty of articles already written about it, so I won’t go into depth about it here. I linked a good primer about vertical slicing from the Monday blog at the end of this post if you want to learn more.

The reason that I mention it in this article is primarily that it is a great way to break stories into changes in the SDD workflow.

Let’s return to discussing the OpenSpec artifacts, starting with…

The Proposal.

First, the engineer works with product to capture the high-level plain-language goals, business constraints, and outcomes. Advanced teams use agent skills like grill-me here, forcing the AI agent to interrogate the engineer with edge-case questions before the document can finalize. Reviewing the Figma file during this session and even providing it to the agent via MCP is very helpful to make sure there is a clear understanding of the UI and experience between business, engineering, and the agent.

I found that doing a co-working session between the engineer and the PO with the agent works best for generating the proposal (proposal.md), and because the proposal is a plain English document it is easy to coordinate the conversation as you are both speaking the same language in the co-working session. Here you will work together to make sure that business and engineering are aligned, an area that teams often struggle with outside of this framework.

The Spec Deltas.

When talking about spec deltas, what we really mean are the feature or bugfix specifications that will ultimately update the existing “source of truth” once the feature or bugfix is completed and archived in the Spec Driven Development framework.

The specs are the highly precise operational requirements, frequently utilizing behavior-driven (Given-When-Then) syntax fenced blocks to establish requirement boundaries. The specs are controlled by the Product Owner and are driven by the proposal. Any deltas must be PO-approved. Specs should always be individually QA testable, and QA should build test cases that target the specs.

You might discover while drafting the design that an important constraint was overlooked that should be a spec because it is QA testable behavior. This might be a case for a valid spec addition, and you should address it with the PO to determine if it should be added. Since specs should be QA testable, any changes should also be brought to the attention of QA in case they have already written test cases and need to add more to address the spec addition or modification.

Specs should originate in your project management software and be tied to each associated slice in the story and be pulled into the repo as a spec delta. With an MCP for your project management suite, you can ask the LLM to generate the spec.md artifacts in the repo for you.

It should be noted that the source of truth is always the specs in the repo. NOT the stories in your project management software. QA, Product, and Engineering should always be aligned to the specs in the repo. Since the specs are plain English in Markdown and can be accessed by anyone in the company with a link to the file in your company's Git account, they can easily be viewed and referenced, even by non-engineering staff who lack access to a code editor.

The Design.

The design is the strict technical architecture blueprint and is owned by the engineer. This lays down the technical constraints — specifying patterns, models, contracts, fences, interfaces, etc. The design (design.md) ensures that these constraints are maintained across each slice and each engineer on the team. The design should ensure each spec is covered from an architectural perspective. I found using the grill-me skill is also useful here to make sure that you close any gaps that the agent would have to guess at during the execution.

The Tasks.

Turns the verified plan (from all of the artifacts) into an atomic checklist of minimal, independent execution steps that an AI agent can build without needing further guidance. As the LLM works through the execution, it will check off each item in tasks.md for you. Tell the agent to generate the tasks, and it will parse all of the artifacts and generate them for you.

The Execution.

This is where you finally set the agent loose to write the code, and you go hands off as the engineer. Simply tell the agent to start the execution, and it will be off and running, generating the code, following all of the specs, constraints, and design patterns that are defined in the artifacts, including those defined in the artifacts from archived slices to keep the solution cohesive.

After the build is complete, it is your opportunity to review the code that was generated. Before you open a PR, you should make sure that you do your own review to understand what was written as well as conduct dev testing to make sure the results fully align with the specs.

Sober Up.

SDD puts the team in control of the agent and ensures cohesive outcomes. Each slice's artifacts are archived and shared across slices (and engineers) through the repo. The agent has each slice's artifacts to reference in each subsequent slice, ensuring patterns are maintained, hallucinations are reduced, bugs are minimized, structural chaos is eliminated, and each slice is manageable in PR and in QA.

And the best part for engineers is it lets you actually engineer again instead of fighting with the agent all day.

You don’t have to feel like the drunk carpenter with a hammer anymore when using agentic AI to increase the efficiency of the development cycle.

Hold my beer.

I have experienced about a 20% time savings for feature delivery when using agentic SDD over a traditional software engineering workflow, but that’s not all. SDD forces the teams and departments to work together, to solve problems together, and think through more edge cases. This leads to far less bugs and a stronger, more cohesive product by coupling the specs to the repository and defining a single source of truth for the code base.

Learn more about the OpenSpec workflow at https://openspec.dev

Monday has a good primer on vertical slicing: https://monday.com/blog/rnd/vertical-slice/

“You have to accept that there will be advanced concepts and syntax that you will have to use in the learning process but won’t necessarily understand. That is part of the process of learning to write code. You just have to accept that this is how the code is written and not understand why yet.”

Well said. That's the crux of it all. You will have to use advanced concepts that you won’t understand at first in order to learn the basics (which you will eventually understand).

I have to admit, as I sat in that classroom on the first day, anxiety crept up on me as I found myself exceedingly lost in the topic. “Maybe this is just not the right path for me. Maybe I just don’t have the type of mental faculty needed to grasp programming. Maybe I am simply not “smart” enough.”

There is just so much stuff that I needed to learn that it felt so overwhelming.

The truth is that every doubt flowing through my brain was nonsense, and that I was certainly not alone in those thoughts and feelings. I am here to tell you that everyone gets overwhelmed when first dipping their feet into the field. Even experienced devs get overwhelmed from time to time.

That feeling does not mean you are failing. It usually means you are standing at the edge of something new, and your brain is trying to map a landscape it has never seen before. Programming dumps a lot of vocabulary, tools, and mental models on you all at once. Of course it feels like drinking from a firehose. The goal is not to absorb the entire firehose on day one. The goal is to keep showing up long enough for the stream to start looking like water.

So, how does one get over that initial pedagogy in a vacuum?

First, let's take a look at the steps of the learning process: The 4 P's

Preparation: Arousing Interest

Presentation: Encountering the New Knowledge or Skills

Practice: Integrating the New Knowledge or Skills

Performance: Applying the New Knowledge and Skills

Preparation is the first step in any learning process. This is where the motivation to learn something cool and new actually happens. Preparation in the traditional sense would occur in the classroom as the teacher introduces a topic that piques your interest. However, this can happen in any number of ways, many unrelated to the classroom. Maybe it happened while you were reading a news article about the subject. Or maybe you spent some time in a subreddit dedicated to the subject, and it tickled your curiosity. Really, how it happens here is irrelevant; it just needs to happen, and you need to be able to maintain the interest.

Protect that interest on purpose. Motivation fades when every session ends in frustration and nothing that feels like progress. Give yourself small wins early: a page that loads, a button that works, a script that prints the right thing. Curiosity gets you in the door. Tiny evidence that you can do this is what keeps you from walking back out.

Presentation is next. In my experience, most students get stuck at Presentation, and unfortunately some never get beyond that point. Students get super excited about the prospect of learning to code, but then the drive dies out once confronted with the difficult concepts and workflows associated with development work. To overcome the anxiety brought on by a lack of understanding, this step should only be viewed as an in-depth introduction to the topic.

You really are not expected to understand all of it at this point. In fact, some may not understand anything at this point. This is especially true with visual learners like myself. It is very important to take good notes and ask lots of on-topic questions, as doing so will make the next step less overwhelming. If you are a visual learner, those notes will serve as your foglight.

If you are learning solo, treat tutorials and docs the same way. Watch or read once for the map, not for mastery. Pause and write down the terms you do not know yet. Star the parts that feel foggy. Resist the urge to restart the same video five times hoping comprehension will magically arrive. That loop keeps you stuck in Presentation. Your job in this step is exposure and orientation. Understanding comes later, with your hands on the keyboard.

The next step is Practice. Practice is where the learning and retention actually happen for people, and in my opinion is the most important step in the entire learning process. Please note: If you are a self-learner and you fail to invest the necessary time here, you will not learn. I cannot emphasize this enough. It does not matter how many articles or books you read, nor how many tutorial videos you sit through — if you don’t practice what you acquired in the presentation step, you will not retain the information, and you will never actually be able to apply it.

The more time you spend here, the greater the benefit. One thing I found incredibly useful when working on practice assignments is to not move on to a new topic unless I feel that I can comfortably explain to someone what the current code does and how it does it. This approach provides a really solid reinforcement of the material as you switch your brain between learning and teaching modes. Doing so also highlights your weaknesses and identifies where you should be investing more time before moving on to the next topic.

Practical tip from the trenches: rebuild the example without looking. Close the tutorial. Open a blank file. Try to recreate the idea from memory and your notes. When you get stuck—and you will—peek, then close it again and keep going. That struggle is not a sign you are bad at this. That struggle is the learning. Also, break practice into short, consistent sessions. One focused hour most days beats a heroic eight-hour weekend followed by two weeks of silence.

At some point in your learning, concepts will just start to click. You will have reinforced enough material that you will be expending less time and energy having to focus on every nuance. As this happens, you will find yourself feeling less overwhelmed when you fire up your code editor. Conceptual understanding that once felt out of reach will instead become second nature.

That does not mean the hard days disappear. You will still hit walls. You will still Google the same error twice. The difference is that the wall starts to look climbable. You will recognize patterns. You will remember that you have been confused before and figured it out. That quiet confidence is earned in Practice, not gifted in Presentation.

Then comes Performance: applying what you learned to something that is yours. This is where junior developers either level up or get stuck in tutorial purgatory. Performance means building a small project, contributing a fix, styling a page from scratch, or solving a real bug without a step-by-step walkthrough holding your hand the whole time. It will feel messy. That is normal. Real work is messier than coursework.

Start smaller than your ego wants. A tiny app that works beats a grand portfolio idea that never ships. Finish something imperfect. Then improve it. Each finished thing teaches you what tutorials never can: how to navigate ambiguity, how to debug your own decisions, and how to recover when you break things.

You also do not have to get through this alone. Ask questions. Join a study group, Discord, or local meetup. Rubber-duck your code to a friend. Searching well is a skill—learn to read error messages, skim docs, and ask for help with what you already tried. Asking for help is not a weakness. Refusing to ask while spinning for three days often is.

The good news is that once you learn one language, picking up others becomes exponentially easier! So, if you are early in your learning and you feel overwhelmed or stuck, just keep pushing through. Accept that you will have to use code you don’t understand while learning and be OK with that.

Thousands have walked the same path before you, and most make it through.

And when the doubt creeps back in, and it will, remember that classroom in 2008. Feeling lost on day one did not mean I lacked the mental faculty for this work. It meant I was beginning. You are allowed to begin messy. You are allowed to not understand yet. Keep practicing. Keep building. The clarity comes after the confusion, not before it.

You’ve been told to “optimize your images for the web.” Cool. But what does that actually mean, and how do you do it without nuking quality? This (opinionated) guide covers the what, why, and how. A couple of notes before we dig in:

Why do you call this article opinionated? Ilya Grigorik has this to say about image optimization,

Image optimization is both an art and a science: an art because there is no one definitive answer for how best to compress an individual image, and a science because there are many well-developed techniques and algorithms that can significantly reduce the size of an image.

Emphasis mine. That is the primary purpose of this article ; to share with you a bit of image optimization knowledge I have acquired over the years as a designer and front-end engineer. Not everyone will use the same approach as me, and your own approach will evolve as new tools, formats, and methods become available.

OK, enough introduction. What is image optimization?

The What?!?

Image optimization can be defined as:

A process applied to digital image files that results in a non-trivial reduction in file size while maintaining a level of visual quality that is acceptable for its intended purpose.

What is a process? The process is the methodology that you apply and the tools you use to achieve the desired result. In this case, the production of an image file that loads faster on a viewport, without any detrimental loss of visual quality on a client device.

What do you mean by non-trivial? Non-trivial in this context means that applying the process will result in a significant reduction in file size, and that this file size reduction provides an advantage to your resources and, more importantly, the user experience.

Simply put, image optimization is about removing unnecessary data from image files and the various methods of doing so.

Why optimize?

There is a wealth of compelling reasons to optimize your images before publishing to the web. What follows are just a few of them ,  the reasons that I feel are most important.

Site load time reduction = improved experience. A great example of this is represented in both Google and Bing image search. When you search for an image, seconds later you are returned a grid of hundreds of images. However, if you click through one of those images to load the high-quality version, that single image may take longer to load than the hundreds of thumbnails.

The search result images have been optimized for speed over quality. They are dimensionally smaller than the original and are of discernibly lower quality. Image optimization is ultimately about providing the best user experience, and that is not in all situations dependent on high-quality, high-resolution imagery.

Shedding the digital calories. Here’s the thing about digital images. They are bloated and contain far more visual information than our displays can accurately represent in pixel density, and more importantly, than our eyes can discern at the typical sitting distance to a display.

If you want to test this for yourself, print out a full-resolution digital image you took on one of those photo printing booths. Open that same photo in your favorite photo editor (I use Photoshop CS) and save a copy of the image in 100 dpi. Open it full screen and compare the printed image to the digital version at normal viewing distance. Test how much visual difference you can discern.

What considerations should I factor into my optimization choices?

1. Which is more important to the user? Fast results, or high-quality images?  I highly encourage user testing your product concepts. Otherwise, how do you know?

2. What level of quality loss can we accept before the image becomes less useful to the viewer? Another push for user testing.

3. What limitations does our hardware and software place on delivery results?

4. What level of loss can we accept before the quality of the results reflects negatively on the expectation people have for our brand?

5. What does the internet service look like in the areas where our target demographic lives?

Reduction in load on resources. Storing huge image files on a server eats up your available storage space, space that you are paying for based on a tier. I don’t like spending more money than I need to, and I am sure you don’t either. Additionally, serving up large files bogs down a network. You may be able to serve up high-resolution images to one or two people at a time without an issue, but what about hundreds of visitors trying to load a page with multiple high-resolution images at the same time? At some point, the load increases to a point where the hardware cannot keep up, and your users experience pays the price.

This brings us to bandwidth.

Broadband is expensive, and still in short supply. If you are lucky enough to live in an industrialized nation, with widely available and affordable high-speed internet, congratulations! You are in the minority.

In the US and Europe, only about 50% of the population have a broadband subscription. Things are far worse in Asia, Africa, and the Middle East, where the percentages drop into the teens and single digits. In developed nations where the majority of internet use has gone mobile, subscribers experience data caps that are costly to exceed, and equally expensive to upgrade.

You are building a product for these users. Don’t punish their bandwidth for visiting your website. Reward their choice to visit your site with a fast-loading and optimized experience. If you don’t, you are definitely going to drive up those bounce rates and annoy the people you are trying to solicit.

Continue to Pt. 2 →

My hope at this point is that I have convinced you of the importance of proper image optimization. From here, we will dive into the methods. I will also provide recommendations on tooling for specific situations, but I strongly encourage you to try other methods to see what works best for your images and your workflow.

As mentioned in part 1 of this article, there is no “right” way to optimize every image, and there are certainly lots of ways to do it. The first thing to consider is, “how many images do I need to process?” If it is just a couple of images, it is simple enough to just optimize them manually, one at a time in your favorite image editor. If you have a large batch of images, then automation is usually the better approach. We will explore the manual approach in this section.

The manual approach.

While manually processing your files is the more tedious option, it does provide several advantages ,  the first of which is maximum control.

When you use automation (more on that later), you are using a tool to apply an algorithm to your images in a best case scenario. They may come out looking perfectly fine, but still contain more visual data than you actually need. A smaller file size than before, but not necessarily as small as they can be.

For small thumbnails and graphics, the savings may not be very much, but for large banner images, you are definitely going to want to trim as much fat as possible.

When going the manual route, there are a couple of tools that I keep in my toolbox, and which one I use depends on the image compression format I will be using.

Modern browsers can render just about any image format you throw at them, but each browser has an optimal format. The process of targeting browsers with their preferred format gets a bit out of scope for this primer, but you should definitely check out this article by the legendary Chris Coyier for more on that.

Common image formats used on the web include .jpeg (also represented as .jpg due to early Windows OS three-letter file extension requirements), Apple's preferred format .png, my personal favorite — .svg, and .gif (which actually predates the modern internet).

The newest format intended for web use is .webp, stylized as webP. WebP compression promises to provide the artifacting reduction of .png in a file size up to 45% smaller than .png. WebP is being pushed by Google.

(Click the image for a high-resolution version)

Working with .jpg

Over the years, I have found Photoshop to be the best tool to use when manually optimizing your images. Photoshop also provides the ability to batch process your images if needed. There are actually two methods to optimize and export images in Photoshop: “save as” and “save for web”. Save for web is a legacy feature, but it provides you with the most control over the output appearance.

Closest neighbors and artifacting

When working with JPG optimization, there are a few things to keep an eye out for. First, JPG compression works by the concept of “closest neighbor”. When the “closest neighbor” is a large block of a single color, artifacting is rarely an issue because all neighbors are the same color. The problem comes when you have an image with a subtle gradient, or lots of vertical components in the photo. As you compress the image, the algorithm starts dropping pixel data. In order to maintain the same image dimensions, your image editor starts duplicating adjacent pixels to fill the void left by the removal. The more you compress, the more pixel data is dropped and replaced with “closest neighbor” color data.

You may be asking, “So if you are removing the data, only to replace it with new data, how is this file compressing?”

To answer that, let's take a look at the image below. Let's imagine that this image is a zoomed-in look at a row of pixels within a gradient.

In this image, we have 5 colors, all shades of blue. Each color must have its own representation in the image source that defines the color and position of the pixel. In a JPG, each pixel uses 8 bits of data. In this example, if each block was a single pixel, we would have an image size of 40 bits.

Let's simulate compression.

After compression, we have the result above. Still a gradient, but now each color utilizes two pixels. What happened?

Well, the software looked at the closest neighbor and replaced the original color with an adjacent match. Now we only have to store 3 colors, and a pointer to the location where the color was changed, as opposed to storing the actual color information for each individual pixel. If you had a row of 10 identically blue pixels, the JPG would store the color once and a pointer for where to start and stop repeating the color before the next color shift.

In this contrived example, we have reduced the file to 24 bits, a reduction of about 50%. While this certainly gets the job done, it does leave us with some concerns.

The more compression you apply, the more color repetition you have. Gradients will be reduced in color variation and start to produce banding, as seen in the example below.

A second issue arises with artifacting. Artifacting typically occurs when there is a sharp contrast between adjacent pixels and not enough file space to store a new transitional color.

Another type of artifacting occurs when dealing with text. Pixels get replicated from one or both contrasting colors while trying to smooth out the transition. The result is pixels that are not copies of their neighbors but rather a pixel that is a mix somewhere between the source colors. The result can be seen below. For this reason, I strongly recommend not using JPG for text.

To avoid this, observe the following suggestions when optimizing a JPG.

1. If you have an image with a lot of gradient color, either limit the amount of compression you apply or consider using another format for the image ,  .png, for example.

2. Never apply additional compression to a .jpg that contains text. It is better to not include text at all in an image, but if you must, don’t use .jpg.

3. Banding can be disguised by adding a small amount of noise to the photo, but remember, doing this adds more pixel data back into the image, increasing its file size.

Working with .png

The way that compression works with PNGs is a more advanced topic and falls outside the scope of this article series. If you are interested in learning about how PNG compression works, check out this article.

PNGs do not compress as well as JPGs. In fact, compressing them often requires stripping out a color channel, specifically the alpha channel. Obviously this is counterintuitive if your image requires transparency. To get around this, consider not using transparency in your graphics and instead make the background the same color as the background on your site. You can then omit the alpha channel.

One of the simplest tools I have found to handle the task of optimizing PNGs is TinyPNG. TinyPNG will strip out the alpha channel (in addition to other optimizations) for you with a simple drag and drop. It also supports batch processing if you have a large set of PNGs to optimize.

Drawbacks of PNG compression

In my experience, I have found that compressing a large PNG for use in banners is often less than satisfactory. The image may take on a blotchy look, similar to a GIF. This is much less noticeable when used on smaller graphics that lack large gradients and large color blocks. This does not happen with all optimized PNGs, but it is enough of an issue that it needs to be mentioned. You will have to test your images and inspect after processing. If any take on a blotchy appearance, consider using JPG instead.

Working with .svg

SVG is hands down my favorite format to work with. It is powerful, versatile, and tiny compared to the rest. SVG is short for Scalable Vector Graphics, an XML Vector based format. It is also the one format that you can open in any text editor to see and manipulate the code.

XML is a list structure for collections of data. Outside of SVG, XML has largely been replaced by JSON.

When you open the file, you will see several pieces of information. A header that defines the file as XML-based, a list of styles being applied to the elements, and below that all the image data. The data here represents vectors that define the shapes, curves, lines, text, and effects. Each element of the artwork will be grouped in a tag. Using CSS or JS, we can target the vector groups to do things like animating the elements. That is what makes SVG ideal for use in web animation.

Optimizing SVG

SVGs generally do not need to be optimized and can be used as is. However, there are ways to reduce its size if desired.

Clean up the source

One thing you can do is remove some of the unnecessary meta data in the head of the file. Often the software you use to create the SVG will add additional data to the file that is not required for the file to render. This includes both comments and some meta. Be careful. You DO NOT want to remove any of the following:

1. Version number

2. Encoding information

3. Viewbox sizing (though you can manually change the values if you need)

4. Style data

5. Any of the vector data

Chop the decimals

The second thing you can do to optimize an SVG takes place when exporting. In most SVG editing software you will have some export options available. One of those options involves vector accuracy, and that accuracy depends on how many decimal places you store for each vector. Choosing 0 would result in no decimal places. For straight lines this will not create much problem, but when you have arcs and curves, accuracy is vital to maintain the smoothness of the curves.

I recommend using no more than 3 decimal places in all cases, but you can reduce the file size considerably by dropping it to 1 or 2 decimals. You will have to experiment with your SVGs to achieve the best results and the smallest possible file.

Concisely put, the more decimal places, the larger the file size and the more accurately the image will render. The fewer decimal places, the less accurate and smaller the file size.

Drawbacks of SVG

While SVG is a great option, it is not always the best choice. SVGs are best for illustrations, but not so great for images. While you can embed other image formats inside of an SVG, doing so is counter to optimization. If a flat illustration is what you need, SVG is the answer. Otherwise, go with one of the other format options.

Tools of choice: My go to tools for handling SVGs are Adobe Illustrator and Affinity Designer.

Working with .gif

Some call it a “giff”, others call it a “jiff”. The GIF format has been around since the early days of BBS ; It’s longevity reflects its simplicity and versatility. It supports animation within the indexed color scheme and this makes it a common format for memes, video clips, and loader animations. It is also a great option for icons and other simple visual elements.

Optimizing a GIF

GIFs are already relatively small in file size as a side effect of its limited color range, but that does not mean they cannot be optimized further. To do so, focus exclusively on the color palette.

GIFs can contain up to 256 colors, though the fewer colors you use in the palette the smaller the resulting file. Optimizing a GIF is a pretty manual process, and the savings are often not worth the effort. If you do choose to optimize your GIFs then I suggest considering how exact the color representation must be.

Let’s consider an icon comprised of 6 different colors. Are all 6 colors really needed? Would the icons still work well using only 4 of the 6 colors? If so, go ahead and adjust your palette down to 4 colors in your GIF editor. You just reduced your file size by ~33% and still have an icon that looks like an icon. I strongly suggest that before making a decision about editing a graphics color palette that you first consult with the person that designed the project.

Drawbacks of the GIF format

No image format is free from issues, and GIFs are no exception. GIFs are not only color limited, they also do a poor job with aliasing — especially if using transparency. A side effect of color indexing is the limitation it places on smoothing out colors and edges. In order to improve the AA (anti-aliasing), you need to make more colors available, thus increasing the file size. Take a look at the image below for a visual on this problem.

With AA off, you have a total of 5 indexed colors. While this will result in a very small file size, it will appear very rough around the edges. The second image demonstrates AA enabled with 5 point sampling. The sharp edges start to smooth out as you increase the sample size. At 25 samples, aliasing is under control but you now have a much large file size. In this case, a JPG, PNG or webP image may actually be better option to use.

If your graphic contains all straight lines, or if you don’t care about rough edges, consider going with GIF. On the other hand, if you need an image with smooth color transitions, improved AA, and a broad color palette, go with JPG or PNG.

Tools of choice: My go to tools for handling GIF optimization is Photoshop, however there are tons of free tools online to use if you don’t have access to PS.

Working with .webP

WebP started at Google around 2010 as a way to get smaller image files without looking worse than JPEG or PNG, basically a modern container that can do lossy photos, lossless graphics, and transparency in one format. It grew out of work related to the VP8 video codec, and the idea was simple: if browsers could decode it natively, sites could deploy less data and pages would feel snappier. Adoption was slow at first because Safari lagged, but once the major browsers caught up it became a practical default for the web instead of a niche experiment.

Optimizing WebP

To opptimize webP, start with a clean original, then decide how big the image really needs to be on the page (hero full-bleed vs thumbnail vs content photo). Export a WebP at roughly that display size, not a huge camera file you’ll downscale in CSS. Photos and atmospheric heroes do well as lossy WebP; start around quality 70–80 and only go lower if it still looks fine zoomed to real size. Sharp UI, logos, or screenshots with text usually want lossless (or a higher quality) so lines and lettering don’t get soft or blotchy.

For the actual optimize step, pick a tool that matches how you work. Squoosh is the easiest for one-offs: drop the file in, flip between quality settings, and watch the kilobytes change. If you’re already in Photoshop or Affinity Photo, export WebP straight from there after you’ve cropped/resized. For a folder of images, cwebp, ImageMagick, or a small Sharp script in Node will batch it. On a Mac, ImageOptim is a nice “drag a bunch of files and go” option; TinyPNG (and friends) work if you want a quick web upload without installing anything.

Are you still here?

That wraps up the common web supported image formats, and with that, this two part image optimization series. Hopefully you are convinced about the importance of image optimization for the web and this series helps you determine the best format and optimization techniques for each use case.

Are there any tips you have for image optimization that this series did not cover? Drop your suggestions in the comments.

*If you are looking to avoid an Adobe subscription then there is also the powerful and free application GIMP.

A simple solution to a longtime UI issue — “what the heck do I do with those form labels to keep them nicely on one line?” You could left align them to the field, but this of course introduces unsightly spacing and alignment issues due to the varying length of label text. You could use hang-on placeholders in lieu of labels — which works, but introduces other accessibility issues. You could stick them right above or below the fields, but this makes it difficult to condense the form.

Slide away labels solves all of these issues! There are many different versions of this feature, some more successful than others. This is my version of the solution.

Here is an example of what we will be building:

In this example, we use jQuery for its concise and cross-platform .focus() method, but you can use vanilla Javascript instead if that is what you prefer. First, we need to markup the form. We will use 3 fields and a button in this simple example. Each label and input is wrapped in a .field-wrapper class in order to provide a needed parent element for each field.

<form onSubmit="JavaScript:submitFunction()" id="contact-form" method="post">
  <div id="form">
    <div class="field-wrapper">
      <label>First name</label>
      <input
        id="firstName"
        required
        type="text"
        name="first_name"
        class="form-control"
      />
    </div>
    <div class="field-wrapper">
      <label>Last name</label>
      <input
        id="lastName"
        required
        type="text"
        name="last_name"
        class="form-control"
      />
    </div>
    <div class="field-wrapper">
      <label>Phone number</label>
      <input
        id="phoneNumber"
        required
        type="tel"
        name="phone"
        class="form-control"
      />
    </div>
  </div>
</form>

Next, some basic CSS to style the form. We also add our label transition animation. The label is set to pointer-events:none to allow the click to pass through to the input field.

#form{ margin-top:50px;}

.field-wrapper{ position:relative;}

label{ 
   position:absolute; 
   top:7px; 
   margin-top:0; 
   pointer-events: none; 
   -webkit-transition: all .2s ease-in-out; 
   transition: all .2s ease-in-out; 
   font-size:17px;
}

.form-control{ 
   padding:10px 0 0 0 !important; 
   font-size:22px; 
   border:none; /* remove the default field borders */ 
   border-bottom: 1px solid grey; 
   background: white; 
   height:auto; 
   color:black;
}

.form-control:focus{ 
   border-bottom: 1px solid green; 
   -webkit-box-shadow: none; 
   box-shadow: none;
}

#btnSubmit{ margin-top:30px;}

.openup{ margin-top:-20px; font-size: 14px;}

Finally, we add our script. The idea here is that when the input field is selected, we attach an .openup class that initiates the transition. I usefocus() here instead of on() to support keyboard operations. Also, we update the underline to indicate the active input. Of course, you can style the active state however you like.

You may notice that I am setting the borders twice here. First I set all input field borders back to default grey, then I set the active field border state. I did this so that I don’t have to track the previously active input field.

$('.form-control').focus( function(e) {       
   $(this).parent().find('label').addClass('openup');    
   $('.form-control').css('borderBottom', '1px solid grey'); 
   $(this).css('borderBottom', '1px solid rgb(111, 189, 68)');  });

That's it! See it working in this Fiddle.

*Thanks /u/max_kek !