DEV Community: Samuel Ruiz

BENEFITS OF MODELING

Samuel Ruiz — Wed, 11 Feb 2026 22:19:48 +0000

Enhanced Requirements Management
Streamlined requirements generation.
Increased end-to-end traceability.
Superior System Design
Reduced design errors and inconsistencies.
Enhanced analytical capabilities and system quality.
Operational Effectiveness
Lowered total lifecycle costs.
Reduced overall schedule duration.
Note: Does not typically reduce initial systems design time.
Long-term Strategic Value
Increased capacity for component reuse.
Advanced support for automation and tool integration.

What to Review Before Merging to `main`: A Practical Code Review Checklist

Samuel Ruiz — Tue, 20 Jan 2026 19:42:29 +0000

Merging to main is not a formality. It’s a commitment.
Once code lands there, it becomes someone else’s problem, future you’s problem, and potentially production’s problem.

Here’s a checklist I use before approving any pull request. If these points aren’t met, the code is not ready.

1. Unit Tests Exist (or There’s a Real Reason They Don’t)

If there are no unit tests, the default assumption is that the code is incomplete.

Questions to ask:

Are unit tests present for new logic?
If not, is there a clear, documented reason why?
Is this logic testable at all?

“No time” is not a valid reason.
“No idea how to test it” is a red flag.

2. Unit Tests Actually Assert Behavior

Tests without assertions are meaningless.

Things to verify:

Every test has at least one assertion
Assertions validate behavior, not just execution
Tests fail when the feature breaks

Bad tests give false confidence.
A green test suite that proves nothing is worse than no tests at all.

3. UI Matches the Design System

Code that “works” but ignores design standards creates silent debt.

Check for:

Correct colors (tokens, not hardcoded values)
Consistent padding, spacing, and alignment
Proper positioning across breakpoints
No “close enough” UI decisions

If the team has a design system, use it or explain why you didn’t.

4. The Code Is Readable, Simple, and Intentional

Before merging, ask yourself:

Does this code make sense at first glance?
Are variable and function names clear?
Is there unused or dead logic?
Is complexity justified—or accidental?

Also verify:

The code follows existing team patterns
No custom abstractions where simple logic would do
No clever tricks that reduce readability

Readable code scales. Clever code breaks teams.

5. It Works on Mobile and Touch Screens

Desktop-only thinking ships broken products.

Validate:

Responsive layout (small, medium, large screens)
Touch targets are large enough
No hover-only interactions
Scroll, focus, and keyboard behavior make sense

If it fails on a phone, it fails—period.

6. Folder Structure and File Placement Are Correct

Where code lives matters.

Check that:

Files follow the established folder structure
No random dumping into utils, helpers, or components
The structure communicates intent

Poor structure compounds fast and is painful to undo later.

7. Storybook Exists (When It Should) and Covers All States

If the project uses Storybook, it’s not optional.

Verify:

Stories exist for new components
All important states are covered:
- Loading
- Empty
- Error
- Disabled
- Edge cases

If a component has logic and UI states, it should be explorable in isolation.

8. Performance Has Been Considered

Performance issues rarely announce themselves—they sneak in.

Look for:

Unnecessary re-renders
Expensive calculations without memoization
Effects firing too often
Large lists without virtualization
Over-fetching data

You don’t need to over-optimize—but ignoring performance entirely is irresponsible.

9. ESLint and Prettier Are Clean

This is the easiest check and the least negotiable.

Before merging:

ESLint errors are fixed
Warnings are intentional and justified
Prettier has been run
TS compiler passes with no errors
No formatting noise in the diff

If tools can fix it automatically, humans shouldn’t review it.

Final Rule Before Merging

Before approving, ask yourself one last question:

Would I be comfortable owning this code six months from now?

If the answer is no, don’t merge it.

Code reviews aren’t about blocking people.
They’re about protecting the codebase—and the team—from unnecessary pain.

Here's a checklist you can follow

🧪 Testing

[ ] Unit tests exist for all new or changed logic
[ ] All unit tests include meaningful assertions (no empty or “render-only” tests)
[ ] Tests validate behavior, not implementation details
[ ] Edge cases are covered (errors, empty states, boundaries)
[ ] Tests are deterministic (no random values, real dates, or timing issues)

🎨 UI / UX (If Applicable)

