Part 2 of my series on Bash helpers I used during AI app development and system debugging.

Photo by Lukas on Unsplash

Read this first

• The provided scripts do not reflect the exact version I used before.

• I’ll add the complete versions on my repository soon: https://github.com/the-shy-dev/bash-snippets-gallery

• I would love to see how you would implement these ideas. Please share them with me.

• Part 1 here: https://blog.theshydev.com/5-bash-snippets-that-saved-my-dev-life-on-linux-devices

1. Smart Orphan & Resource Killer

While testing AI inference applications that spawn subprocesses, I often encountered zombie or orphaned processes due to bugs in my early code. I manually killed them at first — but it got old quickly. Eventually, I extended my helper script to also flag non-zombie processes that were hogging CPU or memory. Now, it prompts me before termination, unless I want to run it in dry-run mode or kill everything automatically.

What it does

• Detects and kills zombie processes automatically.

• Lists high-resource processes and prompts: do you want to kill them?

• Displays PID, CPU%, MEM%, and command line for clarity.

• Offers a --dry-run to simulate what would be killed.

#!/bin/bash
CPU_THRESHOLD=50
MEM_THRESHOLD=50
DRY_RUN=false
AUTO_KILL=false
print_usage() {
    echo "Usage: $0 [--cpu <percent>] [--mem <percent>] [--dry-run] [--auto]"
    exit 1
}
# Parse Arguments
while [[ $# -gt 0 ]]; do
    case "$1" in
        --cpu)
            CPU_THRESHOLD="$2"
            shift 2
            ;;
        --mem)
            MEM_THRESHOLD="$2"
            shift 2
            ;;
        --dry-run)
            DRY_RUN=true
            shift
            ;;
        --auto)
            AUTO_KILL=true
            shift
            ;;
        *)
            print_usage
            ;;
    esac
done
echo "[*] Scanning for zombie processes..."
ZOMBIES=$(ps -eo pid,stat,cmd | awk '$2 ~ /Z/ { print $1 }')
if [[ -n "$ZOMBIES" ]]; then
    echo "[!] Found zombie processes: $ZOMBIES"
    for PID in $ZOMBIES; do
        echo "[-] Killing zombie PID $PID"
        kill -9 "$PID"
    done
else
    echo "[+] No zombie processes found."
fi
echo ""
echo "[*] Checking for high CPU/RAM usage..."
ps -eo pid,comm,%cpu,%mem,cmd --sort=-%cpu | tail -n +2 | while read -r PID COMM CPU MEM CMD; do
    CPU_INT=${CPU%.*}
    MEM_INT=${MEM%.*}
    if (( CPU_INT >= CPU_THRESHOLD || MEM_INT >= MEM_THRESHOLD )); then
        echo "[$(date)] High usage detected: PID=$PID, CPU=$CPU%, MEM=$MEM%, CMD=$CMD"
        if $DRY_RUN; then
            echo "    >> DRY RUN: Would prompt or kill process $PID"
        elif $AUTO_KILL; then
            echo "    >> AUTO: Killing process $PID"
            kill -9 "$PID"
        else
            echo -n "    >> Kill process $PID? (y/N/q): "
            read -r REPLY
            if [[ "$REPLY" == "y" || "$REPLY" == "Y" ]]; then
                kill -9 "$PID"
                echo "    >> Process $PID killed."
            elif [[ "$REPLY" == "q" || "$REPLY" == "Q" ]]; then
                echo "    >> Exiting helper."
                break
            else
                echo "    >> Skipped."
            fi
        fi
    fi
done

2. Config Diff Tracker for AI Experiments

When experimenting with AI model behavior, we constantly tweaked a config.json that controls the application logic. After many changes, we forgot which combination led to success or failure. So I made this tracker that logs full config snapshots and diffs to keep track of iterations.

What it does

• Watches a target config file (default: config.json).

• When modified, saves a timestamped copy.

• Also creates a diff against the last saved version.

• User can control what to save using --mode full, diff, or both.

#!/bin/bash
TARGET_FILE="config.json"
SNAPSHOT_DIR="/opt/file_diff_snapshots"
MODE="both"
while [[ $# -gt 0 ]]; do
    case "$1" in
        --file)
            TARGET_FILE="$2"
            shift 2
            ;;
        --snapshot-dir)
            SNAPSHOT_DIR="$2"
            shift 2
            ;;
        --mode)
            MODE="$2"
            shift 2
            ;;
        *)
            echo "Usage: $0 [--file <path>] [--snapshot-dir <path>] [--mode full|diff|both]"
            exit 1
            ;;
    esac
