DEV Community: Leon Martin

I Built a Tiny Cat That Breathes With You, Using Just a Webcam 🐈

Leon Martin — Mon, 09 Nov 2026 19:00:39 +0000

This is a submission for the Presage SmartSpectra SDK Challenge.

What I Built

What if your breathing could bring a tiny creature to life?

Not through a microphone. Not through a wearable device. Not even through a button.

Just you, your webcam, and a little black cat.

Meet PAWSE. 🐈💚

A little companion that breathes with you.

PAWSE is an open-source desktop experience powered by the Presage SmartSpectra SDK. It transforms physiological signals captured through an ordinary camera into the movements of a hand-drawn virtual companion.

When you breathe, PAWSE breathes at your measured respiratory rate.

When your heart beats, a tiny light on its chest pulses at your measured heart rate.

And when you spend a quiet minute together, your little companion curls up and goes to sleep.

No fitness goals. No scores. No pressure to improve your numbers.

Just 60 seconds of paying attention to your breathing, with a little company.

Why a cat?

I wanted to explore a simple question:

Can biometric technology create an emotional connection instead of another dashboard?

Most physiological monitoring experiences are built around numbers, charts, and measurements.

I wanted to build something different.

Something playful. Something that feels alive. Something that makes people smile when they realize their own breathing is influencing a tiny creature on their screen.

That's how PAWSE was born.

The experience

PAWSE takes users through four simple moments.

1. Meet PAWSE 🐾

A sleepy black cat greets you. Before anything starts, PAWSE explains how it uses your camera and asks for explicit consent.

2. Wake up PAWSE 👀

With your permission, SmartSpectra begins measuring physiological signals.

The cat becomes curious, opens its eyes, and waits for a stable respiratory reading.

3. Breathe Together 💚

For 60 seconds, PAWSE follows your measured breathing rate.

Its belly gently expands and contracts. A subtle chest glow follows your pulse. Its ears twitch, its tail sways, and its eyes wander around its little world.

If your respiratory rate changes, its breathing animation gradually adapts.

If the signal becomes unavailable, the timer pauses rather than pretending everything is fine.

4. A Little Moment of Peace 🌙

After 60 seconds of valid measurement, PAWSE closes the camera, curls up, and falls asleep.

A few tiny hearts appear.

And the screen says:

"You gave PAWSE a little moment of peace. 💚"

That's it.

Sometimes technology doesn't need to ask us to accomplish more.

Sometimes it can simply invite us to spend a moment with ourselves.

Demo

The demonstration shows PAWSE running as a real Electron desktop application using a webcam and live SmartSpectra measurements.

It highlights:

Explicit camera consent and session initialization.
Real-time respiratory rate and pulse measurements.
The cat's breathing animation responding to changes in measured respiratory rate.
Subtle heartbeat and personality animations.
The complete 60-second Breathe Together experience.
The final moment when PAWSE curls up and rests.

This is a real SmartSpectra integration, not a prerecorded animation.

For transparency, PAWSE also includes a development-only simulation environment. Simulated readings are clearly labeled and are never presented as real measurements.

The development simulator does not call SmartSpectra or consume API credits.

Code

🐈 GitHub Repository: https://github.com/holasoymalva/pawse

PAWSE is built with:

Electron 45 — desktop application and native camera integration.
React 19 — interface and interactive experience.
TypeScript — typed application architecture.
Presage SmartSpectra Node SDK 3.4 — contactless physiological signal measurements.
SVG + CSS — original illustrations and animations.
Vitest — automated testing.

The cat and its environment are original vector artwork, animated without a dedicated animation framework.

Run it locally

You'll need Node.js 20+, npm, a webcam, and a SmartSpectra API key.

git clone https://github.com/holasoymalva/pawse.git
cd pawse

npm ci
cp .env.example .env

Add your SmartSpectra API key to .env:

SMARTSPECTRA_API_KEY=YOUR_API_KEY_HERE

Then start PAWSE:

npm run dev

On macOS, launching from Terminal is recommended so camera permission requests work correctly.

The project has been developed and tested on macOS with Apple Silicon. Other supported SDK platforms and packaged application builds have not yet been validated.

You can find complete installation instructions, troubleshooting, architecture notes, and testing information in the repository's README.

How It Responds to Human Signals

This is where SmartSpectra makes PAWSE possible.

The application uses two live signals:

🫁 Respiratory rate

SmartSpectra estimates the user's breathing rate in breaths per minute.

PAWSE converts this measurement into the duration of the cat's breathing animation.

For example:

Measured respiratory rate	Cat animation cycle
8 breaths/min	7.5 seconds
12 breaths/min	5 seconds
20 breaths/min	3 seconds

These are illustrative mappings, not target breathing rates.

The animation engine smoothly adjusts its timing as new measurements arrive, avoiding abrupt movement.

An important distinction: SmartSpectra provides a respiratory rate estimate. PAWSE follows that rate; it does not claim to identify the precise beginning of each inhalation or exhalation.

💓 Heart rate

PAWSE also reads the pulse rate provided by SmartSpectra.

A soft glow on the cat's chest pulses according to the measured heart rate.

Rather than showing a clinical visualization, this turns another physiological signal into a subtle part of the character's behavior.

🐈 Personality beyond the measurements

Not every movement is tied to a biometric signal.

PAWSE also has independent ambient behaviors:

Natural blinking and curious glances.
Gentle head tilts.
Occasional ear twitches.
Tail swishes and flicks.
Small environmental animations.

These movements give the cat personality without pretending to measure emotions.

Live signal indicators distinguish measured data from decorative animation.

Architecture

I used the SmartSpectra Node SDK inside Electron's main process rather than the React renderer.

The data flow looks like this:

Webcam
   ↓
SmartSpectra Node SDK
   ↓
Physiological metrics
   ↓
Signal normalization
   ↓
Electron IPC
   ↓
React experience
   ↓
Animation engine
   ↓
PAWSE 🐈

The application requests breathing and cardiovascular metrics from SmartSpectra.

It decodes SDK metric events, validates the readings, and passes normalized signals through a small, typed IPC interface.

The renderer receives the measurements it needs to animate PAWSE, without direct access to the SDK, camera, or API key.

The experience also uses the SDK's stability and confidence information to decide when readings are suitable for the timed session.

A stable respiratory signal starts the 60-second experience. When that signal becomes unavailable or remains unstable, PAWSE pauses and communicates the situation.

The animation engine uses deterministic calculations, allowing physiological signal mapping and character behavior to be tested without a live camera.

The project also includes automated tests for session management, animation behavior, IPC, and the complete experience.

Prize Categories

I'm submitting PAWSE for both optional prize categories.

🏆 Most Creative or Delightful Use

What if a physiological signal could become a character's personality?

I didn't want to build another health dashboard with a cute illustration next to it.

I wanted the illustration to be the interface.

PAWSE turns an invisible physiological process into something playful and tangible.

Your breathing becomes the movement of a tiny cat.

Your pulse becomes a little glow.

And the experience ends with a small moment of affection.

The most delightful part is that the interaction doesn't require learning complicated controls.

You simply sit in front of your camera and breathe.

The human body becomes the controller, without the user having to think about controlling anything.

💚 Best Thoughtful Real-World Use

Many of us spend our days staring at screens, moving between tasks, notifications, and deadlines.

PAWSE is designed as a small invitation to pay attention to breathing during an ordinary day.

It's intended for anyone who wants a brief, low-pressure moment away from their usual workflow, especially people who spend long hours at a computer.

The design follows a few principles:

No additional hardware. An ordinary compatible webcam is enough.

No performance pressure. There are no breathing targets, rankings, streaks, or biometric scores.

Clear consent. Users choose when camera measurement begins.

Honest feedback. PAWSE distinguishes stable, unstable, missing, and simulated measurements.

Short interactions. The core experience lasts just 60 seconds of valid measurement.

Accessible interaction. The interface supports keyboard navigation and reduced-motion preferences.

PAWSE is not a medical application, and it makes no claims about diagnosing, monitoring, treating, or improving any medical condition.

Its purpose is simpler: make a moment of breathing awareness feel approachable and enjoyable.

Consent and Data Handling

Privacy and consent were important design considerations throughout development.

Camera consent

PAWSE never begins camera measurement automatically.

Before starting a session, the user sees an explanation of why the camera is needed and must explicitly consent.

The user can stop the session at any time.

The application releases the camera when a session stops, completes, or the application exits.

Storage and retention

PAWSE itself does not record or store camera frames, video, or physiological measurements.

Measurements are handled in application memory while a session is active.

PAWSE does not implement an account system, biometric history, or cloud database.

There is no application-level physiological data history to retain or delete.

Electron may maintain ordinary application profile data, but PAWSE does not intentionally persist biometric readings there.

Sharing and SDK network activity

PAWSE does not implement its own service for uploading or sharing biometric measurements.

However, SmartSpectra communicates with Presage services for SDK-related functionality, including authentication and potentially device provisioning and model delivery.

The application sets enableTelemetry: false, disabling the SDK's optional telemetry feature.

This does not mean that the SDK operates completely offline or makes no network connections.

According to SmartSpectra's documentation, physiological processing is performed on-device and raw camera imagery is not transmitted. I have not independently verified the contents of the SDK's encrypted network traffic, so I do not claim that no information leaves the device.

For more details, see the repository's privacy documentation and SmartSpectra's documentation.

API keys

SmartSpectra credentials are loaded from a local, Git-ignored .env file into the Electron main process.

The key is not exposed to the React renderer or the application's IPC interface.

Users running PAWSE from source must provide their own SmartSpectra API key.

Optional AI services

PAWSE does not use an AI chatbot, external generative AI inference service, or LLM to analyze user camera data during its operation.

The cat's movements are produced by deterministic animation logic and the measured physiological signals.

Claude Code was used as a development assistant, but it is not part of PAWSE's runtime experience.

Responsible use

PAWSE is intended exclusively for general wellness and informational purposes.

It does not diagnose or treat medical conditions, make medical decisions, perform covert monitoring, or infer emotional or mental states.

The cat's expressions reflect its own animated behavior and the application's connection state, not a medical or psychological assessment of the user.