[ ] UI follows the design system (colors, spacing, typography, positioning)
[ ] No hardcoded styles where design tokens exist
[ ] Layout is responsive (mobile, tablet, desktop)
[ ] Works correctly on touch devices (no hover-only interactions)
[ ] Accessibility basics are respected (focus, contrast, click targets)

🧠 Code Quality

[ ] Code is easy to read and understand
[ ] No unused variables, functions, or dead logic
[ ] Complex logic is justified and documented (or refactored)
[ ] Naming clearly reflects intent
[ ] Code follows existing team patterns and conventions

📁 Project Structure

[ ] Files follow the established folder structure
[ ] No “dumping” code into generic folders (utils, helpers, etc.)
[ ] New folders or patterns are explained and intentional

📘 Storybook (If Applicable)

[ ] Storybook stories exist for new components
[ ] All relevant states are covered:
- [ ] Default
- [ ] Loading
- [ ] Empty
- [ ] Error
- [ ] Disabled / Edge cases

⚡ Performance

[ ] No unnecessary re-renders
[ ] Expensive logic is memoized or optimized
[ ] Effects and subscriptions are scoped correctly
[ ] Large lists or heavy UI are handled efficiently

🧹 Tooling & Standards

[ ] ESLint passes with no errors
[ ] Prettier has been run
[ ] No unnecessary lint disables
[ ] CI checks are green

🧾 Final Confirmation

[ ] I would be comfortable maintaining this code in 6 months
[ ] This PR is ready to be merged into main

Most React Code Is Hard to Read Because Developers Ignore This One Rule

Samuel Ruiz — Tue, 20 Jan 2026 19:28:16 +0000

Naming is one of the cheapest ways to prevent bugs and mental overhead in React/JS codebases.

Below are practical, opinionated naming conventions that actually matter—with examples that make intent obvious at the call site.

1. Naming Functions

If you need comments to explain what a function does, the name already failed. The naming of a function should tell you what's about without having you read the function definition.

❌ Bad

getUser()

✅ Good

fetchUserAPI()      // network
calculateUserAge()  // pure

Why it matters

You instantly know what can fail and what can be a synchronous function.

2. Async Functions Must Signal Asynchrony

Rule: Async work should be visible without reading implementation.

❌ Bad

getOrders()

✅ Good

getOrdersAsync()
fetchOrdersApi()
loadOrders()

Strong signal hierarchy

fetch* → network
get* → synchronous access

3. React Components vs Utilities

Rule: Components are nouns. Utilities are verbs.

❌ Bad

RenderUser
UserHandler

✅ Good

UserCard        // component
UserList        // component
formatUserName // utility

Bonus

Components never start with verbs.
Utilities always start with verbs.

4. Event Handlers

Rule: Events describe what happened, not what you’ll do.

❌ Bad

submit()
click()

✅ Good

handleSubmit()
handleUserClick()
handleModalClose()

React-specific

Always prefix with handle
Makes JSX scanning painless

5. Boolean Variables

Rule: Booleans must read like a yes/no question.

❌ Bad

loading
active
valid

✅ Good

isLoading
isActive
isValid
hasAccess
canEdit

If it sounds awkward in an if, it’s wrong.

if (isUserAuthenticated) ✅
if (userAuthenticated) ❌

6. State Setters (React)

Rule: Setters must mirror state exactly.

❌ Bad

const [open, toggleOpen] = useState(false);

✅ Good

const [isOpen, setIsOpen] = useState(false);

Why

Predictable
Greppable
No surprises for teammates

7. Files That Touch the Outside World

Rule: Files that hit the world should scream.

❌ Bad

user.ts
utils.ts
helpers.ts

✅ Good

user.api.ts
user.service.ts
user.mapper.ts

Now you instantly know:

.api.ts → network
.mapper.ts → transformations

NOTE: You don’t need to specify the file type (user.api.ts) as long as the file is under the ./apis folder.

8. Hooks

Rule: Hooks describe what they provide, not how.

❌ Bad

useFetchUser()

✅ Better

useUser()
useAuthenticatedUser()
useUserPermissions()

Let the hook hide implementation details.

Mental Model Summary

Good naming answers these without reading code:

Question	Naming Signal
Hits the network? Async?	`fetch`, `.api.ts`, `fetch`, `load`, `Async`
Mutates state?	`set`, `mutate`, `append`
Pure logic?	`calculate`, `format`
UI component?	PascalCase noun
Boolean?	`is`, `has`, `can`