done
mkdir -p "$SNAPSHOT_DIR"
BASENAME=$(basename "$TARGET_FILE")
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
LATEST_SNAPSHOT=$(ls -t "$SNAPSHOT_DIR"/*_"$BASENAME" 2>/dev/null | head -n 1)
NEW_SNAPSHOT="$SNAPSHOT_DIR/${TIMESTAMP}_$BASENAME"
cp "$TARGET_FILE" "$NEW_SNAPSHOT"
echo "[*] Saved snapshot: $NEW_SNAPSHOT"
if [[ "$MODE" == "diff" || "$MODE" == "both" ]] && [[ -n "$LATEST_SNAPSHOT" && "$LATEST_SNAPSHOT" != "$NEW_SNAPSHOT" ]]; then
    DIFF_FILE="$SNAPSHOT_DIR/${TIMESTAMP}_diff.patch"
    diff -u "$LATEST_SNAPSHOT" "$NEW_SNAPSHOT" > "$DIFF_FILE"
    echo "[*] Saved diff: $DIFF_FILE"
fi

3. Safe FFmpeg Recorder

Edge devices like Jetsons and Pi have limited disk space. While recording video feeds via USB or IP cameras, I needed a safeguard to stop ffmpeg before it filled the drive and crashed the system. This script handles it for me.

What it does

• Starts an ffmpeg recording session.

• Monitors available disk space.

• If either --min-mb or --min-pct is breached, it terminates recording gracefully.

#!/bin/bash
DEVICE="/dev/video0"
OUTPUT="recording_$(date +%Y%m%d_%H%M%S).mp4"
MIN_MB=500
MIN_PCT=10
while [[ $# -gt 0 ]]; do
    case "$1" in
        --input)
            DEVICE="$2"
            shift 2
            ;;
        --output)
            OUTPUT="$2"
            shift 2
            ;;
        --min-mb)
            MIN_MB="$2"
            shift 2
            ;;
        --min-pct)
            MIN_PCT="$2"
            shift 2
            ;;
        *)
            echo "Usage: $0 [--input /dev/videoX] [--output file.mp4] [--min-mb X] [--min-pct Y]"
            exit 1
            ;;
    esac
done
echo "[*] Starting ffmpeg recording..."
ffmpeg -f v4l2 -i "$DEVICE" -vcodec libx264 -preset ultrafast "$OUTPUT" &
PID=$!
while true; do
    AVAIL_MB=$(df --output=avail -m . | tail -1)
    TOTAL_MB=$(df --output=size -m . | tail -1)
    AVAIL_PCT=$((AVAIL_MB * 100 / TOTAL_MB))
    if (( AVAIL_MB < MIN_MB || AVAIL_PCT < MIN_PCT )); then
        echo "[!] Low space: $AVAIL_MB MB (${AVAIL_PCT}%). Stopping ffmpeg..."
        kill -INT "$PID"
        break
    fi
    sleep 5
done

4. Checksum Integrity Watchdog

I needed to ensure that post-deployment configs and binaries hadn’t been tampered with or accidentally modified. Especially when troubleshooting unexpected behavior. So this script became my watchdog.

What it does

• Supports a file or entire directory.

• --init: saves current checksums.

• --check: verifies once and reports diffs.

• --start: begins looped monitoring in background.

• --stop: halts the background watchdog.

#!/bin/bash
TARGET_PATH=""
MODE=""
CHECKSUM_FILE="/tmp/checksums.txt"
PID_FILE="/tmp/checksum_watchdog.pid"

print_usage() {
    echo "Usage: $0 <path> --init|--check|--start|--stop"
    exit 1
}
# Generate SHA256 checksums to stdout
generate_checksums() {
    if [ -d "$TARGET_PATH" ]; then
        find "$TARGET_PATH" -type f -exec sha256sum {} +
    elif [ -f "$TARGET_PATH" ]; then
        sha256sum "$TARGET_PATH"
    else
        echo "[!] Invalid path: $TARGET_PATH"
        exit 1
    fi
}
# Compare saved and current checksums
compare_checksums() {
    TMP_FILE=$(mktemp)
    generate_checksums > "$TMP_FILE"
    echo "[*] Checking for changes..."
    diff -u "$CHECKSUM_FILE" "$TMP_FILE"
    rm "$TMP_FILE"
}
# Monitor in a loop
watch_loop() {
    while true; do
        TMP_FILE=$(mktemp)
        generate_checksums > "$TMP_FILE"
        if ! diff -q "$CHECKSUM_FILE" "$TMP_FILE" > /dev/null; then
            echo "[!] Detected file changes at $(date)"
            diff -u "$CHECKSUM_FILE" "$TMP_FILE"
        fi
        rm "$TMP_FILE"
        sleep 10
    done
}
# Ensure at least two arguments (path + mode)
if [[ $# -lt 2 ]]; then
    print_usage
fi
# Parse arguments
while [[ $# -gt 0 ]]; do
    case "$1" in
        --init)
            MODE="init"; shift ;;
        --check)
            MODE="check"; shift ;;
        --start)
            MODE="start"; shift ;;
        --stop)
            MODE="stop"; shift ;;
        *)
            TARGET_PATH="$1"; shift ;;
    esac
done
# Execute mode
case "$MODE" in
    init)
        generate_checksums > "$CHECKSUM_FILE"
        echo "[+] Initial checksums saved to $CHECKSUM_FILE"
        ;;
    check)
        compare_checksums
        ;;
    start)
        echo "[*] Starting checksum monitor in background..."
        watch_loop &
        echo $! > "$PID_FILE"
        ;;
    stop)
        if [ -f "$PID_FILE" ]; then
            kill "$(cat "$PID_FILE")" && rm "$PID_FILE"
            echo "[+] Watchdog stopped."
        else
            echo "[!] No watchdog running."
        fi
        ;;
    *)
        print_usage
        ;;
esac

5. Offline Log Notifier with WebSocket Reporting

During offline debugging of embedded Linux devices, I wanted to know if critical log patterns like segfault, oom, or panic occurred—even without Internet. This script watches logs and ships matching alerts to a WebSocket endpoint once network resumes.

What it does

• Watches log file (dmesg or any path).

• Filters lines using a configurable regex.

• Sends alerts to a WebSocket server.

• Optionally runs in console-only mode (--local-mode).

#!/bin/bash
LOGFILE="/var/log/dmesg"
KEYWORDS="segfault|oom|panic"
ENDPOINT=""
LOCAL_ONLY=false
while [[ $# -gt 0 ]]; do
    case "$1" in
        --logfile)
            LOGFILE="$2"
            shift 2
            ;;
        --keywords)
            KEYWORDS="$2"
            shift 2
            ;;
        --endpoint)
            ENDPOINT="$2"
            shift 2
            ;;
        --local-mode)
            LOCAL_ONLY=true
            shift
            ;;
        *)
            echo "Usage: $0 [--logfile file] [--keywords regex] [--endpoint ws://...] [--local-mode]"
            exit 1
            ;;
    esac
done
echo "[*] Watching $LOGFILE for keywords: $KEYWORDS"
tail -Fn0 "$LOGFILE" | while read -r LINE; do
    if echo "$LINE" | grep -Ei "$KEYWORDS" > /dev/null; then
        echo "[!] Matched log: $LINE"
        if ! $LOCAL_ONLY && [[ -n "$ENDPOINT" ]]; then
            curl -s -X POST -H "Content-Type: application/json" -d "{\"message\": \"$LINE\"}" "$ENDPOINT"
        fi
    fi
done

Final Thoughts

These aren’t polished, one-size-fits-all tools. Most of them were born out of need and evolved over time. There might be more improvements or logical improvements I missed.

Do you have a Bash trick or script that saved your dev life? Drop it in the comments — I’d love to hear it from you!

#linux#bash#programming#shellscripting#tipsandtricks

Part 1 of a series on discovering the friction points in Apple’s polished ecosystem.

Photo by AB on Unsplash

When I unboxed my new MacBook Pro 14-inch with the M4 chip, I wasn’t exactly thrilled. Don’t get me wrong — I respect the hardware, the battery life, and the performance Apple Silicon offers. But something about macOS always made me feel… boxed in.

Unfortunately, it didn’t take long for that feeling to be validated.

The Setup That Works (on Windows)

My personal setup includes three external monitors, all connected via a USB-C hub with:

• 2x HDMI

• 1x DisplayPort

This setup works flawlessly on my Lenovo ThinkPad X1 Carbon:

3 external monitors ➝ USB-C Hub ➝ ThinkPad (Windows)

Each display functions independently — I can drag apps across screens, debug code while watching logs, and have media playing off to the side. Simple and effective.

The Same Setup on macOS? Disaster.

Device Info: MacBook Pro 14 inch, M4, Nov 2024.

When I plugged the same hub into my brand-new MacBook Pro M4, I was greeted with… three identical screens.

No extended displays. No flexibility. Just a single mirrored desktop copy-pasted across all three monitors.

As a sane person, I tried all possible things: checking system settings, browsing online, changing cables (weird choice but whatever)

And this isn’t a hardware issue. It’s a macOS limitation — by design.

Why This Happens: It’s Not Just You

macOS Doesn’t Support MST (Multi-Stream Transport)

MST allows chaining or splitting multiple displays through one port. It’s a core part of DisplayPort and USB-C video delivery.

• Windows and Linux support MST natively.

• macOS never has.

So even though your M4 MacBook Pro hardware technically supports it, the macOS software stack disables it entirely.

That’s why:

• Your USB-C hub mirrors displays.

• macOS can’t differentiate those signals as separate outputs.

If you booted into Linux or Windows (via external drive), it would likely work. TBD: I’ll find reference and add them here.

Apple’s Official Display Limits

From Apple’s official documentation:

“MacBook Pro (14-inch, M4) supports up to two external displays.” One via Thunderbolt + one via HDMI*.*

🔗 Apple Support — How many displays can it support?

You’ll never get three extended displays without a workaround.

Workarounds That Actually Work

1. DisplayLink Dock (With Caveats)

DisplayLink docks simulate multiple displays via software and USB. They bypass macOS’s native display system.

Pros:

• Adds more displays even on limited Macs

• Just one USB-C port needed

Cons:

• Not future-proof (macOS updates can break it)

• Performance issues (lag, screen tearing, limited refresh rates)

• No proper DRM support (Netflix, Apple TV might fail)

• Extra software layer always running in the background

2. Stick With Dual Displays (Officially Supported)

If you want no drama, use one or two displays as specified on Apple Support page. I chose this approach as I don’t want to spend money on an expensive ThunderBolt4 dock and here’s a reference to my setup: Reddit — r/macbookpro

You’ll get proper resolution, GPU acceleration, and fewer headaches — but you’re capped at 2 displays.

3. Use Sidecar / Universal Control

If you own an iPad, Sidecar adds an extra pseudo-display. It’s decent for reference apps, music, or notes — but not a full-fledged monitor replacement.

Some Curious Takes I Found

While researching all of this, I came across forum responses from other Mac users:

• “Why do people even need more than two monitors?”

• “Just close your MacBook lid and use dual screens.”

• “Windows uses too much CPU/GPU when handling multiple monitors — macOS is smarter.”

• “Apple must have a reason for not supporting MST. It’s probably better for battery life.”

• “You’re using the wrong hub. Just buy a proper Thunderbolt dock instead of blaming Apple.”

• “Too many screens just make people unproductive. This is a feature, not a limitation.”

• “Professionals use one screen and focus — that’s the Apple way.”

I get it. Everyone has different workflows, and some people genuinely don’t need more than one or two screens.

But I couldn’t help but feel a little surprised.

Not because people work differently — but because many seemed eager to rationalize limitations instead of recognizing them. Instead of asking Apple to do better, it felt like users were asking each other to settle for less.

It’s okay to love a product and still point out its flaws. That’s how platforms evolve. That’s how user needs are heard.

Final Thoughts

The M4 MacBook Pro is an advanced piece of hardware — battery life, performance, thermals. But I’m starting to feel Apple prioritizes elegance over flexibility — even if it hampers power users.

If you’re coming from Windows or Linux with a complex, multi-screen workflow — brace yourself. You’ll either need to downgrade your expectations or invest in fragile workarounds.

TL;DR

• macOS doesn’t support MST, so USB-C hubs with multiple outputs won’t extend your displays.

• M4 MacBook Pro supports only 2 external displays natively.

• DisplayLink docks work, but they’re fragile and add lag.

• macOS can’t control external display volume natively.

• HDMI-CEC features are incomplete on macOS.

• Some Mac users justify these limitations — but that doesn’t make them less frustrating.

Curious To Hear From You

If you’ve built a stable triple monitor setup on macOS — how did you do it? Do you feel Apple should prioritize power-user flexibility more?

Drop your experience in the comments

#MacBookPro#macOSLimitations#ExternalMonitor#DisplayLink#MST#M4

Image credits: Photo by Nick Morrison on Unsplash

“The best way to learn is to teach.”

I used to think that was just a feel-good quote. Now, I see it as a compass.

If you’re an engineer, enthusiast, or someone trying to break into tech, you’ve probably felt this: There’s no shortage of resources-but there’s a shortage of context.

That gap between knowing and doing is where I’ve spent most of my career. And that’s exactly the space I want to write about.

From Debugging Code to Designing Systems (and Everything in Between)

I began my journey in tech without knowing the local language, straight out of college, working in Japan. Since then, I’ve done backend engineering, developing for Linux and Android, tinkered with custom AI solutions, custom libraries, and worked with specialized hardware and edge devices.

I’ve led development on various stages, contributed to product roadmaps, and even dived into infrastructure setup-wearing multiple hats in startups and fast-moving teams. But here’s the truth: Each new role and responsibility taught me how much I still didn’t know.

That humbling realization is what keeps me learning-and now, writing.

Why I’m Writing

1. To Share Without Sugarcoating
   Most tech blogs filter out the rough edges. But the real learning often comes from the messy middle-things that didn’t go right, weird bugs that took days, or design choices that made sense… until they didn’t.

2. To Clarify My Thinking Through a Third-Person Lens
   Writing forces me to step outside myself and view my work, assumptions, and beliefs objectively. It often unlocks new patterns of thought I’d miss otherwise.

3. To Share My Failures So You Don’t Have To Repeat Them
   I’ve made architectural mistakes. I’ve overengineered solutions. I’ve chased shiny tech instead of solving the actual problem. If writing about these saves someone else a few hours-or a few months-it’s worth it.

4. To Learn From You
   This isn’t just about broadcasting ideas. I want to engage. Whether you’re an aspiring dev or a seasoned engineer with a different lens, I’d love to hear your takes.

What You Can Expect

This won’t be a niche-only blog. It will be as chaotic and random as my brain. In general, you’ll see posts on:

• How I’m integrating AI into traditional systems

• Lessons from building scalable backend systems with real-world constraints

• How Android development taught me the importance of resource constraints

• The curious bugs I find, and the elegant (or ugly) ways I solve them

• Reflections on leadership as someone who prefers building over managing

You’ll also see me explore new tech stacks and areas I’m diving into, like Rust, LLM pipelines, or hardware-software interfacing, and documenting what works, what doesn’t, and what’s exciting.

Why This Matters (To You)

If you’re:

• starting out and want to peek into the messy reality behind clean tutorials

• transitioning from one domain (say, Android) to another (like AI)

• trying to avoid common traps in system design, DevOps, or architecture

• other interesting things :D

I hope this blog feels like a conversation with a learner/peer/mentor based on how far you are. I’ll share not just the how, but also the why and the what I’d do differently if I had to start again.

Because sometimes, the best way to grow fast is to stand on someone else’s failure.

Let’s Learn Together

Writing isn’t something I’ve done regularly before. This is a new habit I’m building.
I can’t promise a fixed schedule (yet), but I can assure authenticity, curiosity, and relevance.

This is an open space: for learning, sharing, and growing together.
Whether you’re here to learn something new, challenge a view, or just lurk and reflect-I’m glad you’re here.

What’s one mistake you wish someone had warned you about early in your tech journey?

Drop it in the comments. Maybe we can turn it into a post-or at least a good conversation.

Until next time

From flaky USB cameras to Docker crashes — these quick scripts helped me survive the wild west of edge devices debugging

Photo by Lukas on Unsplash

When you’re in the trenches with Linux-based systems — working with USB/IP cameras, Dockerized apps— you end up writing a lot of ‘just-make-it-work’ Bash scripts.

Read this first

• The provided scripts do not show the exact version I used before.

• I’ll add the complete versions to my repository on a later date: https://github.com/the-shy-dev/bash-snippets-gallery

• To be honest, I would love to see how you would implement these ideas. Please share them with me.

1. USB Camera Sanity Test Script: Confidence in 30 Seconds

When I plugged in a USB camera, I needed three things immediately:

• Is the device detected?

• Can I preview and save frames?

• Can I log the camera’s capabilities for future debugging?

#!/bin/bash
DEVICE="/dev/video0"
FRAME_DIR="./camera_test_output"
INFO_LOG="$FRAME_DIR/camera_info.log"
mkdir -p "$FRAME_DIR"
echo "[*] Checking USB camera at $DEVICE..."
if v4l2-ctl --list-devices | grep -q "$DEVICE"; then
    echo "[+] Device detected."
    echo "[*] Logging camera capabilities..."
    v4l2-ctl --device="$DEVICE" --all > "$INFO_LOG"
    echo "[*] Previewing camera feed..."
    ffplay -f v4l2 -framerate 25 -video_size 640x480 -i "$DEVICE" &
    sleep 3
    echo "[*] Capturing sample frames..."
    for i in {1..3}; do
        ffmpeg -f v4l2 -video_size 640x480 -i "$DEVICE" -frames:v 1 "$FRAME_DIR/frame_$i.jpg" -loglevel quiet
        sleep 1
    done
    echo "[*] Listing available formats and resolutions..."
    v4l2-ctl --device="$DEVICE" --list-formats-ext >> "$INFO_LOG"
    echo "[+] Output saved in $FRAME_DIR"
else
    echo "[!] Device not found at $DEVICE. Is it plugged in?"
fi

Why it’s useful:

• Logs full camera capabilities.

• Captures sample frames.

• Provides live preview.

• Helps debug camera compatibility without launching a full app.

2. Process Resource Monitor with Basic Fault Handling

This script gives you a simple CSV of CPU, RAM, and network stats for any process you care about. The data could be further processed via a simple python script to represent visually.

#!/bin/bash
PROCESS_NAME=$1
LOGFILE="monitor_${PROCESS_NAME}.log"
NET_INTERFACE="eth0"
if [ -z "$PROCESS_NAME" ]; then
    echo "Usage: $0 <process_name>"
    exit 1
fi
echo "[*] Monitoring '$PROCESS_NAME' every 5 seconds"
echo "Timestamp,CPU(%),Memory(%),Net(TX_KB),Net(RX_KB),Status" > "$LOGFILE"
while true; do
    TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S)
    PID=$(pgrep -n "$PROCESS_NAME")
    if [ -n "$PID" ]; then
        CPU=$(ps -p "$PID" -o %cpu --no-headers | xargs)
        MEM=$(ps -p "$PID" -o %mem --no-headers | xargs)
        TX=$(cat /sys/class/net/$NET_INTERFACE/statistics/tx_bytes 2>/dev/null || echo 0)
        RX=$(cat /sys/class/net/$NET_INTERFACE/statistics/rx_bytes 2>/dev/null || echo 0)
        echo "$TIMESTAMP,$CPU,$MEM,$((TX/1024)),$((RX/1024)),OK" >> "$LOGFILE"
    else
        echo "$TIMESTAMP,0,0,0,0,NOT FOUND" >> "$LOGFILE"
    fi
    sleep 5
done

Why it’s useful:

• Logs everything to a CSV.

• Helps you understand essential performance metrics.

3. Intelligent Network Reconnection Script (Wi-Fi + Ethernet)

I’ve used this on everything from Jetsons to Raspberry Pi to edge Linux boxes. If Ethernet is used, it resets the interface. If Wi-Fi, it tries reconnecting intelligently.

#!/bin/bash
INTERFACE=$1
WIFI_SSID=$2
WIFI_PASS=$3
CHECK_INTERVAL=10
if [ -z "$INTERFACE" ]; then
    echo "Usage: $0 <interface> [wifi_ssid] [wifi_password]"
    exit 1
fi
is_wireless() {
    iw dev | grep -q "$INTERFACE"
}
reconnect_wifi() {
    if nmcli dev wifi | grep -q "$WIFI_SSID"; then
        echo "[$(date)] Attempting to reconnect to known Wi-Fi $WIFI_SSID..."
        nmcli dev wifi connect "$WIFI_SSID" password "$WIFI_PASS" iface "$INTERFACE"
    else
        echo "[$(date)] Wi-Fi SSID not found. Retrying later..."
    fi
}
restart_eth() {
    echo "[$(date)] Restarting Ethernet interface $INTERFACE..."
    sudo ip link set "$INTERFACE" down && sleep 2
    sudo ip link set "$INTERFACE" up
}
echo "[*] Monitoring network on $INTERFACE"
while true; do
    if ! ping -I "$INTERFACE" -c 1 8.8.8.8 > /dev/null 2>&1; then
        echo "[$(date)] Network unreachable on $INTERFACE"
        if is_wireless; then
            reconnect_wifi
        else
            restart_eth
        fi
    else
        echo "[$(date)] Network OK on $INTERFACE"
    fi
    sleep "$CHECK_INTERVAL"
done

Why it’s useful:

• Automatically recovers from lost connections.

• Handles both Wi-Fi and Ethernet with appropriate logic.

• Keeps headless devices online.

4. Docker Debug Collector (Auto-Zip Diagnostic Logs)

This one is a life-saver when your Docker app fails and you want to collect everything before restarting or reporting the bug.

#!/bin/bash
CONTAINER_NAME=$1
OUTPUT_DIR="docker_debug_$(date +%Y%m%d_%H%M%S)"
ZIP_FILE="$OUTPUT_DIR.zip"
if [ -z "$CONTAINER_NAME" ]; then
    echo "Usage: $0 <container_name>"
    exit 1
fi
mkdir -p "$OUTPUT_DIR"
echo "[*] Collecting Docker system info..."
docker images > "$OUTPUT_DIR/images.txt"
docker ps -a > "$OUTPUT_DIR/containers.txt"
echo "[*] Capturing logs for container: $CONTAINER_NAME"
docker inspect "$CONTAINER_NAME" > "$OUTPUT_DIR/${CONTAINER_NAME}_inspect.json"
docker logs "$CONTAINER_NAME" > "$OUTPUT_DIR/${CONTAINER_NAME}_logs.txt"
echo "[*] Copying mounted volumes (if any)..."
docker inspect --format '{{ range .Mounts }}{{ .Source }} -> {{ .Destination }}\n{{ end }}' "$CONTAINER_NAME" > "$OUTPUT_DIR/${CONTAINER_NAME}_mounts.txt"
echo "[*] Zipping all collected logs..."
zip -r "$ZIP_FILE" "$OUTPUT_DIR" > /dev/null
echo "[+] Debug data archived to $ZIP_FILE"

Why it’s useful:

• Grabs container logs, mounts, inspect data, and Docker status in one go.

• Great for creating bug reports or investigating crashes after-the-fact.

5. Real-Time File Watcher for Custom Actions (inotify)

Imagine a file drops in a folder, and you want to process or back it up immediately. This script listens for new files using inotifywait.

#!/bin/bash
WATCH_DIR="/home/user/input_dir"
ACTION_SCRIPT="./process_file.sh" # Assume this is another script that handles files
echo "[*] Watching $WATCH_DIR for new files..."
inotifywait -m -e create --format "%f" "$WATCH_DIR" | while read FILE
do
    echo "[$(date)] New file detected: $FILE"
    "$ACTION_SCRIPT" "$WATCH_DIR/$FILE"
done

Why it’s useful:

• No need for polling loops.

• Automates pipeline triggers as soon as data arrives.

• Very handy for camera footage processing or ETL-like setups.

Bonus: nohup – My Unsung Hero for Remote Scripting

Okay, this one’s not a script — but it ran all my scripts. When you’re working with edge devices — especially over SSH or in unstable environments — you quickly realize that losing your shell session mid-execution is a nightmare. That’s where nohup came to my rescue.

I used it constantly while running these very scripts on real devices in the field:

• The network reconnection script kept headless Jetson and Pi devices online, even when Wi-Fi dropped.

• The process monitor ran quietly in the background, logging performance of my Docker apps overnight.

• The file watcher script processed incoming camera footage while I focused on other tasks.

• or Any other installer scripts I prepared in the past that can run quite long.

Instead of setting up tmux or systemd immediately, I often used:

nohup ./network_watchdog.sh > watchdog.log 2>&1 &

This kept the script alive even after SSH disconnects, power hiccups, or accidental terminal closures — an absolute lifesaver when deploying to remote or industrial environments.

Pros:

• Doesn’t die with your terminal.

• Simple and fast to use for long-running scripts.

• Logs output to file for post-mortem debugging.

Cons:

• If you forget to redirect output, it writes to nohup.out in your working directory.

• It doesn’t survive reboots — consider systemd, supervisord, or cron @reboot if needed.

Bonus 2: Use logrotate to Keep Log Files Clean

An amazing helper command to keep things clean. Running long-term scripts with nohup means log files can grow fast. To avoid disk space issues, set up log rotation to clean files based on desired conditions.

Here’s a sample logrotate configuration file:

/home/nvidia/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 644 user user
}

This configuration:

• Rotates logs daily

• Keeps logs for the last 7 days

• Compresses older logs to save space

• Skips empty or missing files

• Creates new logs with correct permissions

Without logrotate, nohup logs can silently eat up your disk. With it, you get Reliable background scripts (nohup), Persistent logs without bloat (logrotate). I consider this as a low-effort, high-impact combo for any serious Linux development setup.

Final Thoughts

These scripts weren’t born in clean labs or tidy tutorials — they came out of panic, frustration, and real-world chaos: broken cameras, flaky Wi-Fi, silent crashes on remote machines, unstable applications.

If you’ve ever SSH’d into a device and whispered things like:

“Please work…”

“What’s happening!?”

“How do I know it’s still alive?”

…then you know exactly why scripts like these matter.

They helped me bring some sanity to systems that weren’t built to be predictable — and maybe they’ll help you too.

Do you have a Bash trick or script that saved your dev life? Drop it in the comments — I’d love to hear it from you!

Photo by Francisco De Legarreta C. on Unsplash

Read this first

• Mistakes are common everywhere. Don’t fret it too much. Never stop learning.

Here are 10 common (but fixable) mistakes developers make when building REST APIs-and what to do instead.

1. Using Verbs in Endpoints

REST is resource-oriented. The HTTP method already describes the action. If you are using verbs to define your endpoint, it will be redundant.

GET /createUser  
POST /deleteOrder

You can fix this by using nouns for endpoints and verbs only in HTTP methods.

POST /users        // create user  
DELETE /orders/:id // delete order

2. Ignoring Status Codes

This confuses clients that rely on status codes for logic (think: frontend, mobile apps, API consumers).

res.status(200).json({ error: "User not found" });

Utilize the status code based on their meaning. Return appropriate status codes-200, 201, 400, 404, 500... Don't make everything a 200.

res.status(404).json({ error: "User not found" });

3. Exposing Internal Errors Directly

From security point of view, it could leak some sensitive information or give clues to intruders.

res.status(500).json({ message: err.message }); // might expose stack traces or DB internals

Carefully review your implementation. Log errors internally if required.

res.status(500).json({ error: "Internal server error" });
myLogger.logError(err); // log the detailed error internally

4. Not Versioning Your API

Excluding version route in your endpoint can lead to potential future issues

GET /users
// How do you release breaking changes later?

A simple way to fix it would be include version info in your endpoint. Make this habit from day one.

GET /v1/users

Alternatively, you could use headers (Accept-Version).

5. Overloading 200 OK for Everything

This sounds familiar to an earlier mistake. Using 200 everytime might be syntactically OK but it gives a false confidence to clients.

res.status(200).json({ success: false, error: "Bad input" });

Be semantically correct as well. Don’t lie with 200.

res.status(400).json({ error: "Bad input" });

6. Inconsistent Naming and Pluralization

GET /user  
GET /orders  
POST /order

There’s no strict rule for it but assume plural noun to be the norm to make your life (and your future-self’s life) easier.

GET /users  
GET /orders  
POST /orders

7. Cramming Too Much Into One Endpoint

The most common reason for an endpoint to grow insanely huge-it’s convenient.

GET /users?includeOrders=true&includeComments=true&includeProfile=true

There are many ways to fix this. Let’s go with a basic idea of breaking down the endpoint by resources.

GET `/users/:id`
GET `/users/:id/orders`
GET `/users/:id/profile`

8. No Rate Limiting or Throttling

A classic but costly mistake. Anyone can hit your API a few thousand times a second and you won’t notice until the server dies. (The intention is not always with a DDoS intent… but it could be!)

Always rate-limit your APIs.

// Simple example with middleware
import rateLimit from 'express-rate-limit';
app.use(rateLimit({
  windowMs: 1 * 60 * 1000,
  max: 100,
}));

9. Trusting the Client a bit too much (Poor Input Validation)

Clients don’t always send what you expect-sometimes due to bugs, sometimes due to… creative users. This leads to garbage data, crashes, or worse-security issues.

app.post('/users', (req, res) => {
  const { email, age } = req.body; // assumes everything's fine
  // ...
});

Always validate your input. There are various libraries to make it easy for you — Zod, Yup, Joi, etc.

import { z } from 'zod';
const schema = z.object({
  email: z.string().email(),
  age: z.number().int().positive(),
});
app.post('/users', (req, res) => {
  const parsed = schema.safeParse(req.body);
  if (!parsed.success) return res.status(400).json({ error: parsed.error });
  // ...
});

10. Assuming Everyone Speaks JSON

Most APIs default to JSON responses-and that’s fine. But assuming it’s the only format clients ever need can be shortsighted.

res.send('Success'); // No content type set

Or:

res.json({ message: "Success" }); // even when the client asked for CSV or XML

• You don’t negotiate the correct Content-Type, so clients may misinterpret your response.

• Some clients (like CLI tools, legacy systems, BI tools) might expect other formats like CSV or XML.

• Debugging becomes painful when the frontend receives HTML error pages instead of structured JSON errors.

I think requesting something apart from JSON is a rare problem but let’s consider a possible fix.

Utilize Accept and Content-Type headers. Check and respect the Accept header sent by the client. Here's a TypeScript + Express example that supports both application/json and text/csv:

app.get('/reports', (req, res) => {
  const data = [
    { id: 1, name: "Hakuna" },
    { id: 2, name: "Matata" },
  ];
const accept = req.headers['accept'];
  if (accept?.includes('text/csv')) {
    const csv = data.map(row => `${row.id},${row.name}`).join('\n');
    res.setHeader('Content-Type', 'text/csv');
    return res.status(200).send(csv);
  }
  if (accept?.includes('application/json') || !accept) {
    res.setHeader('Content-Type', 'application/json');
    return res.status(200).json(data);
  }
  return res.status(406).send('Not Acceptable');
});

• Use the Accept header to determine what the client wants.

• Return a 406 Not Acceptable if the requested format isn't supported.

• Communicate data type on both sides with Content-Type header.

• Keep JSON as your default, but make future extensibility easy.

One Last Thing: Undocumented APIs Are Invisible

If no one knows how to use your API, it might as well not exist.

Use tools like OpenAPI, Swagger UI, or Redoc to generate and maintain clear, up-to-date docs automatically.

Final Thoughts

Designing a good REST API isn’t just about writing endpoints-it’s about building clear, predictable contracts between systems. These mistakes are common, but fixing them early can save you from weeks of work later.

Start simple. Make things explicit. Keep improving.

Have you stumbled on any of these? Drop a comment-I’d love to hear it.

What’s the sum of all integers from 1 to 100?

If you instantly said 5050, either you’re aware of Gauss Summation… Or you remembered it from the last time someone asked you.

Now imagine I ask you the same question again… Would you calculate it again or just reuse the answer?

What Is Caching?

Photo by Liam Briese on Unsplash

Caching is the practice of temporarily storing the result of expensive operations so you can serve future requests faster without doing the same work again.

In REST API development, this often means avoiding unnecessary database queries or redundant API calls.

Why Is Caching Important?

Imagine your /api/products endpoint hits the database every time someone visits your e-commerce homepage. If 10,000 users hit that in a minute, your DB is going to suffer. With caching, you store the result once and reuse it, saving time and resources.

Where Can You Apply Caching?

1. In-memory (e.g. node-cache, memory-cache)

2. Distributed (e.g. Redis, Memcached)

3. Browser-level (Cache-Control headers)

4. CDNs (Cloudflare, Akamai, etc.)

Let’s focus on in-memory and Redis for API development in this article. I can write posts on others if you want me to.

In-Memory Cache

import express from 'express';
import NodeCache from 'node-cache';
const app = express();
const cache = new NodeCache({ stdTTL: 60 }); // time to live in seconds. After that, cache expires.
app.get('/api/products', async (req, res) => {
  const cacheKey = 'products';
  const cachedData = cache.get(cacheKey);
  if (cachedData) {
    return res.json({ source: 'cache', data: cachedData });
  }
  const products = await fetchProductsFromDB(); // simulate DB query
  cache.set(cacheKey, products);
  res.json({ source: 'db', data: products });
});

Redis Cache

import express from 'express';
import Redis from 'ioredis';
const app = express();
const redis = new Redis();
app.get('/api/users', async (req, res) => {
  const cacheKey = 'users';
  const cached = await redis.get(cacheKey);
  if (cached) {
    return res.json({ source: 'redis', data: JSON.parse(cached) });
  }
  const users = await fetchUsersFromDB();
  await redis.set(cacheKey, JSON.stringify(users), 'EX', 120); // expires in 120 seconds
  res.json({ source: 'db', data: users });
});

When You Should (and Shouldn’t) Cache?

• ✅ Data doesn’t change often

• ✅ Reads > Writes

• ❌ Highly dynamic or user-specific data (e.g. shopping cart)

Cache Invalidation — The Hard Part

“There are only two hard things in computer science: cache invalidation and naming things. — Phil Karlton”

Cache invalidation is hard, but picking the right strategy makes it manageable. You’ll need a strategy to refresh or clear the cache when your underlying data changes.

I’ll make a detailed post on Caching and invalidation in the coming days. Here’s a summary for now.

A Classic Edge AI use case

Caching works beyond web and APIs

Before the medium-high powered Jetson devices era, the most common Edge AI use cases were on resource-constrained environments (Raspberry Pi, or embedded devices), where each CPU cycle is crucial for performance and energy efficiency.

Here’s a simple example in C++ that demonstrates caching inference results of a vision model (like object detection) for frames with little to no change, which is a common optimization.

Imagine you’re running a pressure gauge detection model on a camera feed. If two consecutive frames are nearly identical, you can skip re-running inference and reuse the previous result — that’s caching at the edge.

We’ll cache the last processed frame’s hash and its detection result.
If the new frame is “similar enough”, we’ll skip the model inference and reuse the result. On the edge, skipping AI inference even for a few frames saves CPU/GPU, battery, and latency.

// frame_handler.cpp
#include <opencv2/opencv.hpp>
#include <unordered_map>
#include <string>
cv::Mat last_frame;
std::string last_result;
int frame_threshold = 10; // pixel-wise threshold for frame difference
// Simulate an expensive model inference
std::string runInference(const cv::Mat& frame) {
    // Pretend this runs a heavy AI model
    return "Normal readings detected\n";
}
// Compare two frames for similarity
bool isSimilar(const cv::Mat& a, const cv::Mat& b, int threshold) {
    if (a.empty() || b.empty()) return false;
    cv::Mat diff;
    cv::absdiff(a, b, diff);
    return (cv::countNonZero(diff > threshold) < 1000); // heuristic
}
std::string processFrame(const cv::Mat& frame) {
    if (isSimilar(frame, last_frame, frame_threshold)) {
        std::cout << "Cache hit: Reusing previous result\n";
        return last_result;
    }
    std::cout << "Cache miss: Running inference\n";
    last_result = runInference(frame);
    last_frame = frame.clone();
    return last_result;
}

// In action - main.cpp
int main() {
    cv::VideoCapture cap(0); // camera input
    while (true) {
        cv::Mat frame;
        cap >> frame;

        if (frame.empty()) break;

        std::string result = processFrame(frame);
        std::cout << "Result: " << result << "\n";

        cv::imshow("Edge AI Frame", frame);
        if (cv::waitKey(30) >= 0) break;
    }
    return 0;
}

You use Caching every day

Caching is everywhere. We rely on it daily without realizing it:

• Mobile Apps: Ever noticed how apps like Instagram, YouTube, or Twitter load faster the second time you open them? That’s local caching at work — images, videos, and layouts are stored temporarily so the app doesn’t have to download everything again.

• Web Browsing: When you revisit a website, it often loads faster. That’s because your browser caches static assets like CSS, JavaScript, and images. No need to re-download the entire site on every visit.

• Your Brain (Seriously!): Remember the answer to “What’s the sum of 1 to 100?” from earlier? If you don’t recalculate it and instead recall it — that’s mental caching. Passwords, Frequently used routes, Common answers in conversations, etc. are also your cached responses.

• Cooking: Let’s say you prepare a big batch of curry and refrigerate it. You don’t cook it from scratch every day — you reheat it. In a sense, that’s caching in the kitchen.

Caching is a universal principle of optimizing effort, whether it’s computers, phones, or your own brain.

Final Thoughts

Whether you’re building REST APIs, edge AI systems, or microservices — caching is one of those tools that offers massive returns for minimal effort when used right.

From in-memory and Redis caching to frame-level optimization in computer vision, the underlying idea is the same:
Don’t do expensive work more than once if you can avoid it.

If you’re just getting started, pick one high-traffic endpoint or heavy computation, add caching, and measure the impact. You’ll be surprised how much faster and leaner your system feels.

Have you implemented caching in your systems?

• What strategies worked best for your use case?

• Have you ever struggled with stale data or cache invalidation?

• Any fun edge caching hacks you’ve tried?

Drop your thoughts, war stories, or questions in the comments — let’s share notes and level up together.

Photo by RealToughCandy.com: https://www.pexels.com/photo/programmer-holding-a-paper-cutout-with-an-api-quote-11035364/

“The integration worked in staging, but blew up in production.”

“The client relied on a field we never intended to expose.”

“We added a small change and broke three downstream systems.”

The above cases can be quite common when you’re primary work involves a lot of API development. In real-world engineering, how you understand API requirements is just as important as what the requirements say.

I intend to break down the evolution of API understanding through three lenses — Junior, Senior, and Tech Lead — based on how I’ve seen and experienced these roles.

Read this before going further

• Titles don’t have a real value unless the associated responsibilities are truly realized. The post is not intended to talk about individual’s performance.

• Code snippets written here are not tested. They are just there to explain a point visually.

• I’m not explaining the most common problems at each level and fixes. The main idea is to share my interpretation of these roles.

What Do “API Requirements” Actually Mean?

For many, API requirements = endpoint + method + payload + response. That’s the bare minimum. In practice, it includes:

• Functional constraints: What the API must do.

• Contextual expectations: Why it exists, who uses it, where it fits in the system.

• Systemic qualities: Performance, rate limits, error semantics, observability.

• Temporality: What breaks if we change it? Is it versioned? Is it backward-compatible?

API endpoints can be assumed like contracts for communication.

Junior Engineer: Fulfilling the Contract

At this stage, you’re mostly writing code as instructed or requested — follow the provided Jira ticket or relevant extract from a big spec document.

Typical focus areas:

• HTTP verb and route structure

• Payload fields and response types

• Return correct status codes

• Implement/update the unit tests

Where things go wrong:

• Incomplete requirements from your source

• Misunderstand optional vs. required fields

• Don’t consider how the API is used downstream (e.g. other systems, third-party clients)

• Assume “happy path” is sufficient

How I tried to improve

A simple question and a perspective shift helped me improve my solution capability to implement a better solution.

What assumptions were made for this task? (or spec?) and reading the API spec like a consumer, not just a coder

Senior Engineer: Seeing Beyond the Contract

Now you’re thinking about how this API behaves in production, not just if it works.

Your questions evolve:

• How do we handle edge cases (e.g. deleted users, archived states)?

• Is this exposing sensitive or inconsistent data?

• How does this interact with pagination, search, localization?

• Should we debounce calls or cache on client/server?

A problem scenario:
Here’s something that illustrates a common real-world problem with leaking internal fields in an API response. You once exposed a GET /users/:id that returned full user objects.

// user.model.ts (Prisma ORM model or internal DB schema)
export const user = await prisma.user.findUnique({ where: { id } });
res.json(user); // Assume this exposes everything, including sensitive/internal fields like isAdmin, lastLoginIp.

Fields like isAdmin, lastLoginIp are unintentionally exposed. If another team starts depending on them, changing those fields later becomes a breaking change.

A common fix to it is using DTOs and field-level control.

// dto/PublicUserDTO.ts
import { Exclude, Expose } from "class-transformer";

export class PublicUserDTO {
  @Expose()
  id: string;
  @Expose()
  name: string;
  @Expose()
  avatarUrl: string;
  @Expose()
  joinedAt: Date;
  @Exclude()
  isAdmin: boolean;
  @Exclude()
  lastLoginIp: string;
  constructor(partial: Partial<PublicUserDTO>) {
    Object.assign(this, partial);
  }
}

// ---------------------------------------------------------
// user.controller.ts
import { plainToInstance } from "class-transformer";

app.get("/users/:id", async (req, res) => {
  const user = await prisma.user.findUnique({ where: { id: req.params.id } });
  if (!user) return res.status(404).json({ message: "User not found" });
  const publicUser = plainToInstance(PublicUserDTO, user, {
    excludeExtraneousValues: true,
  });
  res.json(publicUser); // Only exposes whitelisted fields
});

• This keeps your public API contract stable, even as your internal models evolve.

• Adding/removing fields becomes a controlled change, not a surprise.

Never forget that if it’s in the API, someone will depend on it. Consider minimal responses from the early stages. Expand as required after careful data-driven decisions

Tech Lead: Designing for Time, Teams, and Trade-offs

At this level, you’re no longer just shipping endpoints; you’re shaping how systems communicate, evolve, and scale across teams.

Your focus shifts:

• Will adding a required query param break downstream consumers?

• Does this align with the REST patterns used across other teams?

• What happens if a dependent service goes down mid-request?

• Can we detect and respond to API degradation before users feel it?

• Are we truly seeing the consumer perspective?

Often, the most important API requirements are the ones not written down:

• What are clients assuming implicitly?

• Is this endpoint used synchronously or in batch mode?

• Is this API part of a contract with an external partner?

• Will this be consumed by mobile apps (with bad network)?

You learn to ask better questions:

• “Why does this need to be real-time?”

• “What happens if the field is missing?”

• “Who else might be affected if we change this?”

• “How frequently will the user call this?”

You’re no longer just writing code-you’re designing long-term contracts. And often, the hardest work is navigating ambiguity, aligning cross-team needs, and making intentional trade-offs.

A problem scenario:
You’re building a User Profile API used by internal HR tools, customer-facing dashboards, and reporting systems. Each use case needs different slices of data, and some rely on slow or failure-prone downstream services.

Do you build one endpoint to serve all? Or a clean core endpoint with sidecar APIs?

Initially, you build a single endpoint to serve all needs-but it quickly becomes fragile and hard to evolve.

// One Endpoint Trying to Serve All Use Cases
app.get("/api/v3/users/:userId", async (req, res) => {
  const user = await profileService.fetch(userId);
const location = await geoService.lookup(user.locationId); // Assuming it's a 3rd party service, it might fail or be slow
  const adminFlags = await hrService.getAdminFlags(user.id); // Not needed by all consumers
  res.json({
    id: user.id,
    name: `${user.firstName} ${user.lastName}`,
    email: user.email,
    location,
    adminFlags,
  });
});

The above code is fragile. A single service failure takes down the entire response. Everyone gets all the data, whether they need it or not.

// DTO + Fallbacks is one way to solve this problem
// dto/PublicUserProfileDTO.ts
import { Expose } from "class-transformer";
export class PublicUserProfileDTO {
  @Expose() id: string;
  @Expose() name: string;
  @Expose() avatarUrl: string;
  @Expose() location?: string;
  static from(user: any, location?: string): PublicUserProfileDTO {
    return {
      id: user.id,
      name: `${user.firstName} ${user.lastName}`,
      avatarUrl: user.avatarUrl,
      location,
    };
  }
}
// ---------------------------------------------------------
// user.controller.ts
import { plainToInstance } from "class-transformer";
import { PublicUserProfileDTO } from "../dto/PublicUserProfileDTO";
app.get("/api/v3/users/:userId", async (req, res) => {
  onst user = await profileService.fetch(req.params.userId);
  const role = req.user?.role || "public"; // Confirm the role

  if (role === "admin") {
    adminFlags = await hrService.getAdminFlags(user.id);
  }
  let location: string | undefined;
  try {
    location = await geoService.lookup(user.locationId);
  } catch {
    location = undefined; // Fallback. dummy example. Please don't come after me saying it's against Typescript philosophy
  }
  const response = plainToInstance(
    PublicUserProfileDTO,
    PublicUserProfileDTO.from(user, location),
    { excludeExtraneousValues: adminFlags } // Get only required content
  );
  res.json(response);
});

• Only explicitly exposed fields are sent; internal schema changes won’t leak into the response.

• Having a fallback ensures predictable responses if other services fail.

• You can create new DTOs for future API versions without touching core logic.

You’re no longer optimizing just for functionality, but for resilience, collaboration, and change over time.

Because at this level, the question isn’t just “Does the API work?”; it’s “Will it still work X months/years from now, under pressure, across clients?”

Takeaways

• Junior engineers think about correctness of their implementation.

• Seniors think about robustness and user experience.

• Leaders think about longevity and ecosystem alignment.

• True API skill isn’t writing endpoints — it’s understanding requirements in multiple dimensions.

Good engineers implement APIs. Great engineers challenge the need for them.

What API lesson left an impact on you at job? Or if you’re earlier in your journey: What part of API design still feels unclear?

Drop a comment or share your favorite war story. Let’s grow together.

Until next time 👋