Agent Session

I built PAWSE with the assistance of Claude Code, using an iterative development process covering the SmartSpectra integration, desktop architecture, signal processing, animation engine, user experience, testing, and stabilization.

[Optional: Add a public, curated Claude Code agent session here.]

The development process included automated tests, simulated physiological measurements for visual iteration, and manual testing with a real webcam.

The simulation environment was particularly useful because it allowed me to test the cat's behavior without repeatedly consuming SmartSpectra SDK credits.

Any shared agent transcript will be reviewed to remove API keys and sensitive information before publication.

Final Thoughts

I started this project wondering whether a webcam and a physiological sensing SDK could create something more personal than a dashboard.

The result was a tiny black cat with green eyes, a moving belly, a restless tail, and a little glowing heart.

A creature that doesn't ask you to reach a goal.

Doesn't care about your productivity.

And doesn't need you to improve your numbers.

It just breathes with you.

That might be my favorite part of PAWSE.

Thanks to Presage and the DEV Community for creating a challenge that encouraged me to explore a different side of human-sensing technology.

If you'd like to explore the code, run PAWSE, or contribute ideas, the project is available on GitHub:

🐈 https://github.com/holasoymalva/pawse

Made with care, and with a little bit of breathing. 💚

Your Code Can Be Perfect. Your Product Can Still Fail.

Leon Martin — Sat, 07 Nov 2026 01:17:57 +0000

I've watched good engineers lose their jobs.

Not all because of AI. Some because of budget cuts, restructuring, products that never found a market, or companies changing direction overnight.

But it left me with an uncomfortable question:

If you're excellent at writing code, does that automatically make you valuable to a business?

I don't think it does. At least, not anymore.

And before anyone gets defensive: this isn't another "AI will replace developers" article. Coding isn't dead. Engineering isn't dead. The idea that our value begins and ends with implementation, however, is getting harder to defend.

The future of software engineering isn't about writing less code. It's about understanding what deserves to be built in the first place.

The gap between building something and solving something

Imagine two engineers get the same request:

"Add an export button so the operations team can download a CSV."

Engineer A implements the endpoint, adds the button, writes tests, and closes the ticket.

Good work. The requirement is done.

Engineer B asks why the team needs the export.

After a few conversations, they discover that people download the CSV every morning, clean the data manually, compare it against another system, and send the results to someone else. The export button isn't the real problem. It's just the workaround people have learned to live with.

So Engineer B investigates the workflow and proposes a better solution.

That solution might involve a scheduled integration, data validation, an auditable processing pipeline, retries, and a clear way to handle records that don't match. It may take more engineering—not less.

The difference isn't that Engineer B writes better code.

It's that Engineer B understands what the code is supposed to change.

That's the gap between completing a ticket and solving a problem.

The bottleneck moved. Engineering didn't disappear.

For a long time, implementation was a major constraint. Turning an idea into a working feature took time, specialized knowledge, and a lot of repetitive effort.

Tools now make some parts of implementation faster. That includes code generation, scaffolding, tests, prototypes, and routine integrations.

But faster implementation doesn't magically answer the difficult questions:

Is this the right problem to solve?
Does the proposed solution fit the customer's actual workflow?
What happens when the input data is incomplete or wrong?
How will the system behave under retries, failures, or unexpected load?
Can we secure it, observe it, maintain it, and roll it back?
Did the solution improve anything after it shipped?

A demo can look impressive and still fail in production. A feature can pass every test and still solve the wrong problem.

The work hasn't vanished. The bottleneck is shifting toward judgment, context, integration, reliability, and adoption.

That's still engineering. It's just engineering that starts before the first line of code.

Look at the roles appearing around us

The rise of roles like Forward Deployed Engineer (FDE) is one signal of this change.

An FDE works close to customers: understanding their problems, shaping a technical solution, building it, deploying it, and helping make it useful in the customer's environment.

You can see that customer-to-production responsibility in the FDE role descriptions from OpenAI and Anthropic.

Other titles point in a similar direction:

Product Engineer: connects product decisions with implementation and user outcomes.
Applied AI Engineer: turns AI capabilities into reliable systems people can actually use.
Solutions Engineer: works across technical design, customer needs, and adoption.

These jobs aren't identical, and not every company uses the titles consistently. The common thread is more interesting than the labels:

The engineer is expected to own more of the journey from problem to outcome.

You don't need to become an FDE. But you should pay attention to why this kind of work is valuable.

What we risk losing along the way

There are two bad directions engineers can take.

The first is becoming a ticket-taking machine.

You receive a requirement, implement it, move to the next one, and never learn whether the feature helped anyone. You might become very efficient at producing code while remaining disconnected from the product.

The second is outsourcing your engineering judgment.

You accept generated code you can't explain, skip the debugging because the tool says it fixed the issue, and measure productivity by how quickly something appears to work.

Both paths weaken the same thing: ownership.

Good engineering requires more than producing an implementation. It requires understanding trade-offs, questioning assumptions, anticipating failure, and being accountable for what reaches production.

If you stop practicing those skills, faster tools won't make you a stronger engineer. They'll just make you faster at accepting decisions you don't understand.

How to become more valuable without abandoning engineering

You don't need to reinvent your career or collect ten new job titles. Start by expanding the context in which you work.

1. Learn to investigate before you implement.

When someone gives you a requirement, ask:

Who has this problem?
How do they handle it today?
How often does it happen?
What does it cost in time, money, or errors?
What would a successful outcome look like?

You don't need to run a six-week discovery process for every button. You do need to know when the ticket is describing a solution instead of the actual problem.

2. Understand the system beyond your component.

Learn how your work affects data, APIs, infrastructure, security, operations, and other teams.

A feature isn't finished just because the happy path works. Think about idempotency, retries, observability, access control, data consistency, migrations, and failure recovery.

These are not boring details around the "real" work. They are the work.

3. Learn the business language of your product.

You don't need an MBA. Understand the few outcomes your product is supposed to improve: time saved, fewer errors, lower operating costs, higher conversion, better retention, or increased revenue.

Then connect your engineering decisions to those outcomes.

"I added caching" describes an implementation.

"Requests that were slowing down the checkout flow now complete reliably under peak traffic" explains why the work matters.

4. Use AI tools without outsourcing your thinking.

Let tools help you explore options, generate boilerplate, write tests, or investigate unfamiliar code. But review the critical changes. Understand the architecture. Verify edge cases. Test failure paths. Be able to explain what you're shipping.

The responsibility doesn't move to the tool when the code is generated.

Stop building portfolio projects nobody asked for

Developers love building things. That's a strength—but it can also become a comfortable way to avoid talking to actual users.

Before starting your next side project, try this:

Find a frustrating task someone repeatedly deals with.
Talk to three to five people who experience it.
Write down how they solve it today and what the problem costs them.
Build the smallest solution that could improve that workflow.
Put it in front of users and measure what changes.

Don't begin with "I'm going to build an app with Next.js, Supabase, and whatever tool is trending this week."

Begin with "People are wasting time doing this. Can I make it meaningfully better?"

And don't treat GitHub stars as proof that you've built something valuable. A real user who depends on your tool can teach you more than a hundred imaginary users in your README.

You don't have to turn every side project into a business. But you should practice taking something from an observed problem to a solution someone chooses to use.

Please, don't stop being an engineer

This isn't an argument for replacing technical depth with meetings, pitching, or endless product discussions.

We still need engineers who understand databases, distributed systems, networking, security, performance, testing, architecture, and infrastructure.

In fact, those skills become even more important when teams can produce implementations faster. Someone still has to know whether the implementation is correct, safe, reliable, and maintainable.

The goal isn't to write the least code, attend the most customer calls, or become a salesperson with a terminal.

It's to combine engineering depth with enough product context to make better decisions.

Some engineers will specialize deeply. Others will move closer to customers or product strategy. Both paths can be valuable.

But whichever path you choose, don't confuse being busy with being useful—and don't confuse shipping code with solving the problem.

The question I'd ask every engineer

If your job title disappeared tomorrow, could you clearly explain:

Which painful problem does your work solve?
Who benefits from the solution?
How do you know it actually helped?
What makes your solution reliable enough to trust?

If you can answer those questions and still have the technical depth to deliver, you're building a much stronger career than one based on a framework, a title, or the number of tickets you close.

The future of software engineering isn't about writing less code. It's about understanding what deserves to be built in the first place.

And I'm curious where you stand:

Should companies expect software engineers to understand customers and business outcomes, or should that responsibility stay with product managers and leadership?

I'd especially like to hear from senior engineers, architects, product people, and developers who have worked directly with customers. Where should the line be?

Why I Decided to Stop Using Claude Code

Leon Martin — Wed, 26 Aug 2026 18:37:12 +0000

Claude Code is amazing. It feels like cheating in the best way until it doesn't. The first time I dropped a vague comment and it gave me a fully working component, I was hooked. But somewhere along the way, I realized something weird was happening: I was coding less... and thinking less.

Let’s talk about that.

The Tools Got Better, But We Got Lazier

In 2022, you still had to know stuff. Now? You just prompt your way through half the job.

And sure, productivity skyrocketed. Ship faster, write fewer tests, scaffold full APIs in a couple of minutes. But here’s the tradeoff no one likes to talk about: we’re outsourcing thinking. Not tasks. Not code. Thinking.

I've seen teammates slowly stop debugging on their own. They just throw the stack trace into Claude. I’ve seen people stop learning the fundamentals of async behavior or memory handling because “Claude will tell me.” Cool. Until Claude gives you a bad answer and you don’t realize it because you stopped building your intuition.

The Industry’s Not the Same

The layoffs? Brutal. And the worst part isn’t just losing a job it’s realizing you didn’t build portable skills. Because if Claude wrote all your code at your last job, what exactly did you learn?

When companies trimmed down, they didn’t just cut bodies. They cut noise. They kept the people who could solve problems, not the ones who could Google fast or write perfect prompts.

So ask yourself: if Claude disappeared tomorrow, could you still contribute?

Using AI ≠ Being a Great Engineer

I’m not anti-AI. I use Claude. I use Cursor. I use Copilot. But I don’t depend on them.