Common Third-Party GUI Integration Patterns

Samuel Ruiz — Tue, 06 Jan 2026 18:50:05 +0000

At some point, almost every product needs to embed or integrate a third-party UI: payments, analytics, scheduling, support widgets, internal tools, or partner features.

There are four common patterns, each with very different tradeoffs around security, UX, ownership, and complexity:

🧱 Iframe embed
📜 Script tag / JavaScript SDK
📦 NPM package / component library
🧬 Micro-frontend (MFE)

Choosing the wrong one early can lock you into painful rewrites later.

⚡ Quick Decision Guide

🛡️ Safest, fastest “just embed it” → Iframe
⚠️ Quick integration + tight UX (accepts global JS risk) → Script tag / JS SDK
🎯 Best UX + full control + shared design system → NPM package
🏗️ Independent deploys + large teams → Micro-frontend (MFE)

If you’re unsure, start with iframe. You can always move down the list—but moving up is expensive.

🧱 1. Iframe Embed

🔍 What it is

You render third-party UI inside an <iframe> pointing to a URL hosted by the vendor (or another internal team).

The iframe runs in a separate browsing context, isolated from your app’s JS and CSS.

💻 Basic Example

<iframe
  src="https://vendor.example.com/widget?tenant=acme"
  title="Vendor Widget"
  width="100%"
  height="700"
  loading="lazy"
  style="border:0; border-radius:12px;"
></iframe>

🔐 Secure Sandbox Example

<iframe
  src="https://vendor.example.com/widget?tenant=acme"
  title="Vendor Widget"
  width="100%"
  height="700"
  sandbox="allow-scripts allow-forms allow-popups"
  allow="clipboard-read; clipboard-write"
  style="border:0;"
></iframe>

🔁 Parent ↔ Child Communication (`postMessage`)

Parent

const iframe = document.getElementById("vendor-iframe") as HTMLIFrameElement;

window.addEventListener("message", (event) => {
  if (event.origin !== "https://vendor.example.com") return;

  if (event.data?.type === "READY") {
    iframe.contentWindow?.postMessage(
      { type: "SET_THEME", theme: "dark" },
      "https://vendor.example.com"
    );
  }
});

Child

window.parent.postMessage(
  { type: "READY" },
  "https://host.example.com"
);

✅ Pros

🛡️ Strong isolation (security, CSS, JS)
🔄 Easy rollback
🚀 Vendor deploys independently

❌ Cons

🎨 Styling consistency is harder
🔁 Requires postMessage plumbing
🔍 SEO & accessibility limitations

🎯 Use when

Vendor is untrusted
Security > UX polish
You want minimal blast radius

📜 2. Script Tag / JavaScript SDK

🔍 What it is

A vendor-hosted script injects UI or exposes a global SDK that runs inside your app’s origin.

💻 HTML Example

<div id="vendor-root"></div>

<script src="https://cdn.vendor.com/widget/v1/widget.min.js"></script>
<script>
  VendorWidget.mount("#vendor-root", {
    tenant: "acme",
    theme: "light",
  });
</script>

⚛️ React Wrapper Example

import { useEffect, useRef } from "react";

export function VendorWidget({ tenant }: { tenant: string }) {
  const ref = useRef<HTMLDivElement>(null);

  useEffect(() => {
    const instance = (window as any).VendorWidget.mount(ref.current, { tenant });
    return () => instance?.unmount?.();
  }, [tenant]);

  return <div ref={ref} />;
}

✅ Pros

🎯 Better UX than iframe
⚡ Fast integration
🧩 No build-time dependency

❌ Cons (Real Risks)

☠️ Executes untrusted JS in your origin
🎨 CSS / global JS conflicts
🐞 Painful debugging
📦 CDN version drift

🛡️ Required Safety Measures

🔒 Pin exact versions
🧾 Use SRI
🚧 Lock down CSP
🧩 Demand namespaced CSS or Shadow DOM

🎯 Use when

Vendor is trusted
Widget is small
Speed matters more than isolation

📦 3. NPM Package / Component Library

🔍 What it is

You install the vendor UI as a dependency and render it directly.

This gives the best UX—and the most responsibility.

📥 Install

npm install @vendor/ui @vendor/sdk

⚛️ React Example

import { VendorCheckout } from "@vendor/ui";

export function Checkout() {
  return (
    <VendorCheckout
      customerId="cust_123"
      theme="light"
      onSuccess={(result) => console.log(result)}
    />
  );
}

✅ Pros

🏆 Best UX
🧪 Fully testable
🔢 Explicit version control
🎨 Design system alignment

❌ Cons

📦 Bundle size impact
🔗 Dependency conflicts
💥 Vendor bugs can break builds
🚫 No isolation

🧠 Best Practices

🔒 Pin versions
⏳ Lazy-load heavy UI
🧱 Wrap with adapter components

🎯 Use when

UI is core to your product
You own UX decisions
You accept upgrade ownership

🧬 4. Micro-Frontend (MFE)

🔍 What it is

A separately built and deployed frontend loaded at runtime.

🏗️ Host Loader Example

async function loadRemote(url: string) {
  await new Promise<void>((resolve) => {
    const s = document.createElement("script");
    s.src = url;
    s.onload = () => resolve();
    document.head.appendChild(s);
  });

  return (window as any).RemoteApp;
}

🔌 Remote App Contract

export function mount(el: Element, opts: { tenant: string }) {
  return { unmount() {} };
}

(window as any).RemoteApp = { mount };

✅ Pros

🚀 Independent deploys
🧑‍🤝‍🧑 Team scalability
🔄 Shared runtimes

❌ Cons

🧠 High complexity
🔗 Version coordination pain
🐢 Slower local dev

🎯 Use when

Multiple teams
Independent release cycles
Large UI surface area

📊 Comparison Table

Pattern	Isolation	UX	Complexity	Risk
🧱 Iframe	High	Medium	Low	Low
📜 Script SDK	Low	High	Low	Medium–High
📦 NPM Library	Low	Very High	Medium	Medium
🧬 MFE	Medium	High	High	Medium

⚠️ Critical Engineering Concerns

🔐 Authentication

Avoid long-lived tokens in URLs
Prefer short-lived sessions
Never expose secrets to iframes

🎨 Styling

Use theme contracts
Avoid global CSS
Prefer Shadow DOM when possible

⚡ Performance

Lazy-load non-critical UI
Cache remote assets
Watch for duplicate bundles

🛟 Reliability

Loading states
Timeouts
Graceful fallbacks

🧭 Practical Recommendations

🛡️ Untrusted vendor → Iframe
⚠️ Trusted widget → Script SDK
🎯 Core UI → NPM library
🏗️ Large org → MFE

3 Secrets to Perfectly Printed Web Pages

Samuel Ruiz — Wed, 10 Dec 2025 23:16:41 +0000

Generating PDFs in a modern web app sounds simple—until you actually try to do it. Between browser limitations, inconsistent HTML rendering, sandboxed environments like Electron, and the need for pixel-perfect output, developers quickly realize there’s no one-size-fits-all solution. Different tools solve different problems. Some libraries are great for building PDFs from scratch, others are ideal for filling existing templates, and some are the only reliable way to recreate a webpage exactly as it appears on screen.

Some tools excel at building PDFs from scratch with custom layouts. Others are perfect for filling existing PDF templates. And a completely different set of tools is required when you need a PDF that looks exactly like the webpage your users see.
If you choose the wrong approach, you’ll waste hours fighting broken CSS, missing fonts, cut-off pages, or slow rendering.

This guide cuts through the noise and breaks down the most practical, battle-tested methods — from browser printing and React-based rendering to low-level PDF manipulation, HTML conversion engines, and Electron-specific techniques — so you can choose the right strategy for your app and avoid a weekend of debugging

The multiple ways to print PDFs

Comparing methods
1. Browser shortcut - Ctrl + P (Windows) or Cmd + P (Mac)
2. React-pdf
3. pdf-lib
4. jsPDF
Recommendations
Client side vs Server side print

Comparing methods

Browser "Print to PDF" (Fastest, but not the cleanest)

Every browser can do this.

How does it work:

Open your webpage
Press Ctrl + P (Windows) or Cmd + P (Mac)
Select Save as PDF
Adjust margins, background graphics, and layout

Pros:

Simple
No setup needed

Cons:

Often messy layouts
Doesn't handle long pages well
Breaks when your website uses animations, dynamic content, or infinite scrolling
Electron app doesn't work with ctrl+p. Use Electron's webContents.printToPDF() API.

// main.js
const { BrowserWindow, ipcMain, dialog } = require('electron');