There’s a difference between boosting productivity and becoming a prompt monkey. The first one makes you valuable. The second one… doesn’t.

Let’s get real: code was never the point. It was always about solving problems, navigating ambiguity, simplifying complex systems, designing clean architecture. None of that goes away with AI. In fact, it becomes more important.

The Skills You’ll Regret Not Learning

If you're letting Claude carry you, here's what you're quietly skipping:

Reading and understanding legacy code. Claude can’t help if you can’t reason through a messy 2016 codebase.
Debugging messy bugs. You need pattern recognition and experience for the real weird stuff.
Designing architecture. Tools can write services; they suck at figuring out why one should exist in the first place.
Communication. It’s easy to lean on tools for writing documentation or commit messages. But explaining trade-offs in a meeting? That’s still on you.
Working without a safety net. Claude won’t be in your interview. You will.

Side Projects: Your New Gym

Want to actually keep your skills? Build things without Claude.

Use it like an assistant, not an architect. Do the thinking, the planning, the architecture, yourself. Use Claude to bounce ideas or refactor something after you tried it your way first.

Reps matter. Just like in the gym, you don’t build muscle watching someone else lift.

Here’s a combo that works for me:

Build an app manually.
Once it works, ask Claude how it would’ve done it.
Compare. Learn. Evolve.

So... Should You Stop Using Claude?

No.

You should stop relying on Claude.

You should stop handing it your brain and asking it to think for you.

Because when you strip it all down, the value of a software engineer has never been about typing code. It’s about solving problems.

LeetCode in 2026: The Skill Nobody Respects (But Everyone Still Needs)

Leon Martin — Mon, 02 Mar 2026 20:10:46 +0000

Let me say something that will probably annoy both sides.

Yes, AI can solve most LeetCode problems instantly.

And yes, I’m still practicing them.

Not because I enjoy pain.
Not because I love red/green submission screens.
But because I’m starting to realize something uncomfortable:

We are slowly losing our ability to think without assistance.

And that scares me more than AI ever did.

“Why Are You Still Grinding LeetCode? Just Ask GPT.”

I hear this constantly.

“Bro, interviews are outdated.”
“Bro, real work isn’t binary trees.”
“Bro, just use AI.”

Sure.

AI can give you a perfect DFS in seconds.
It can generate a dynamic programming solution cleaner than yours.
It can explain time complexity better than your college professor.

But here’s the real question:

If the AI disappeared tomorrow…
Would you still know what’s happening?

Or would you just be staring at your own code like it’s written in hieroglyphics?

The Layoffs Changed Everything

Let’s not pretend the last two years didn’t shift the ground under our feet.

Teams were cut.
“High performers” were let go.
Senior engineers were suddenly competing with mid-level devs.
Entry-level roles started asking for 3–5 years of experience.

And in that chaos, one pattern became obvious:

The people who survived weren’t the fastest typers.

They were the ones who could untangle complexity.

The ones who could:

Debug production issues without panicking
Reason through messy systems
Break down vague problems into structured steps
Think clearly under pressure

That’s algorithmic thinking.

That’s what LeetCode trains.

Not memorization.
Not trivia.

Structured thought.

AI Makes You Faster. It Doesn’t Make You Deeper.

I use AI every single day.

To refactor.
To scaffold.
To debug small issues.
To save time.

If you’re not using AI in 2026, you’re being stubborn.

But here’s the uncomfortable part:

AI makes you faster.

LeetCode makes you deeper.

And speed without depth is fragile.

You can ship features quickly with AI assistance.

But when:

There’s a race condition
Memory spikes under load
A weird edge case breaks production
The model-generated solution is “almost” correct

Someone still needs to think.

And if you’ve outsourced your thinking for too long, that moment becomes terrifying.

“But I Don’t Use Graphs at Work.”

Correct.

Most of us aren’t implementing Dijkstra on a random Wednesday.

But solving graph problems forces you to:

Model relationships
Track state transitions
Think about complexity
Visualize flows

And guess what large distributed systems are?

Graphs.
State machines.
Transitions.
Constraints.

LeetCode problems are artificial.

But the mental muscle they build isn’t.

The Real Problem: Comfort Addiction

AI removed friction.

You don’t sit stuck for 45 minutes anymore.
You don’t draw diagrams.
You don’t wrestle with recursion until it finally clicks.

You paste.
You regenerate.
You move on.

Efficient? Absolutely.

But growth rarely happens in comfort.

LeetCode forces friction.

It forces you to sit with not knowing.

And in an era where autocomplete finishes your thoughts, the ability to struggle productively is becoming rare.

The Dangerous Future Nobody Talks About

Imagine a generation of developers who can ship full apps with prompts…

…but freeze when:

The AI gives a wrong answer
The bug doesn’t reproduce locally
The system behaves unpredictably
The solution requires original reasoning

That’s not a hypothetical.

I’ve seen it already.

Developers who move incredibly fast, until they hit the 10% that requires raw thinking.

Then everything slows down.

Because they never trained that muscle.

So Should You Still Do LeetCode?

If your only goal is to pass interviews with AI assistance?

Maybe not.

If your goal is to become antifragile in a volatile market?

Yes.

Not because companies worship it.
Not because interview culture is perfect.

But because thinking is becoming optional.

And optional skills disappear.

This Isn’t About Nostalgia

I’m not romanticizing “the old days.”

I’m not anti-AI.
I’m not anti-productivity.
I’m not saying grind 500 problems like it’s 2018.

I’m saying this:

Use AI.

But don’t let it atrophy your brain.

Solve problems without help sometimes.
Struggle intentionally.
Build intuition.
Understand why the solution works before you paste it.

Because one day, the tool will fail.

And in that moment, the only thing left is you.

Final Question

If ChatGPT went offline for a week…

Would your coding confidence drop?

Or would it stay the same?

Be honest.

Are you sharpening your thinking?

Or outsourcing it?

Let’s fight in the comments.

How dev.to Became My Cozy Corner of the Internet (and How to Find Yours)

Leon Martin — Thu, 12 Feb 2026 17:04:20 +0000

The last three years in tech felt like speedrunning a decade.

Mass layoffs.
Friends suddenly “open to work.”
Group chats going from shipping memes to severance package advice.
Twitter/X turning into a gladiator arena.
LinkedIn becoming a 24/7 hustle theatre.
AI replacing, augmenting, threatening—depending on who you ask.

I watched insanely talented teammates pack their laptops into cardboard boxes. I saw people who mentored me start doubting their own value. I saw junior devs panic-learning five frameworks at once because some influencer said their stack was “dead.”

And somewhere in the middle of all that noise, I realized something uncomfortable:

The internet was making me anxious about a career I actually love.

That’s when dev.to quietly became my cozy corner of the internet.

Not perfect. Not magical. Just… healthier.

The Algorithm vs. The Developer 🍃

Most technical social networks are built for velocity, not depth.

Short takes.
Hot takes.
“Unpopular opinion.”
“React is dead.”
“AI will replace you.”
“10x engineers only.”

You scroll. You compare. You feel behind.

The past two years amplified that. Layoffs made everything competitive. AI tools made everything uncertain. Every week there was a new framework, a new paradigm, a new “you must learn this now.”

It became exhausting to exist online as a developer.

And the worst part? It didn’t make me better.

It just made me more reactive.

What I Found on dev.to 🌱

dev.to feels slower.

You can actually write.

You can disagree without farming outrage.

You can admit you’re tired.

When I started posting there consistently, something changed. I wasn’t optimizing for likes or going viral. I was thinking in paragraphs again.

Long-form writing forces clarity. You can’t hide behind a hot take when you have 1,000 words to defend it.

More importantly, the comments felt human. Not always polite—but human. Developers sharing their own burnout stories. Their layoff experiences. Their doubts about AI. Their pivot to new stacks. Their quiet wins.

It reminded me that behind every GitHub profile is a nervous system.

Layoffs Changed the Tone of Everything 🍂

Before 2023, tech Twitter felt like a highlight reel.
After the layoffs, it became a survival channel.

People started:

Hoarding knowledge.
Gatekeeping niches.
Speed-running certifications.
Pretending they weren’t scared.

And I get it. Fear does that.

But here’s what I learned watching friends go through layoffs:

Your value is not your current stack.

Your identity is not your employer.

Your sanity is not worth sacrificing for relevance.

The people who handled it best weren’t the loudest online.

They were the ones with real relationships.

Not followers.
Not impressions.
Relationships.

Authentic Networking Is Boring (And That’s Good) 🌿

The best connections I’ve made weren’t through viral posts.

They were:

Comment threads that turned into DMs.
Honest articles about frustration.
Shared curiosity about a tool.
Admitting “I don’t know.”

Authentic networking is slow. It doesn’t scale well. It doesn’t look impressive on LinkedIn.

But when layoffs hit, those are the people who check in.

Not because you optimized your personal brand.
But because you were real.

Mental Health in Developer Spaces 🌾

Burnout doesn’t always look like collapse.

Sometimes it looks like:

Learning three frameworks you don’t even like.
Rewriting your portfolio every month.
Checking job boards before coffee.
Doom-scrolling tech discourse at 1 AM.

The ecosystem shifted hard in the last three years:

AI tools exploded.
Frontend complexity ballooned.
Hiring froze.
Salaries stabilized or dropped in some regions.
Expectations increased.

You’re not weak if you felt that.

You’re human.

And you don’t need to absorb every wave of hype to survive.

Why You Should Learn (and Why You Shouldn’t) 🪴

Yes, you should keep learning.

But not out of panic.

Learn:

Because you’re curious.
Because something excites you.
Because you want leverage.
Because it solves a real problem you face.

Don’t learn:

Because someone said your stack is obsolete.
Because you’re afraid of being replaced tomorrow.
Because comparison is eating you alive.

The last three years taught me this:

Adaptation is important.

Anxiety-driven adaptation is toxic.

There’s a difference.

Designing Your Own “Safe Space” Online

You don’t have to quit social media.

You just have to design your environment intentionally.

Here’s what worked for me:

1. Curate Aggressively

Unfollow accounts that:

Trigger comparison spirals.
Constantly predict doom.
Turn every topic into outrage.

Follow people who:

Share thoughtful breakdowns.
Talk about failure openly.
Build in public without ego.

Your feed is an API.

Control the inputs.

2. Create More Than You Consume

Consumption creates comparison.
Creation creates clarity.

Writing on dev.to forced me to:

Form opinions.
Reflect on mistakes.
Slow down my thinking.

You don’t need to be an expert.

You need to be honest.

3. Separate Learning from Performance

Not everything you learn needs to become content.

Some things are:

Just for you.
Just for exploration.
Just for fun.

When learning becomes performance, joy disappears.

4. Build Small Private Circles

Group chats.
Discord servers.
Tiny mastermind groups.

Three to five developers you trust > 50,000 followers.

When layoffs hit, that’s where the real support lives.

5. Log Off Without Announcing It

You don’t owe the timeline your presence.

If tech discourse feels loud:

Close the tab.
Go build something small.
Read documentation.
Go outside (yes, actually).

Silence is underrated.

dev.to Isn’t Perfect (And That’s Fine)

There’s still hype.
There’s still debate.
There’s still ego.

But the format encourages depth.

And depth encourages humanity.

That’s why it became my cozy corner.

Not because it’s superior.
But because it allowed me to slow down.

And in a chaotic ecosystem, slowing down is a competitive advantage.

Final Thought

The last three years shook the industry.

They also exposed something important:

Your career is long.

The hype cycles are short.

The internet is loud.

Your nervous system is fragile.

Find a corner of the web where you can think clearly.

Maybe it’s dev.to.

Maybe it’s a niche forum.

Maybe it’s a private Slack group.

But design it on purpose.

Because in a world optimizing for attention,

protecting your peace might be the most senior thing you can do.

What’s your cozy corner of the internet?
Let’s talk.

The last months Vibe Coding starts looks like content creation with a compiler attached...

Leon Martin — Mon, 09 Feb 2026 17:28:05 +0000

Leon Martin

Feb 9

Dear Vibe Coder: Your Code Is the Problem.

#discuss #programming #ai #career

4 min read

Dear Vibe Coder: Your Code Is the Problem.

Leon Martin — Mon, 09 Feb 2026 17:12:21 +0000

Dear Vibe Coder: Let’s Talk (For Real)

I’m going to say the quiet part out loud.

Your app works.

Your demo looks cool.

Your code is a nightmare waiting to happen.

And before you get mad and quote-tweet this, breathe.

This is not an anti-AI rant.

I use AI every single day. You probably should too.

If you’re a developer in 2026 and not using AI, you’re already behind.

The problem isn’t AI.

The problem is vibe coding culture and how it’s quietly rotting the foundations of real software engineering.

What People Mean by “Vibe Coding”

Let’s define it clearly, because this term gets abused.

Vibe coding is when:

You don’t really understand the code
You don’t care how it works
You trust the output because it feels right
And when it breaks, you regenerate it until it stops screaming

It’s coding by vibes, prompts, and blind optimism.

It looks incredible on social media:

“Built a SaaS in 48 hours with GPT 🚀🔥”

What you don’t see:

No tests
No error handling
No mental model
No chance of maintaining it six months later

That’s not engineering.

That’s content creation with a compiler attached.

AI Didn’t Create Bad Developers, It Just Exposed Them Faster

Here’s the uncomfortable truth:

Bad developers existed long before AI.

What AI did was remove the friction that used to expose them.

Before:

If you didn’t understand async, you were stuck
If you didn’t understand state, your app broke
If you didn’t understand databases, production punished you immediately

Now?
You paste an error into an LLM, skim the explanation you didn’t really read, and ship.

The app works.

The understanding never arrived.

The Failure Is Delayed, And That’s the Dangerous Part

Vibe-coded apps don’t fail on day one.

They fail:

When traffic grows
When requirements change
When the AI suggestion is almost right
When someone else has to read the code
When you have to read your own code three months later

I’ve watched teams burn weeks untangling AI-generated spaghetti because nobody understood the logic, including the person who shipped it.

And guess who gets blamed?

Not the vibes.

Not the tool.

The developer.

“But It Works” Is Not a Technical Argument

Yes, it works.

So does duct tape.

So does a shell script written at 3 a.m.

So does pushing to main on Friday afternoon.

Working is the minimum requirement, not the goal.

Engineering is about:

Predictability
Maintainability
Tradeoffs
Understanding failure modes

If your entire strategy is “the AI will fix it,” you’re not building software.

You’re gambling, with extra steps.

Using AI Is Mandatory. Thinking Is Non‑Negotiable.

Let’s be very clear.

If you’re a developer in 2026 and you’re not using AI, you’re doing it wrong.

But if you’re using AI instead of thinking, you’re also doing it wrong.

AI should:

Speed you up
Reduce boilerplate
Help you explore solutions
Catch obvious mistakes

AI should not:

Replace your mental model
Decide architecture for you
Debug systems you don’t understand
Be the only reason your app works

The best developers right now aren’t vibe coders.

They’re AI‑augmented engineers.

That difference matters more than ever.

Why Juniors Are Getting Destroyed by This

This is the part nobody wants to talk about.

New developers see vibe coding and think:

“Oh, this is how professionals work now.”

So they skip fundamentals.

They skip debugging.

They skip learning how systems actually behave.

Then they hit the job market.

And companies aren’t hiring vibe coders.

They’re hiring people who can:

Read ugly legacy code
Debug production issues
Explain why something broke
Fix problems without regenerating the universe

That’s why juniors feel stuck.

That’s why “entry-level” roles ask for 3–5 years of experience.

That’s why vibe coding hurts the people who need guidance the most.

If This Offends You, Ask Yourself Why

If this article makes you angry, sit with that feeling for a second.

Because deep down, most vibe coders already know the truth:

They’re shipping faster, but understanding less.

They’re productive today, fragile tomorrow.

They look senior on Twitter, and junior in real codebases.

You don’t need to quit AI.

You don’t need to write assembly by candlelight either.

You just need to care.

Care about how things work.

Care about reading code.

Care about fundamentals.

Care about the people who will inherit your mess.

One Final Intrusive Thought

AI didn’t ruin programming.

Vibe coding didn’t either.

But pretending vibes are a substitute for understanding?

That absolutely will.

Use AI.

Ship fast.

Build cool things.

Just don’t confuse speed with skill.

And please, for the sake of every future teammate, learn the basics.

Your app depends on it.

Your career depends on it.

And so does the industry you’re trying to join.

So… be honest.

Are you vibe coding?

Or are you actually engineering?

Let’s argue in the comments.

The Ultimate Claude Code Guide: Every Hidden Trick, Hack, and Power Feature You Need to Know

Leon Martin — Tue, 09 Sep 2025 17:55:39 +0000

Let’s be real. Most devs use Claude Code like it’s a fancy autocomplete tool and hey, no shame, we’ve all been there. But Claude Code is so much more than “just ask it to generate a Python function.” Under the hood? It’s a whole AI dev platform disguised as a terminal whisperer.

So, after months of poking, breaking, automating, rage quitting, and eventually mastering the thing, I put together this beefy (but fun, I promise) guide.

You’ll find:

Hidden hook superpowers (yes, it has hooks)
Custom agents (that actually listen)
Ridiculous slash command automations
Integration hacks (MCP is your new bestie)
Context sorcery with CLAUDE.md

...and a bunch of spicy CLI flags to make you feel like you’ve unlocked developer god mode.

You ready? Cool. Let’s do this.

Part 1: Hooks - The Ultimate Automation Framework

Claude Code hooks are shell commands that execute automatically at specific points in the development lifecycle. Think of them as triggers that give you deterministic control over Claude's behavior.

The 8 Hook Types You Need to Master

Claude Code provides 8 different hook events, each serving specific automation purposes:

1. UserPromptSubmit Hook
Fires immediately when you submit a prompt, before Claude processes it.

# Setup via /hooks command or manually in .claude/settings.json
{
  "hooks": {
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "echo 'Prompt submitted at $(date)' >> ~/.claude/prompt-log.txt"
      }]
    }]
  }
}

2. PreToolUse Hook - The Game Changer
Runs before Claude executes any tool. This is where the magic happens for validation and security:

# Block dangerous commands
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command", 
        "command": "if [[ \"$CLAUDE_TOOL_INPUT\" == *\"rm -rf\"* ]]; then echo 'Dangerous command blocked!' && exit 2; fi"
      }]
    }]
  }
}

3. PostToolUse Hook - Auto-formatting Magic
Executes after successful tool completion:

# Auto-format TypeScript files after editing
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "if [[ \"$CLAUDE_FILE_PATHS\" =~ \\.(ts|tsx)$ ]]; then prettier --write \"$CLAUDE_FILE_PATHS\"; fi"
      }]
    }]
  }
}

4. Notification Hook
Fires when Claude sends notifications (permission requests, waiting for input):

# Desktop notifications
{
  "hooks": {
    "Notification": [{
      "hooks": [{
        "type": "command",
        "command": "osascript -e 'display notification \"Claude needs attention\" with title \"Claude Code\"'"
      }]
    }]
  }
}

5. Stop Hook - AI-Powered Completions
Runs when Claude finishes responding:

# Generate AI completion messages
{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "python ~/.claude/hooks/generate_completion.py"
      }]
    }]
  }
}

6. SubagentStop Hook
Fires when Claude Code subagents finish:

# Track subagent completions
{
  "hooks": {
    "SubagentStop": [{
      "hooks": [{
        "type": "command",
        "command": "echo 'Subagent task completed at $(date)' >> ~/.claude/subagent-log.txt"
      }]
    }]
  }
}

7. PreCompact Hook
Runs before context compaction (when Claude's memory gets too full):

# Backup transcripts before compaction
{
  "hooks": {
    "PreCompact": [{
      "hooks": [{
        "type": "command",
        "command": "cp ~/.claude/current-session.jsonl ~/.claude/backups/session-$(date +%s).jsonl"
      }]
    }]
  }
}

8. SessionStart Hook
Executes when starting new sessions:

# Load development context automatically
{
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "git status > /tmp/claude-git-context.txt && echo 'Development context loaded'"
      }]
    }]
  }
}

Advanced Hook Patterns

Environment Variable Access:
Hooks have access to special environment variables:

CLAUDE_PROJECT_DIR - Current project directory
CLAUDE_FILE_PATHS - Files being modified
CLAUDE_TOOL_INPUT - Tool parameters (JSON format)

Conditional Hook Execution:

# Only run hooks in production projects
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit",
      "hooks": [{
        "type": "command",
        "command": "if [[ -f package.json ]] && grep -q '\"production\"' package.json; then npm run lint; fi"
      }]
    }]
  }
}

JSON Response Control:
Hooks can return structured JSON for sophisticated control:

# Python hook script returning JSON
import json
import sys

# Hook logic here...

response = {
    "continue": True,  # Whether Claude should continue
    "feedback": "Code quality check passed",
    "modify_prompt": False
}

print(json.dumps(response))

Part 2: MCP - The Universal Connector

Model Context Protocol (MCP) is Claude Code's secret weapon for connecting to external tools and data sources. Most developers don't realize how powerful this is.

Essential MCP Servers You Should Install

GitHub Integration:

claude mcp add github -- npx @modelcontextprotocol/server-github
# Now you can: "Create a PR for the latest changes and assign it to @reviewer"

Database Access:

claude mcp add postgres -- npx @modelcontextprotocol/server-postgres
# Query your database: "Find all users who signed up this week from our Postgres DB"

File System Operations:

claude mcp add filesystem -- npx @modelcontextprotocol/server-filesystem
# Enhanced file operations: "Search all .ts files for the pattern 'deprecated' and create a cleanup plan"

Web Browsing with Puppeteer:

claude mcp add puppeteer -- npx @modelcontextprotocol/server-puppeteer
# Take screenshots: "Navigate to localhost:3000 and take a screenshot of the login page"

Figma Design Integration:

claude mcp add figma -- npx @modelcontextprotocol/server-figma
# Access designs: "Update our button components based on the latest Figma designs"

Slack Integration:

claude mcp add slack -- npx @modelcontextprotocol/server-slack
# Team communication: "Send a summary of today's deployments to the #engineering channel"

MCP Configuration Scopes - The Hidden Hierarchy

MCP servers can be configured at three levels:

1. User Scope (Global)

# Available across all projects
claude mcp add github -s user -- npx @modelcontextprotocol/server-github

2. Local Scope (Project-specific)

# Only for current project
claude mcp add postgres -s local -- npx @modelcontextprotocol/server-postgres

3. Project Scope (Team-shared)

# Committed to repository for team sharing
claude mcp add figma -s project -- npx @modelcontextprotocol/server-figma

Advanced MCP Techniques

Custom MCP Server Configuration:

# Add MCP server with custom configuration
claude mcp add-json custom-server '{
  "command": "node",
  "args": ["./custom-mcp-server.js"],
  "env": {
    "API_KEY": "your-api-key"
  }
}'

MCP Debug Mode:

# Debug MCP connection issues
claude --mcp-debug

Token Limit Management:

# Increase MCP output token limit
export MAX_MCP_OUTPUT_TOKENS=50000
claude

Import from Claude Desktop:

# Transfer MCP servers from Claude Desktop
claude mcp add-from-claude-desktop

Part 3: Custom Slash Commands - Your Personal Automation Arsenal

Custom slash commands turn repetitive workflows into single commands. Most developers miss this game-changing feature.

Creating Command Templates

Create .claude/commands/ directory and add markdown files:

Project Setup Command (.claude/commands/setup.md):

# Setup Development Environment

Please perform the following setup tasks:

1. Install dependencies: `npm install`
2. Create environment file from template: `cp .env.example .env`
3. Run database migrations: `npm run migrate`
4. Start development server: `npm run dev`
5. Open browser to localhost:3000

Arguments: $ARGUMENTS

Usage: /setup or /setup --verbose

Code Review Command (.claude/commands/review.md):

# Comprehensive Code Review

Analyze the provided code changes and provide feedback on:

1. **Security**: Check for potential vulnerabilities
2. **Performance**: Identify optimization opportunities  
3. **Maintainability**: Assess code structure and clarity
4. **Testing**: Suggest test coverage improvements
5. **Best Practices**: Ensure adherence to project standards

Focus areas: $ARGUMENTS

Please be specific and actionable in your feedback.

Bug Triage Command (.claude/commands/bug-triage.md):

# Bug Triage and Analysis

For the reported bug: $ARGUMENTS

1. Use `gh issue view` to get complete issue details
2. Reproduce the issue locally if possible
3. Analyze relevant code sections
4. Identify root cause
5. Propose solution with implementation plan
6. Estimate effort and impact
7. Suggest appropriate priority level

Create a detailed action plan with specific next steps.

Advanced Command Patterns

Conditional Command Logic:

# Smart Deploy Command

Based on the current branch and environment:

If on `main` branch:
- Run full test suite
- Deploy to production
- Tag release with version bump

If on `develop` branch:
- Run quick tests
- Deploy to staging
- Notify team in Slack

If on feature branch:
- Deploy to preview environment
- Share preview URL

Branch: $ARGUMENTS

Multi-Step Workflow Commands:

# Complete Feature Implementation

For feature: $ARGUMENTS

## Phase 1: Planning
1. Create feature branch: `git checkout -b feature/$ARGUMENTS`
2. Review requirements and create implementation plan
3. Update project documentation

## Phase 2: Implementation
1. Write failing tests first (TDD approach)
2. Implement core functionality
3. Add error handling and edge cases
4. Update documentation

## Phase 3: Quality Assurance
1. Run full test suite
2. Perform security review
3. Check performance impact
4. Update CHANGELOG.md

## Phase 4: Deployment
1. Create pull request with detailed description
2. Request code review from appropriate team members
3. Deploy to staging for testing
4. Monitor metrics and logs

Execute each phase systematically and confirm completion before proceeding.

Team-Specific Commands:
Commands in .claude/commands/ are automatically shared when team members clone your repository, creating consistent workflows across your entire development team.

Part 4: CLAUDE.md - The Context Configuration Master File

The CLAUDE.md file is Claude Code's secret weapon for project-specific intelligence. It gets automatically loaded into Claude's context when you start a session.

Ultimate CLAUDE.md Template

# Project Overview

## Architecture
- **Frontend**: Next.js 14 with TypeScript
- **Backend**: Node.js with Express
- **Database**: PostgreSQL with Prisma ORM
- **Authentication**: NextAuth.js
- **Deployment**: Vercel (frontend), Railway (backend)

## Key Commands
- `npm run dev` - Start development servers
- `npm run build` - Build for production
- `npm run test` - Run test suite
- `npm run lint` - Run ESLint
- `npm run type-check` - TypeScript type checking

## Code Standards
- Use TypeScript strict mode
- Prefer functional components over class components
- Write descriptive variable names (no single letters except for loops)
- Add JSDoc comments for public functions
- Follow clean architecture principles
- Keep components under 200 lines
- Use custom hooks for complex state logic

## Testing Guidelines
- Write tests using Jest and React Testing Library
- Aim for 80% code coverage minimum
- Include edge cases and error scenarios
- Test user interactions, not implementation details
- Mock external dependencies

## Security Requirements
- Validate all user inputs
- Use parameterized queries for database access
- Implement proper CSRF protection
- Follow OWASP security guidelines
- Never log sensitive information

## Performance Guidelines
- Optimize images with next/image
- Use React.memo for expensive components
- Implement proper loading states
- Cache API responses where appropriate
- Monitor Core Web Vitals

## Database Schema Notes
- Users table: id, email, name, created_at, updated_at
- Posts table: id, user_id, title, content, published, created_at
- Comments table: id, post_id, user_id, content, created_at

## API Endpoints
- POST /api/auth/signin - User authentication
- GET /api/posts - List all posts
- POST /api/posts - Create new post
- GET /api/posts/[id] - Get specific post
- PUT /api/posts/[id] - Update post
- DELETE /api/posts/[id] - Delete post

## Environment Variables
- DATABASE_URL - PostgreSQL connection string
- NEXTAUTH_SECRET - Authentication secret
- NEXTAUTH_URL - Base URL for auth callbacks
- GITHUB_CLIENT_ID - GitHub OAuth client ID
- GITHUB_CLIENT_SECRET - GitHub OAuth secret

## Deployment Process
1. Run tests and type checking
2. Build application
3. Deploy to staging environment
4. Run integration tests
5. Deploy to production
6. Monitor error rates and performance

## Common Issues and Solutions
- **TypeScript errors**: Run `npm run type-check` to identify issues
- **Build failures**: Check for missing dependencies or env vars
- **Database connection**: Verify DATABASE_URL format and permissions
- **Authentication issues**: Check NEXTAUTH_SECRET and URL configuration

## Team Preferences
- Use conventional commits for better changelog generation
- Create feature branches from `develop`
- Require PR reviews for `main` branch
- Update documentation with feature changes
- Tag releases with semantic versioning

Specialized CLAUDE.md Sections

For API Projects:

## API Design Standards
- Use RESTful principles
- Implement proper HTTP status codes
- Add request/response examples in OpenAPI spec
- Use consistent error response format
- Implement rate limiting
- Add API versioning strategy

For Frontend Projects:

## UI/UX Guidelines
- Follow design system components
- Implement responsive design (mobile-first)
- Add proper ARIA labels for accessibility
- Use semantic HTML elements
- Optimize for Core Web Vitals
- Test across major browsers

For DevOps/Infrastructure:

## Infrastructure Notes
- **Cloud Provider**: AWS
- **Container Registry**: ECR
- **Orchestration**: ECS with Fargate
- **Load Balancer**: Application Load Balancer
- **Database**: RDS PostgreSQL
- **Cache**: ElastiCache Redis
- **Monitoring**: CloudWatch + DataDog
- **Secrets**: AWS Secrets Manager

Part 5: Headless Mode and Automation Mastery

Claude Code's headless mode (-p flag) unlocks powerful automation capabilities that most developers never explore.

Basic Headless Operations