ipcMain.handle('export-current-view-to-pdf', async (event) => {
  const win = BrowserWindow.fromWebContents(event.sender);
  const pdfBuffer = await win.webContents.printToPDF({
    printBackground: true,
    marginsType: 1, // default
    pageSize: 'A4',
  });

  const { filePath } = await dialog.showSaveDialog(win, {
    title: 'Save PDF',
    defaultPath: 'export.pdf',
    filters: [{ name: 'PDF', extensions: ['pdf'] }],
  });

  if (!filePath) return { canceled: true };

  const fs = require('fs');
  fs.writeFileSync(filePath, pdfBuffer);
  return { canceled: false, filePath };
});

Renderer:

// renderer (React)
await window.electron.invoke('export-current-view-to-pdf');

React-pdf

A react-based renderer that lets you build PDFs using React components, similar to building a UI. Think of it like "writing JSX for a PDF file".

When to use react-pdf?

A custom-designed PDF layout (contracts, invoices, quotes, receipts)
Full control over spacing, fonts, margins, page breaks
A PDF that does NOT look like your website, instead a professionally formatted document
Server-side or client-side generation with React/Next.js

Pros:

Custom layouts
Use your React knowledge (JSX components)
Good for complex multi-page PDFs
Supports images, tables, styling

Cons:

Slow for heavy PDFs
Not ideal for turning an existing webpage into a PDF
Styling is limited compared to CSS
Leaning curve (if no previous experience of React)

import { Page, Text, Document, StyleSheet } from '@react-pdf/renderer';

const styles = StyleSheet.create({
  page: { padding: 30 },
  title: { fontSize: 20, marginBottom: 10 }
});

export const MyPDF = () => (
  <Document>
    <Page style={styles.page}>
      <Text style={styles.title}>INRI Paint & Wall LLC Estimate</Text>
      <Text>Total: $6,800</Text>
      <Text>Includes wood replacement, caulking, and painting.</Text>
    </Page>
  </Document>
);

pdf-lib

A low-level PDF manipulation library. It's extremely powerful, you can modify existing PDFs, merge, split, add pages, add images, write text anywhere. Think of it like "photoshop but PDFs in JavaScript".

You can take a PDF contract, then fill in:

Client name
Address
Price
Dates
Signature image

Pros:

Modify existing PDFs
Compact and fast
Very flexible
Supports images, font embedding
No React required

Cons:

Not meant for designing full layouts from scratch
Harder to position elements (you must use coordinates)
Does Not covert webpages to PDFs

import { PDFDocument } from 'pdf-lib';

const existingPdf = await fetch('/contract.pdf').then(res => res.arrayBuffer());
const pdfDoc = await PDFDocument.load(existingPdf);

const pages = pdfDoc.getPages();
const firstPage = pages[0];

firstPage.drawText('Client: Steve', { x: 50, y: 700 });
firstPage.drawText('Price: $6,800', { x: 50, y: 680 });

const pdfBytes = await pdfDoc.save();
// download or return via API

jsPDF

A very popular, older library for generating PDFs in the browser. Works with HTML or manual drawing commands. Think of it like "Quick PDF generator, simple and lightweight".
You can take sections of your webpage and convert it. You can also manually write text, draw lines, and add images.

Pros:

Easy to use
Supports HTML-to-PDF
Good for simple PDFs
Fast on small documents

Cons:

Not good for complex layouts
HTML rendering is inconsistent
Not great for long PDFs
Struggles with modern CSS

import jsPDF from 'jspdf';

const pdf = new jsPDF();
pdf.text("INRI Paint & Wall LLC", 10, 10);
pdf.text("Exterior Paint Quote: $6,800", 10, 20);
pdf.save("quote.pdf");

Headless Browser Rendering (Puppeteer/Playwright)

These tools use a headless Chrome instance to generate PDFs. This produces pixel-perfect output, identical to what you see in the browser. Perfect when you need your PDF to look like the webpage (consistent styles, fonts, and layout), and when generating long or multi-page documents.

Pros:

Pixel perfect
Handel long pages correctly

Cons:

Requires a backend
Not ideal for purely client-side apps

const browser = await puppeteer.launch();
const page = await browser.newPage();

await page.goto("https://yourcompany.com", {
  waitUntil: "networkidle0",
});

await page.pdf({
  path: "page.pdf",
  format: "A4",
  printBackground: true,
});

await browser.close();

Client side vs Server side print:

Client side: Generating big PDFs on the renderer thread can freeze the UI, making your app feel janky, especially with long documents or many images.
Server side: Requires a backend server and not ideal for purely client-side apps.

Recommendations:

Which Library Should You Use?

“I want the PDF to look exactly like my webpage”
Use: Puppeteer or Playwright (Only reliable option)
“I need a professional layout (invoice, contract, estimate)”
Use: react-pdf
“I already have a PDF template (like a contract) and I just need to fill fields”
Use: pdf-lib
“I want a quick HTML → PDF in the browser”
Use: jsPDF (but be ready for CSS issues)
“I need millions of PDFs server-side”
Use: Puppeteer + caching or streaming
“I need dynamic client-side generation without a backend”
Use: react-pdf or jsPDF

Before You Can Make $500k+, You Must First Challenge the Beliefs Holding You Back

Samuel Ruiz — Fri, 14 Nov 2025 16:26:17 +0000

Your path to a six-figure salary depends on three things:

Mastering the right tools
Entering a well-paying industry
Cultivating the belief that you deserve success

Here’s the guide that helped me break my limiting beliefs and secure a great salary.

First, I had to confront my biggest weaknesses:

Caring too much about being “nice”
Comparing myself to everyone else’s highlight reel
Forgetting that nobody fully knows what they’re doing all the time

Not senior devs.
Not staff engineers.
Not FAANG engineers.
Nobody.

The difference?

Seniors operate despite uncertainty. Juniors freeze because of it.

Let’s change that.

🔥 Step 1 — You’re Not Lacking Skill. You’re Lacking Evidence.

Your brain doesn’t trust you yet.

When you say “I don’t feel good enough,” it’s because your brain has no proof that you finish things consistently.

So let’s give it evidence.

✔️ Do this daily:

Solve one bug — any size
Finish one small task
Write one technical explanation (even rough notes)

Three small wins a day build unstoppable confidence in 30 days.

🔥 Step 2 — Stop Comparing Yourself

If your code feels messy sometimes, congratulations — that means you’re a real developer, not a robot.

Comparison is the fastest way to trigger imposter syndrome.

You’re not supposed to be a clone of someone else.
God made you unique — with your own strengths, instincts, and perspective.

Your coworker might be amazing at CSS but terrible at database architecture.
You might be great at something they struggle with.

Everyone has strengths.
Everyone has blind spots.

“Why do you look at the speck of sawdust in your brother’s eye…?” — Matthew 7:1–5

Focus on what you bring.
Learn from others.
But don’t shrink yourself.

Yes, some people can blaze through Vim commands or memorize terminal flags.
You also have abilities they don't.

🔥 Step 3 — Learn the Senior Mindset (This Is the Real Cure)

Here’s what seniors understand that juniors don’t:

1. Being wrong is normal.

They expect it — and recover fast.

2. Progress > perfection.

Shipping matters more than polishing forever.

3. They break down problems.

Small chunks = clarity.
Overwhelm = insecurity.

4. They learn patterns, not syntax.

Frameworks change.
Patterns last.

5. They push through confusion.

Feeling lost means you’re learning something new.

🔥 Step 4 — Build “Deep Confidence” With Repetition

Confidence doesn’t come from motivation.
It comes from proof.

You need reps.

Try this for 7 days:

Pick one problem that scares you a little:

A feature you’ve avoided
A weird bug
A confusing part of the codebase
A small tool you’ve wanted to build

Finish it — even if the solution feels ugly.

Ugly solutions build confidence.
Polished tutorials don’t.

🔥 Step 5 — The Fastest Way to Feel Senior

Do this every day:

Explain what you learn out loud.

To:

yourself
ChatGPT
your notes
a rubber duck
a friend

Teaching forces clarity.
Clarity kills insecurity.

🔥 Step 6 — You Need a Leveling-Up Plan

1) Master the Fundamentals

Not frameworks. Not hype.

Learn:

Data structures
Algorithms basics
Async programming
Networking
HTTP + APIs
Databases
Architecture patterns

When your fundamentals are solid, you can learn any tool in days.

2) Build Real-World Projects

A senior has dealt with:

authentication
payments
file uploads
caching
migrations
error handling
performance
deployment
security basics

If you’ve only built a to-do app, you’re not ready.
Build things that force these skills.

3) Learn to Debug Like a Surgeon

This is the #1 senior skill.

Learn to:

isolate problems
reproduce bugs
simplify scope
trace data flow
read logs
follow stack traces
stop guessing

Seniors aren’t faster coders.
They’re faster debuggers.

4) Get Good at Reading Code

Most juniors only know how to write code.
Seniors can read messy codebases and understand them.

Practice by:

reading open source repos
reading production code
reading more than you write

🧠 Step 7 — Communicate Like a Professional (The Most Important Skill)

A true senior can:

Explain why a decision was made
Simplify complex ideas for anyone
Write clear summaries
Document reasoning, not just steps
Ask questions early
Push back respectfully when needed

Here’s the truth most developers don’t like hearing:

**Communication is more than half the job.

Realistically, it’s 80% communication, 20% code.**

Top earners aren’t the smartest developers —
they’re the ones with exceptional emotional intelligence.

They understand people.
They navigate conflict.
They make others better.

Most CTOs and CEOs don’t touch code anymore —
not because they can’t, but because their real value is in:

leadership
clarity
vision
decision-making

If you want to stay a pure coder forever, that’s totally fine.
Just know your income ceiling will stay lower.

Communication is what creates opportunity.
Talking to the right people at the right time can 10x your career.

🧩 Stop Comparing, Start Growing

Learn from others.
Help others.
Support your coworkers.
But don’t measure your worth by someone else’s strengths.

Zig Ziglar said it best:

“You can have everything in life you want if you will just help enough other people get what they want.”

Master that mindset and you’ll outrun anyone relying only on raw coding skill.

You Start Everything, Finish Nothing. Are you the kind of developer who starts ten side projects, only to abandon them when things get tough and jump to the next idea?

Samuel Ruiz — Wed, 12 Nov 2025 17:52:00 +0000

The Developer-Entrepreneur Curse: You Start Everything, Finish Nothing. Are you the kind of developer who starts ten side projects, only to abandon them when things get tough and jump to the next idea?

Samuel Ruiz — Wed, 12 Nov 2025 17:50:56 +0000

DEV Community: Samuel Ruiz

BENEFITS OF MODELING

What to Review Before Merging to `main`: A Practical Code Review Checklist

1. Unit Tests Exist (or There’s a Real Reason They Don’t)

2. Unit Tests Actually Assert Behavior

3. UI Matches the Design System

4. The Code Is Readable, Simple, and Intentional

5. It Works on Mobile and Touch Screens

6. Folder Structure and File Placement Are Correct

7. Storybook Exists (When It Should) and Covers All States

8. Performance Has Been Considered

9. ESLint and Prettier Are Clean

Final Rule Before Merging

Here's a checklist you can follow

🧪 Testing

🎨 UI / UX (If Applicable)

🧠 Code Quality

📁 Project Structure

📘 Storybook (If Applicable)

⚡ Performance

🧹 Tooling & Standards

🧾 Final Confirmation

Most React Code Is Hard to Read Because Developers Ignore This One Rule

1. Naming Functions

❌ Bad

✅ Good

2. Async Functions Must Signal Asynchrony

❌ Bad

✅ Good

3. React Components vs Utilities

❌ Bad

✅ Good

4. Event Handlers

❌ Bad

✅ Good

5. Boolean Variables

❌ Bad

✅ Good

6. State Setters (React)

❌ Bad

✅ Good

7. Files That Touch the Outside World

❌ Bad

✅ Good

8. Hooks

❌ Bad

✅ Better

Mental Model Summary

Common Third-Party GUI Integration Patterns

⚡ Quick Decision Guide

🧱 1. Iframe Embed

🔍 What it is

💻 Basic Example

🔐 Secure Sandbox Example

🔁 Parent ↔ Child Communication (postMessage)

✅ Pros

❌ Cons

🎯 Use when

📜 2. Script Tag / JavaScript SDK

🔍 What it is

💻 HTML Example

⚛️ React Wrapper Example

✅ Pros

❌ Cons (Real Risks)

🛡️ Required Safety Measures

🎯 Use when

📦 3. NPM Package / Component Library

🔍 What it is

📥 Install

⚛️ React Example

✅ Pros

❌ Cons

🧠 Best Practices

🎯 Use when

🧬 4. Micro-Frontend (MFE)

🔍 What it is

🏗️ Host Loader Example

🔌 Remote App Contract

✅ Pros

❌ Cons

🔁 Parent ↔ Child Communication (`postMessage`)