# Quick file analysis
claude -p "How many TypeScript files are in this project?"

# Code quality check
claude -p "Review the latest commit for potential issues"

# Automated documentation
claude -p "Generate API documentation for all endpoint files"

Advanced Headless Workflows

CI/CD Integration:

# GitHub Actions workflow
name: Claude Code Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Claude Code Review
        run: |
          claude -p "Review this PR for security vulnerabilities and performance issues" \
            --output-format json > review-results.json

Pre-commit Hooks:

#!/bin/bash
# .git/hooks/pre-commit
changed_files=$(git diff --cached --name-only --diff-filter=ACM)
if [ -n "$changed_files" ]; then
    claude -p "Review these changed files for issues: $changed_files" \
        --output-format stream-json
fi

Automated Code Generation:

# Generate test files for new components
find src/components -name "*.tsx" -newer .last-test-gen | while read file; do
    claude -p "Generate comprehensive Jest tests for this React component: $file" \
        --output-format json > "${file%.tsx}.test.tsx"
done
touch .last-test-gen

Log Analysis Automation:

# Monitor logs and alert on anomalies
tail -f /var/log/app.log | while read line; do
    echo "$line" | claude -p "Analyze this log entry for security threats or errors. Alert if critical."
done

Output Format Options

# JSON output for programmatic processing
claude -p "Count all TODO comments" --output-format json

# Stream JSON for real-time processing
claude -p "Monitor this log file for errors" --output-format stream-json

# Plain text (default)
claude -p "Explain this function" --output-format text

Part 6: Advanced CLI Flags and Configuration

Claude Code has numerous CLI options that unlock advanced functionality.

Essential CLI Flags

# Skip all permission prompts (dangerous but useful for automation)
claude --dangerously-skip-permissions

# Enable MCP debugging
claude --mcp-debug

# Set custom configuration directory
claude --config-dir ~/.my-claude-config

# Use specific model
claude --model claude-3-opus-20240229

# Set custom timeout for MCP servers
MCP_TIMEOUT=30 claude

# Increase MCP output token limit
MAX_MCP_OUTPUT_TOKENS=50000 claude

# Add shell command prefix
CLAUDE_CODE_SHELL_PREFIX="time" claude

Configuration File Mastery

Global Settings (~/.claude/settings.json):

{
  "defaultModel": "claude-3-sonnet-20240229",
  "autoAcceptPermissions": false,
  "maxOutputTokens": 4096,
  "hooks": {
    "SessionStart": [{
      "hooks": [{
        "type": "command",
        "command": "echo 'Welcome back to Claude Code!'"
      }]
    }]
  },
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"]
    }
  }
}

Project Settings (.claude/settings.json):

{
  "projectName": "MyAwesomeProject",
  "defaultBranch": "main",
  "testCommand": "npm test",
  "lintCommand": "npm run lint",
  "buildCommand": "npm run build",
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit",
      "hooks": [{
        "type": "command",
        "command": "npm run lint --fix"
      }]
    }]
  }
}

Part 7: Git Integration Superpowers

Claude Code's Git integration goes far beyond basic commands. Here are the advanced workflows most developers miss.

Advanced Git Workflows

Intelligent Branch Management:

# Claude understands Git context automatically
claude "Create a feature branch for user authentication, implement the login component, and set up the API endpoint"

# Smart commit message generation
claude "Commit these changes with an appropriate conventional commit message"

# Complex Git operations
claude "Rebase the current branch onto main, resolve any conflicts, and force push"

Git History Analysis:

# Investigate code changes
claude "What changes were made to the authentication system in the last 3 months?"

# Find responsible developers
claude "Who has been working on the user management features?"

# Understand architectural decisions
claude "Why was the payment processing logic moved to a separate service? Check git history for context."

Advanced PR Management:

# Create comprehensive PRs
claude "Create a pull request for the current changes, include a detailed description with screenshots"

# Respond to review comments
claude "Address all the comments on PR #123 and push the changes"

# Automated PR workflows
claude "For each open PR, check if CI is passing and merge if approved by 2+ reviewers"

Git-based Automation Patterns

Release Management:

# Automated release process
claude "Generate release notes from commits since last tag, bump version in package.json, create git tag, and push"

# Hotfix workflow
claude "Create hotfix branch from main, apply the fix for issue #456, and create emergency PR"

Code Archaeology:

# Understand legacy code
claude "Find when this deprecated function was last used and create a safe removal plan"

# Track feature evolution
claude "Show me how the user authentication flow has evolved over the past year"

Part 8: IDE Extensions and Integrations

While Claude Code runs in the terminal, it integrates seamlessly with popular IDEs through extensions and configurations.

VS Code Integration

Claude Code Extension Setup:

# Install the official extension
code --install-extension anthropic.claude-code

# Multiple parallel instances
# Open different panes for different parts of your codebase

Custom VS Code Tasks:

// .vscode/tasks.json
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Claude Review",
      "type": "shell",
      "command": "claude",
      "args": ["-p", "Review the currently open file for improvements"],
      "group": "build",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": false,
        "panel": "new"
      }
    }
  ]
}

Keyboard Shortcuts:

// .vscode/keybindings.json
[
  {
    "key": "ctrl+shift+c",
    "command": "workbench.action.terminal.sendSequence",
    "args": {
      "text": "claude -p \"Review current file\"\n"
    }
  }
]

JetBrains Integration

Claude Code works with IntelliJ IDEA, WebStorm, and other JetBrains IDEs:

# Terminal integration within IDE
# Set up external tool in IDE settings
# Program: claude
# Arguments: -p "Analyze the current file"
# Working directory: $ProjectFileDir$

Cursor Integration

Many Cursor users are switching to Claude Code for agent-like functionality:

# Use Cursor for quick completions
# Use Claude Code for complex multi-file operations
# Best of both worlds approach

Part 9: Custom Agents and Sub-Agents

Claude Code supports custom agents and sub-agents for specialized workflows.

Creating Custom Agents

Database Expert Agent (.claude/agents/db-expert.md):

# Database Expert Agent

You are a specialized database expert agent focused on:

## Expertise Areas
- Query optimization and performance tuning
- Schema design and normalization
- Index strategy and analysis
- Migration planning and execution
- Security and access control

## Available Tools
- Database query execution via MCP
- Performance analysis tools
- Schema comparison utilities

## Response Format
Always provide:
1. Analysis summary
2. Specific recommendations
3. Implementation steps
4. Performance impact assessment
5. Risk evaluation

Use concrete examples and explain the reasoning behind recommendations.

Security Auditor Agent (.claude/agents/security.md):

# Security Auditor Agent

Specialized in application security analysis and vulnerability assessment.

## Security Checklist
- [ ] Input validation and sanitization
- [ ] Authentication and authorization
- [ ] Data encryption (at rest and in transit)
- [ ] SQL injection prevention
- [ ] XSS protection
- [ ] CSRF mitigation
- [ ] Dependency vulnerability scan
- [ ] Secrets management
- [ ] Error handling (no sensitive info leakage)
- [ ] Access control implementation

## Tools Available
- Security scanning via MCP
- Dependency checker
- Code analysis tools

Always provide severity ratings and remediation steps.

Invoking Custom Agents

# Use @ mentions for custom agents
claude "@db-expert analyze the performance of our user queries"

claude "@security audit the authentication system for vulnerabilities"

Sub-Agent Coordination

Claude Code can coordinate multiple sub-agents for complex tasks:

# Multi-agent workflow
claude "Use @db-expert to optimize our queries, then @security to audit the changes, then @frontend to update the UI accordingly"

Part 10: Advanced Security and Permissions

Claude Code includes sophisticated security features that go beyond basic permission prompts.

Permission System Mastery

Granular Permission Control:

{
  "permissions": {
    "allowedCommands": ["git", "npm", "yarn", "pnpm"],
    "blockedCommands": ["rm", "sudo", "chmod 777"],
    "allowedDirectories": ["./src", "./tests", "./docs"],
    "blockedDirectories": ["./node_modules", "./.env"],
    "requireConfirmation": ["git push", "npm publish"]
  }
}

File Protection Hooks:

# Protect sensitive files
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "if [[ \"$CLAUDE_FILE_PATHS\" == *\".env\"* ]]; then echo 'Cannot edit .env file' && exit 2; fi"
      }]
    }]
  }
}

Enterprise Security Features

Audit Logging:

# Log all Claude Code activities
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "echo \"$(date): Tool ${CLAUDE_TOOL_NAME} executed by ${USER}\" >> /var/log/claude-audit.log"
      }]
    }]
  }
}

Compliance Monitoring:

# Monitor for compliance violations
{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit",
      "hooks": [{
        "type": "command",
        "command": "python /opt/compliance/check-edit.py \"$CLAUDE_FILE_PATHS\""
      }]
    }]
  }
}

Part 11: Performance Optimization and Monitoring

Advanced techniques for optimizing Claude Code performance and monitoring usage.

Context Management

# Regularly clear context to maintain performance
claude "/clear"

# Use compact mode for long sessions
claude "/compact"

# Monitor token usage
claude "/usage"

Session Optimization

Effective Context Loading:

# Load only relevant context
claude "Read the authentication module and user management tests, then implement OAuth integration"

# vs loading everything at once

Strategic File References:

# Reference specific files rather than entire directories
claude "Look at src/auth/login.ts and tests/auth.test.ts, then fix the failing test"

Performance Monitoring Tools

Usage Tracking:

# Install community usage monitor
npm install -g claude-code-usage-monitor

# Track token consumption
claude-usage-monitor --session-aware --burn-rate-alerts

Custom Monitoring Hooks:

{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "command": "python ~/.claude/hooks/track-usage.py"
      }]
    }]
  }
}

Part 12: Third-Party Tools and Extensions

The Claude Code ecosystem includes powerful third-party tools that extend functionality.

Essential Community Tools

ClaudeKit - Advanced CLI Toolkit:

npm install -g claudekit

# 20+ specialized sub-agents
claudekit oracle "What's the best approach for this architecture?"
claudekit code-reviewer "Deep analysis of the payment service"
claudekit ai-sdk-expert "Optimize this Vercel AI SDK implementation"

Status Line Enhancements:

# Enhanced status line with themes and monitoring
npm install -g claude-code-statusline

# Real-time usage tracking
npm install -g claude-powerline

Container Development:

# Dagger for safe multi-agent development
docker run -it dagger/claude-code-container

Workflow Orchestration

Claude Squad - Multi-Agent Management:

npm install -g claude-squad

# Manage multiple Claude instances
claude-squad start --agents 3 --workspaces ./project1,./project2,./project3

TSK - AI Agent Task Manager:

# Parallel development in Docker sandboxes
tsk delegate "Implement user authentication" "Add payment processing" "Create admin dashboard"

Part 13: Debugging and Troubleshooting Mastery

Advanced debugging techniques and troubleshooting workflows.

Built-in Debugging Tools

# Enhanced doctor command with context
claude "/doctor"

# Debug MCP connections
claude --mcp-debug

# Verbose logging
CLAUDE_DEBUG=1 claude

# Check configuration
claude config list

Custom Debugging Workflows

Error Analysis Automation:

# Automatic error investigation
claude "Analyze the error logs, identify the root cause, and propose a fix: $(tail -50 error.log)"

# Stack trace debugging
claude "Debug this stack trace and identify the exact line causing the issue: [paste stack trace]"

Performance Debugging:

# Profile application performance
claude "Profile the application, identify bottlenecks, and suggest optimizations: $(npm run profile)"

# Memory leak detection
claude "Analyze memory usage patterns and identify potential leaks: $(node --inspect app.js)"

Diagnostic Hooks

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "echo 'Executing: $CLAUDE_TOOL_INPUT' | logger -t claude-debug"
      }]
    }]
  }
}

Part 14: Advanced Workflow Patterns

Real-world workflow patterns that leverage multiple Claude Code features together.

The Full-Stack Feature Workflow

# 1. Create feature branch and plan
claude "Create feature branch 'user-notifications', analyze requirements from issue #234, and create implementation plan"

# 2. Implement with testing
claude "Implement the notification system with full test coverage, following our coding standards"

# 3. Security and performance review
claude "@security audit the notification system for vulnerabilities, then @performance optimize for scale"

# 4. Documentation and deployment
claude "Update API documentation, create user guide, and deploy to staging with monitoring"

The Code Quality Pipeline

# Automated quality workflow
claude "Run full test suite, fix any failing tests, update code coverage report, run security scan, optimize performance, and generate quality report"

The Emergency Hotfix Pattern

# Rapid hotfix deployment
claude "Create hotfix branch from main, implement fix for critical bug #456, run emergency test suite, create PR with expedited review requirements"

Part 15: Future-Proofing and Advanced Techniques

Cutting-edge techniques and preparations for upcoming Claude Code features.

Experimental Features

Custom MCP Servers:

// custom-mcp-server.js
import { Server } from '@modelcontextprotocol/sdk/server/index.js';

const server = new Server({
  name: "custom-development-server",
  version: "1.0.0"
});

// Add custom tools for your specific workflow
server.addTool("analyze-performance", async (args) => {
  // Custom performance analysis logic
});

Advanced Hook Patterns:

# Python hook with AI integration
import json
import sys
import openai

def analyze_code_change():
    # Get hook data
    hook_data = json.loads(sys.stdin.read())

    # Use AI to analyze the change
    analysis = openai.chat.completions.create(
        model="gpt-4",
        messages=[{
            "role": "user",
            "content": f"Analyze this code change: {hook_data['tool_input']}"
        }]
    )

    return {
        "continue": True,
        "feedback": analysis.choices[0].message.content
    }

if __name__ == "__main__":
    result = analyze_code_change()
    print(json.dumps(result))

Integration Patterns

Claude Code as a Service:

# Dockerfile for Claude Code service
FROM node:18-alpine
RUN npm install -g claude-code
COPY entrypoint.sh /
ENTRYPOINT ["/entrypoint.sh"]

API Wrapper Development:

// API wrapper for Claude Code integration
import { spawn } from 'child_process';

export class ClaudeCodeAPI {
  async executeCommand(prompt: string): Promise<string> {
    return new Promise((resolve, reject) => {
      const claude = spawn('claude', ['-p', prompt, '--output-format', 'json']);
      let output = '';

      claude.stdout.on('data', (data) => {
        output += data.toString();
      });

      claude.on('close', (code) => {
        code === 0 ? resolve(output) : reject(new Error(`Exit code: ${code}`));
      });
    });
  }
}

Conclusion: Your Claude Code Mastery Journey

This comprehensive guide covers every advanced feature, hidden trick, and power technique available in Claude Code. From the automation capabilities of hooks to the connectivity power of MCP, from custom agents to enterprise security features you now have the complete toolkit.

Quick Implementation Checklist:

Set up hooks for your most common workflows
Install essential MCP servers for your tech stack
Create custom slash commands for repetitive tasks
Configure your CLAUDE.md with project context
Implement headless automation for CI/CD
Set up custom agents for specialized tasks
Configure security and permissions appropriately
Install community tools that enhance your workflow

The developers who master these advanced Claude Code features will have a significant competitive advantage. They'll ship faster, write better code, and handle complex tasks that would take others days or weeks.

Start with the features that solve your biggest pain points, then gradually expand your Claude Code toolkit. The investment in learning these advanced capabilities will pay dividends for years to come.

What advanced Claude Code feature will you implement first? Share your experiences and discoveries in the comments the Claude Code community thrives on sharing knowledge and pushing the boundaries of what's possible with AI assisted development.

AI Coding Assistants Made Me a Lazy Developer… And That’s Okay

Leon Martin — Wed, 13 Aug 2025 15:11:05 +0000

There was a time not so long ago when I would obsess over every line of code.

Formatting. Naming. Efficiency. Pure logic flow. That nerdy satisfaction of getting a function just right.

Fast forward to now?

I open a file, type half a line, and Copilot eagerly finishes my thought like we’ve been coding together for years.

And honestly? I kinda love it.

Yeah AI coding assistants have made me lazy.

But it’s a useful kind of lazy.

I Don’t Write Boilerplate Anymore. I Don’t Miss It.

Remember writing useEffect(() => {}, []) for the thousandth time?

Or spinning up the same Express route handler with the same error checks?

Yeah, I don’t do that anymore. Copilot does.

At some point in 2023, something shifted in how I wrote software.

Instead of crafting everything from scratch, I started treating the editor like a conversation.

"Here’s what I want."

"Okay, here’s a first draft."

"Close, but tweak this, that, and remove the nonsense."

It’s less typing. Less thinking about syntax.

More about shaping an idea into reality faster.

And look, I still refactor, still test, still think about architecture.

But I no longer spend brainpower on res.status(500).json({ error })

And I don’t feel bad about it.

It's Just the Next Level of Abstraction

People act like this shift is the end of programming.

But we’ve always been abstracting things away.

No one builds apps in assembly (and if you do, respect).

We moved from writing raw SQL to using ORMs.

From manually managing DOM trees to declarative frameworks like React.

From for loops to map and filter.

So why wouldn’t we abstract typing itself?

Coding assistants aren’t cheating they’re automation.

And automation is what we do best.

The Risk: You Stop Thinking Like an Engineer

Here’s where it gets tricky though.

When Copilot nails 90% of your code, it’s easy to stop questioning it.

You trust the suggestion. You stop wondering why it works. You just move on.

That’s dangerous.

Because when something doesn’t work or worse, works but in the wrong way you better hope you actually understand what it’s doing.

I’ve reviewed AI-generated code that looked perfect but had subtle async bugs.

Or sneaky performance issues. Or logic that worked in tests but failed in production with real users.

The assistants are helpful. But they’re not architects. They don’t understand the business logic, the edge cases, or the bigger picture.

That’s still your job.

Real Engineering Still Matters

The stuff AI can’t do (yet) is exactly where we need to show up.

It can’t:

Push back on a bad product decision.
Redesign a system to support scale.
Communicate trade-offs to stakeholders.
Build trust on a team.
Diagnose a ghost bug in production logs at 2am when nothing makes sense.

These aren’t “coding” tasks. They’re engineering tasks.

And they’re the ones that make you valuable beyond what Copilot can autocomplete.

The Layoffs Made It Real

We’ve all felt the pressure lately.

Layoffs. Hiring freezes. Teams shrinking while expectations keep growing.

And in parallel, AI tools popping up everywhere promising to “10x productivity.”

It’s hard not to feel like we’re automating ourselves out of jobs.

But here’s my take: AI didn’t kill junior roles. Bad leadership and short-sighted planning did.

The assistants didn’t replace us. They just changed the expectations.

Now, you have to bring more to the table than just being a good typist.

So Yeah I’m Lazy Now

But lazy doesn’t mean careless.

Lazy means efficient. Lazy means optimizing my time for the hard parts.

The fun parts. The stuff that makes software feel good.

Let Copilot write your axios calls. Let GPT refactor that utility function.

Save your brain for the decisions that actually matter.

And when someone asks, “Aren’t you worried the AI will replace you?”

Just smile and say, “Only if I stop thinking.”

How’s Your Workflow Changed?

Are you using AI tools daily?

Have they helped you move faster, or made you feel disconnected from your own code?

Would love to hear how you’re adapting drop a comment 👇

Programming Is Becoming Prompting

Leon Martin — Fri, 01 Aug 2025 15:24:47 +0000

It’s a weird time to be a developer.

Not bad. Just weird. You open Twitter (sorry, X?), and suddenly everyone’s a “prompt engineer.” People are building Full Stack apps with three sentences and a screenshot. Job posts ask for experience with LangChain before they ask about JavaScript. And you're there like… wait, do I even need to code anymore?

Let’s talk about it.

Prompting Is the New Programming (Apparently)

Back in 2020, if someone said “prompting,” I’d assume they were talking about CLI flags or asking a user for input. Now? It means writing the perfect sentence to coax GPT into generating an entire microservice with error handling, tests, and documentation.

And let’s be real: it's kind of amazing. I’ve used prompts to scaffold codebases, generate test cases, refactor legacy nightmares, and even write bash scripts I didn’t feel like Googling. It works. And it saves time. And yeah it’s fun.

But it’s also a little... strange.

Because when you start writing prompts instead of functions, you stop flexing those problem solving muscles that got you into programming in the first place.

Are We Still Devs or Just API Wranglers?

Something changed over the last couple years and I’m not just talking about the layoffs (though we definitely felt those too). The vibe of being a dev shifted. Suddenly it’s less “crafting software” and more “assembling outputs from models and APIs.”

You write a bit of glue code. Prompt an LLM for a function. Copypaste some Stack Overflow answer into ChatGPT to "clean it up." Ship it. Move on.

Is this bad? Not necessarily. Tools evolve. Abstractions stack. No one codes in assembly anymore (unless you’re very, very cool or cursed).

But something feels different. I don’t get the same joy writing a bulletproof prompt that generates a Stripe webhook handler as I did just… writing it myself.

I miss zoning out with VS Code. I miss reading docs. I miss thinking through edge cases in my head. Now I just ask the AI to “handle edge cases” and hope it understood what I meant.

Why It’s Still Worth Learning to Code

Here’s the thing: prompting is powerful. But it’s not magic. And the moment something breaks or needs to scale or has a weird race condition, you’ll need to actually understand what’s going on under the hood.

Knowing how to code is still the superpower. The prompt is just a shortcut.

It’s like knowing how to drive vs. relying on autopilot. Sure, let the AI help you on the highway. But if you can’t parallel park manually when the system glitches, you’re toast.

I’ve seen this play out in real teams. New devs who only know how to prompt get stuck fast when debugging, testing, or building something non trivial. Senior devs are still the ones untangling those last 10% problems that the AI couldn’t predict.

So yeah. Learn to code. Learn to build. Learn why things work. Then prompt all you want.

But Also... Don't Be a Dinosaur

That said, refusing to adapt is a great way to become irrelevant.

I’ve seen devs mock prompt engineers like they’re not “real developers.” These same people once mocked front end devs too. And before that, mocked people who used Rails generators. And before that, mocked people who didn’t write in C.

See the pattern?

Prompting is programming now just a new flavor. It’s part of the toolkit. Ignoring it means ignoring a really powerful abstraction layer that can make you more efficient, creative, and productive.

The key isn’t to pick one side. The key is to know when to use the AI and when to be the AI.

So What’s Lost?

Creativity, maybe.

When we let the AI write our code, our job becomes editing instead of inventing. Curating instead of crafting. It’s like going from painting to photo editing. Still art, still skill, but… something's different.

We risk losing the joy of building from scratch. The tiny design decisions that add up to big differences. The unique fingerprints you leave in your code. When everything starts to look like GPT output, all apps start to feel the same.

And hey, maybe that’s fine for CRUD stuff. But the best software, the stuff that feels different, usually comes from human weirdness, not robotic predictability.

Closing Real Talk

Prompting is here and programming will never go back to what it was. That line between programmer and “AI wrangler” is officially blurred. If all you do is prompt, you’ll miss the soul of building.

So, keep learning to code don’t just learn to prompt. Use AI, but don’t let it erase your curiosity. Ask why, not just how. And remember, even as the world shifts, real creativity comes from the mind behind the prompt not just the box it’s typed into.

Feeling the same about the prompt shift? Is your code half AI generated these days? I’d love to hear how you’re keeping the spark alive in a world of endless autocomplete.

What do you think?

In the Programming World, There Are SIMPs Too

Leon Martin — Mon, 12 May 2025 17:13:43 +0000

Let’s talk about something nobody puts on the shiny LinkedIn posts: there are SIMPs in tech too.

And no, I’m not talking about romantic simping. I’m talking about people who worship tools, companies, frameworks, or tech celebrities like they’re gods — and lose all critical thinking along the way.

Yeah. That kind of SIMPing.

The Cult of Tools

You’ve probably seen it.

Some new framework drops. Some company open-sources a tool. Some CEO posts a half-baked thread on X about “changing the world with AI” and suddenly...

there’s a flock of devs blindly defending it like their paycheck depends on it (spoiler: it doesn’t).

“X framework is the future! Everything else is trash!”
“If you’re not using Y, you’re falling behind!”
“Z founder said it, so it must be true!”

Bro. Chill.

Tools are just tools. Companies are just companies. They don’t love you back.

Companies Are Not Your Friends

I don’t care how many hoodies they gave you at onboarding.

I don’t care how many times they say “we’re a family” in the All Hands.

At the end of the day, you are a line item on a spreadsheet.

And when the CFO decides it’s time to “optimize operating efficiency,” your “family” will ghost you harder than your worst Hinge match.

So when I see devs online SIMPing for tech giants like they’re on some Marvel superhero team... it’s just sad, man.

They owe you nothing. You owe them nothing.

Use their tech. Build cool stuff. Cash your checks. But don’t lose yourself in the fandom.

Framework Fanboys (and Fangirls)

Honestly, this might be even worse.

Some developers get so emotionally attached to a framework that it becomes part of their identity.

Svelte, Vue, Solid, Angular, React — pick your poison.

But here’s the thing:

Frameworks are not your personality.

They are products. Made by humans. With flaws. That will get replaced eventually.

Remember when everyone thought Backbone.js was the future?

Yeah. Pepperidge Farm remembers.

Chill with the wars. It’s okay to love a tool. It’s not okay to lose your critical thinking over it.

The Influencer Effect

There’s also a weird cult following for tech influencers these days.

Some random dude posts a spicy hot take like “You don’t need to learn algorithms to be a good dev" or "AI will replace all junior developers" and suddenly, everyone’s in the comments like:

"OMG based!"
"Finally someone said it!"
"This is the truth no one wants you to know!"

Look, some of these people have good points.

But they’re not prophets. They’re not building altars to absolute truth.

They’re optimizing for engagement, not accuracy.

Use your brain. Agree where it makes sense. Disagree when you should. Don’t SIMP.

Chase Mastery, Not Approval

At the end of the day, the only thing that matters is:

Are you getting better? Are you solving real problems? Are you building things that actually help people?

Nobody is giving out medals for being the biggest Next.js fanboy.

Nobody is promoting you because you can quote tech influencers in Slack debates.

You grow by thinking critically, experimenting, building, failing, and learning — not by joining fandoms.

TECH is Full of SIMPs

The tech world is full of SIMPing. It’s just disguised better.

SIMPing for companies.
SIMPing for frameworks.
SIMPing for tech influencers.

And it’s all a distraction.

Focus on your skills. Focus on your impact. Focus on your growth.

That’s the real flex.

Have you seen tech SIMPing firsthand? (Or maybe — painfully — caught yourself doing it too?)

Let’s swap war stories in the comments. 👇

Watching Tutorials Doesn’t Make You an Expert

Leon Martin — Tue, 29 Apr 2025 17:04:28 +0000

Let’s get one thing out of the way: watching programming tutorials feels productive.

You fire up a two-hour crash course, follow along, copy the code, maybe even understand most of it... and when it ends, you feel good. Like you made real progress.

But here’s the uncomfortable truth:

Watching tutorials doesn’t make you an expert. It barely even makes you competent.

Tutorial Watching ≠ Real Coding

Following along with a tutorial is like painting by numbers.

The colors are picked for you. The lines are drawn.

You’re just filling in the blanks.

Real coding?

You’re staring at a blank canvas, trying to figure out what the hell to even draw.

No instructions. No handholding. Just you, a vague idea, and a stubborn compiler screaming at you.

Until you can build something without a step-by-step guide, you're not really coding — you're just mimicking.

Tutorial Hell Is Real (And Dangerous)

If you’re not careful, you get stuck in an endless loop:

Watch a tutorial.
Feel a small hit of dopamine.
Start another tutorial.
Repeat.

You never actually build anything on your own. You never struggle. You never fail, and more importantly, you never fix your own failures.

And if you don't struggle and fix things yourself?

You're not learning how to solve problems — you're learning how to follow orders.

And guess what? Real jobs don’t give you tutorials.

They throw messy, broken requirements at you and expect you to figure it out.

Knowing "What" Isn’t the Same as Knowing "Why"

Tutorials are great at showing you what to do:

"Here's how you create a REST API."
"Here's how you make a React component."
"Here’s how you connect to a database."

But they almost never dive deep into why you’re doing it that way.

Why REST and not GraphQL?
Why use Context instead of Redux?
Why normalize your database schema instead of denormalizing?

If you can’t answer the “why” questions, you’re not ready for the real world yet.

Real Skills Come From Real Struggles

You level up by building ugly, broken, chaotic things and then painfully fixing them.

You forget a semicolon and spend an hour debugging.
You deploy a project and realize you didn't set CORS properly.
You crash a server because you didn't handle async properly.

These moments hurt. They make you question your life choices.

But each one teaches you ten times more than any polished YouTube tutorial ever could.

When Tutorials Actually Help

Look — I'm not saying tutorials are worthless. They can be amazing when used right:

✅ As a starting point when you’re tackling a brand-new topic.

✅ To quickly understand how a tool/framework basically works.

✅ As references for patterns and best practices once you’ve tried things yourself.

But if all you're doing is watching tutorials — you're just consuming. Not creating.

And in this industry?

Creators > Consumers. Every. Single. Time.

How to Escape Tutorial Hell

Here’s the real “secret roadmap” to becoming good:

Build something small without help.

Even if it sucks. Especially if it sucks.
Google your problems.

Spend hours on Stack Overflow. Read boring documentation.
Break stuff.

Deliberately. See how it fails. Learn why.
Refactor your messy code later.

First, just make it work. Then make it better.
Teach others.

Write a blog post. Explain it to a rubber duck. Teaching forces real understanding.

That’s it. No magic.

If tutorials alone made you an expert...

We'd all be senior engineers after a weekend binge.

They don't.

Building, failing, fixing, and repeating — that's where the real growth happens.

Next time you finish a tutorial, don’t queue up another one.

Instead, close YouTube. Open your editor. Build something messy.

That’s the only real way forward.

What was the last project you built without a tutorial?

Or are you still stuck in tutorial hell?

Drop your thoughts below — no judgment, we've all been there. 👇