Forem: fern_d3v

soft_reset episode2

fern_d3v — Wed, 11 Feb 2026 23:03:42 +0000

Burnout, Rust, and the Feruchemy Problem

Burnout is weird. You know you need rest, but rest feels impossible when your brain won't stop running.

This week, I stopped pretending productivity was the cure. I let myself just exist. Morning coffee with my cat watching birds, bonding with a borrowed cat, falling down a TUI rabbit hole (shoutout to bookokrat and noctavox).

The thing that clicked: I've been thinking about Mistborn, and Feruchemy a lot lately. You can only tap what you've actually stored. You can't pull the rest you never gave yourself. Burnout isn't a motivation problem; it's an empty metalmind.

So I'm making changes. Going all-in on Rust. Swapping GUIs for CLI's. Being intentional instead of just busy. And I'm trying to remember; Sometimes the real win is just making space to exist.

What does rest actually look like for you

check out the full podcast here
cover image by Laura Samiento

burnout in learning

fern_d3v — Tue, 27 Jan 2026 20:41:59 +0000

the weight of burnout

life hits everyone differently. no two people share the exact same struggles, and no one person can claim to have greater struggles than another. burnout is one of those struggles that varies per individual. and the age-old question is, "how do i avoid burnout?"

i don't have those answers, unfortunately. burnout is one of my biggest struggles. has been for as long as i can remember. back when i was in film school it seemed easier to counter burnout as it approached, but the older i got, the lower my threshold for burnout became. this time, i got about 6 months before the burnout really took its toll.

i am not the oprah of solutions

while developers are, at their core, problem solvers. and there are a million and one videos and articles on how to avoid burnout. none offered long term applicable solutions to me. set alarms to remind yourself so you don't go a day without it does not work mid-burnout (having adhd doesn't help honestly). set a schedule, these are my absolute enemy.

i cannot get locked into a schedule that would dictate my though process. i'm just a lil weirdo who needs to be able to do things on their time or nothing will happen.

wrap it up, friend

i apologize if you came into this tiny article hoping for a solution to burnout. solutions evade me like fish covered in oil in a stream. i would be forever grateful to anyone who feels a kinship to this issue, and has found a way to combat, or minimize their burnout.

interpreter? hmm...

fern_d3v — Fri, 31 Oct 2025 16:45:13 +0000

new project: nekkoscript

I have decided that for my next personal project, I am going to learn how to make my own lil language that I'm calling nekkoscript. Originally, this was going to be interpreted into JavaScript, but after doing some research, I think I want to go with Typescript instead.

but why?

Why not? I have absolutely no clue what I am doing or even how to write my own language, just like my previous project devKataCLI. I find that if I go in completely blind and learn as I go, that success is far more likely. There is an internal drive to learn that pushes me daily, and that feral goblin is ravenous for knowledge.

typescript?

The decision to switch from JavaScript to TypeScript was pretty simple to me. I really admire how TypeScript functions and how strict it is with types. I find it forces me to write cleaner code and need to be more present than when I write JavaScript (that is probably just a me problem, but I'm trying to work with my weaknesses here).

we have one yes, but what about second language?

I was told as a kid, "go big or go home". Well... I am at home already so, I guess I gotta go big. After I finish nekkoscript, I want to work on my own fully compiled programming language. For this one, I will probably lean on Rust (it fascinates me).

is that all?

For now? Yes. These are some really big goals I have set for myself and I am ecstatic to work on them! Currently, I am following this tutorial series on youtube on making a TypeScript Interpreter. I highly recommend check it out if this topic has piqued your own lil learning goblin.

>nikko the nekko header. wip

Building Better Dev Habits with devKataCLI: A Terminal-Based Practice Routin

fern_d3v — Mon, 06 Oct 2025 05:37:48 +0000

Building Better Dev Habits with devKataCLI: A Terminal-Based Practice Routine

TL;DR

The Problem: My ADHD brain can't stick to morning dev routines. I know I should practice coding daily, but consistency is hard when you're tired from your day job and need structure.

The Solution: I built devKataCLI - a terminal-based tool that guides you through daily dev warmup routines. It's like having a personal trainer for your coding habits, but in your terminal.

How It Works: Three progressive kata levels:
• miniKata (10-15 min): Posture check, daily goals, read a tech article, review a GitHub repo
• namiKata (15-30 min): Everything above + hydration check, review yesterday's code, typing practice
• devKata (30-45 min): Everything above + stretches, coding challenge, coding sandbox

The Tech: Built with Node.js, @clack/prompts for beautiful CLI interactions, integrated with Dev.to and GitHub APIs, git commit reviews, and detailed session logging.

Why It Matters: Start small, build progressively, and trick your brain into consistent practice. The CLI handles the planning - you just show up and code.

Try it: npm install -g devkatacli or npx devkatacli start

Full article dives into the technical challenges, architecture decisions, API integrations without axios (learned the hard way!), and how progressive habits actually work. Plus my journey from "I should practice more" to actually doing it every morning.

How devKataCLI Works

The User Experience

Let me walk you through what a typical morning looks like with devKata. You wake up, grab your coffee (or tea, no judgment), and instead of staring blankly at your IDE wondering where to start, you simply open your terminal and type:

$ devkata start

And boom, you're greeted with this beautiful ASCII art banner that I spent way too much time on (but it looks sick, so worth it):

The CLI then asks you which kata you want to run. Let's say you're feeling ambitious and choose the full devKata:

Then it walks you through each task, one at a time. First up? Posture check. Because let's be real, we all sit like shrimp at our desks.

Next, you set your daily goals. This is where the magic happens - you're being intentional about your day before the chaos starts:

Then it gets really cool - the CLI searches Dev.to for a random article based on tags you provide:

This pattern continues, you get to choose a subject to search GitHub for and it will fetch a random repository for you to review:

The whole experience feels like having a personal trainer for your dev skills, but without the yelling.

What's Inside Each Kata?

miniKata (10-15 minutes)
Your morning warmup starts with a posture check (because we all sit like shrimp). Set three daily goals to stay focused on what matters. Then the CLI searches Dev.to for a random tech article based on your tags and finds a highly-starred GitHub repo to review. First API integration = lots of mistakes, but it works! Fair warning: no language filter yet, so you might get an article in Portuguese.

namiKata (15-30 minutes)
Builds on miniKata by adding: hydration check, communications review, and the big one - reviewing yesterday's git commits. This habit keeps your GitHub graph green and helps you pick up where you left off. Ends with typing practice on MonkeyType because keyboard speed matters when you're in flow state.

devKata (30-45 minutes)
The final boss. Adds stretches (stay limber!), a coding challenge (CodeWars or LeetCode - your choice), and the coding sandbox. The sandbox is a persistent file in ~/.config/devKata/ that opens in your IDE. It's your blank canvas - practice algorithms, debug that annoying bug, or slowly build a side project. Whatever you write stays there for tomorrow. Future plan: make it a git repo so every sandbox session builds that commit streak.

The progression is intentional: miniKata teaches basics, namiKata adds real dev workflow, devKata makes you actually code. Start small, build up, stay consistent.

Technical Deep Dive

The Tech Stack

I wrote this in JavaScript utilizing Node.js because:

This is a CLI and I don't know any other languages to build one in (yet!)
I needed something familiar for building my first real application
Node gives me access to its vast library of packages

The core dependencies I chose were:

@clack/prompts - This library is chef's kiss. It provides beautiful, interactive CLI prompts that make the whole experience feel polished. I chose it over Inquirer because the API is cleaner and the prompts look gorgeous right out of the box.
picocolors - The fastest terminal styling library. I went with the Dracula color scheme because purple and cyan just hit different.
commander - For command parsing and routing. Super straightforward for defining devkata new and devkata start.

Architecture Overview

The project is structured like this:

devKataCLI/
├── src/
│   ├── index.js              # Entry point & command routing
│   ├── commands/
│   │   ├── new.js           # Kata creation workflow
│   │   └── start.js         # Kata execution engine
│   └── utils/
│       ├── storage.js       # File system operations
│       ├── handlers.js      # Task-specific handlers
│       ├── apiHelpers.js    # API integrations
│       ├── systemHelpers.js # System operations (git, browser)
│       ├── logger.js        # Session logging
│       └── helpers.js       # General utilities
└── package.json

The flow is pretty straightforward:

User runs devkata new or devkata start
Commander routes to the appropriate command file
Command files use @clack/prompts for user interaction
Storage utils handle reading/writing to ~/.config/devKata/
Handlers execute specific tasks (posture check, code review, etc.)
Logger tracks sessions and progress

Everything is saved to ~/.config/devKata/ which includes:

kata.json - Your saved kata configurations
config.json - Git repos and sandbox languages
logs/ - Daily session logs with metrics
coding-sandbox.* - Your practice files

Key Features I'm Proud Of

1. Interactive Configuration

The devkata new command is where users build their kata. I'm really proud of how this turned out because it guides you through the entire setup without feeling overwhelming:

export default async function newCmd() {
  intro(dracula.special('Create a new devKata routine'));

  const kataType = await select({
    message: dracula.info('What type of kata would you like to create?'),
    options: [
        { value: 'miniKata', label: 'miniKata (10-15 minutes)' },
        { value: 'namiKata', label: 'namiKata (15-30 minutes)' },
        { value: 'devKata', label: 'devKata (30-45 minutes)' }
    ],
  });

  const useDefaults = await select({
    message: dracula.info('How would you like to configure this kata?'),
    options: [
        { value: true, label: dracula.special('Use default kata') },
        { value: false, label: dracula.alt('Create custom kata') }
    ],
  });

  // ... rest of the setup flow
}

I implemented a progressive default system where each kata type builds on the previous one:

export async function buildKata(type) {
    let tasks = [];
    // Always start with miniKata
    tasks = [...DEFAULT_KATAS.miniKata];

    // Add namiKata tasks if selected
    if (type === 'namiKata' || type === 'devKata') {
        tasks = [...tasks, ...DEFAULT_KATAS.namiKata];
    }

    // Add devKata tasks if selected
    if (type === 'devKata') {
        tasks = [...tasks, ...DEFAULT_KATAS.devKata];
    }

    return tasks;
}

This means if you choose devKata, you automatically get all the miniKata and namiKata tasks too. It's progressive!

2. API Integrations

This was my first time working with APIs, and honestly, I made it way harder on myself than it needed to be. I didn't use axios or any fancy HTTP library - just raw Node.js https module because I wanted to understand how HTTP requests actually work.

Here's my custom HTTPS wrapper:

function httpsGet(url, timeout = 10000) {
    return new Promise((resolve, reject) => {
        const options = {
            timeout,
            headers: {
                'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36',
                'Accept': 'application/json'
            }
        };

        const request = https.get(url, options, (response) => {
            let data = '';

            response.on('data', (chunk) => {
                data += chunk;
            });

            response.on('end', () => {
                if (response.statusCode !== 200) {
                    reject(new Error(`HTTP ${response.statusCode}`));
                    return;
                }
                try {
                    const parsed = JSON.parse(data);
                    resolve(parsed);
                } catch (error) {
                    reject(new Error('Failed to parse JSON response'));
                }
            });
        });

        request.on('error', (error) => reject(error));
    });
}

The User-Agent header was crucial - without it, some APIs were blocking my requests thinking I was a bot (which, fair).

For Dev.to articles:

export async function fetchDevToArticles(tags) {
    try {
        const tag = Array.isArray(tags) ? tags[0] : tags;
        const url = `https://dev.to/api/articles?tag=${encodeURIComponent(tag)}&per_page=100`;

        const articles = await httpsGet(url);

        return {
            success: true,
            articles: articles,
            count: articles.length
        };
    } catch (error) {
        return {
            success: false,
            articles: [],
            count: 0,
            error: error.message
        };
    }
}

And for GitHub repos:

export async function fetchGitHubRepos(query) {
    try {
        let searchQuery;
        if (query.includes(' ') || query.includes(':')) {
            searchQuery = `${query} stars:>1000`;
        } else {
            searchQuery = `language:${query} stars:>1000`;
        }

        const url = `https://api.github.com/search/repositories?q=${encodeURIComponent(searchQuery)}&sort=stars&order=desc&per_page=100`;
        const response = await httpsGet(url);

        return {
            success: true,
            repos: response.items || [],
            count: response.items ? response.items.length : 0
        };
    } catch (error) {
        return {
            success: false,
            repos: [],
            count: 0,
            error: error.message
        };
    }
}

I added the stars:>1000 filter to ensure we're only surfacing quality repos, not random experiments.

3. Git Integration

This feature is probably my favorite because it actually makes you look at your code from yesterday. The implementation uses Node's child_process to run git commands:

export async function getGitCommits(repoPath, since = 'yesterday') {
    try {
        const normalizedPath = path.normalize(repoPath);

        const untilDate = since === 'yesterday' ? 'today' : 'now';
        const cmd = `cd ${JSON.stringify(normalizedPath)} && git --no-pager log --since=${JSON.stringify(since)} --until=${JSON.stringify(untilDate)} --oneline`;

        const { stdout, stderr } = await execAsync(cmd, { timeout: 5000 });

        const commits = stdout.trim().split('\\n').filter(line => line.length > 0);

        return {
            success: true,
            commits,
            count: commits.length,
            repoPath
        };
    } catch (error) {
        return {
            success: false,
            commits: [],
            count: 0,
            error: error.message
        };
    }
}

The key here is git --no-pager - without that flag, git tries to open a pager and the command hangs. Learned that one the hard way.

You can even view the full diff of a commit:

export async function getCommitDiff(repoPath, commitHash) {
    try {
        const normalizedPath = path.normalize(repoPath);

        // Validate commit hash (should be alphanumeric)
        if (!/^[a-f0-9]+$/i.test(commitHash)) {
            throw new Error('Invalid commit hash');
        }

        const cmd = `cd ${JSON.stringify(normalizedPath)} && git --no-pager show ${commitHash} --color=always`;

        const { stdout } = await execAsync(cmd, { timeout: 10000, maxBuffer: 1024 * 1024 * 10 });

        return {
            success: true,
            diff: stdout,
            commitHash
        };
    } catch (error) {
        return {
            success: false,
            diff: '',
            error: error.message
        };
    }
}

The --color=always flag preserves git's beautiful diff coloring in the terminal.

4. Progress Tracking & Logging

Every session is logged with detailed metrics. This was important to me because I wanted to be able to look back and see my consistency over time:

export function createSessionObject(kataType) {
    return {
        sessionId: generateUUID(),
        kataType: kataType,
        startTime: new Date().toISOString(),
        endTime: null,
        totalDuration: null,
        status: null,
        tasks: [],
        summary: {}
    };
}

Each task gets its own log entry:

export function createTaskLogEntry(task, result) {
    return {
        taskId: task.taskId,
        description: task.description,
        category: task.category,
        status: result.status || null,
        timestamp: result.timestamp || null,
        duration: result.duration || null,
        details: result.details || null,
        notes: result.notes || ""
    };
}

The logs are saved as JSON files in ~/.config/devKata/logs/ with filenames like kataLog_2025-10-06.json. This makes it easy to parse and potentially build analytics or visualizations later.

Interesting Technical Challenges

Challenge 1: Building Without External HTTP Libraries

The Problem: I wanted to keep dependencies minimal, but I also needed to fetch data from Dev.to and GitHub APIs. Most tutorials say "just use axios" but I wanted to actually understand HTTP.

My Approach: I dove into Node's built-in https module documentation. It's... not the friendliest API. Everything is event-based and you have to manually handle response chunks, timeouts, errors, etc.

The Solution: I built a Promise wrapper around https.get() that handles all the edge cases:

function httpsGet(url, timeout = 10000) {
    return new Promise((resolve, reject) => {
        const options = {
            timeout,
            headers: {
                'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)',
                'Accept': 'application/json'
            }
        };

        const request = https.get(url, options, (response) => {
            let data = '';
            response.on('data', (chunk) => { data += chunk; });
            response.on('end', () => {
                try {
                    resolve(JSON.parse(data));
                } catch (error) {
                    reject(new Error('Failed to parse JSON'));
                }
            });
        });

        request.on('timeout', () => {
            request.destroy();
            reject(new Error('Request timeout'));
        });

        request.on('error', reject);
    });
}

What I Learned:

The User-Agent header is crucial - without it, you're getting blocked
Always set timeouts or your CLI will hang indefinitely
JSON parsing can fail, always wrap in try-catch
Event-driven code is harder to reason about than Promises

Would I use axios next time? Probably, but I'm glad I learned the hard way first.

Challenge 2: Task Handler Routing System

The Problem: Each task type needs different behavior. Posture checks show tips, code reviews open git diffs, articles search APIs, etc. How do I route tasks to the right handler without a massive if-else chain?

My Approach: I initially had a giant switch statement in start.js that was getting unmanageable. I needed something more extensible.

The Solution: I created a handler system where each task type has its own function in handlers.js, and the router uses keyword matching:

let taskResult;
const description = task.description.toLowerCase();

// Route to appropriate handler based on task description
if (description.includes('posture')) {
    taskResult = await handlePostureCheck(task);
} else if (description.includes('goal')) {
    taskResult = await handleSetDailyGoals(task);
} else if (description.includes('article') || description.includes('read')) {
    taskResult = await handleReadTechArticle(task);
} else if (description.includes('repo') || description.includes('github')) {
    taskResult = await handleRandomRepoReview(task);
} else if (description.includes('review') || description.includes('yesterday')) {
    taskResult = await handleReviewYesterdaysCode(task);
} else if (description.includes('typing')) {
    taskResult = await handleTypingPractice(task);
} else if (description.includes('challenge') || description.includes('codewars')) {
    taskResult = await handleDailyCodingChallenge(task);
} else if (description.includes('sandbox')) {
    taskResult = await handleCodingSandbox(task);
} else {
    // Fallback for custom tasks
    const confirmed = await confirm({
        message: dracula.info(`complete ${task.description}?`)
    });
    taskResult = { completed: confirmed, cancelled: false, details: {} };
}

Each handler returns a consistent result shape:

{
    completed: boolean,
    cancelled: boolean,
    details: {
        // Task-specific data for logging
    }
}

What I Learned:

Consistency in return values makes everything easier downstream
Keyword matching is flexible for custom tasks
Having a fallback handler is crucial for extensibility
This pattern makes testing individual handlers way easier

Challenge 3: Session Logging Architecture

The Problem: I wanted rich session logs that track:

What tasks were completed
How long each took
What the user actually did (which article, which repo, etc.)
Session status (mastered, partial, abandoned)

But I also needed this to be non-blocking and not ruin the UX if logging fails.

My Approach: I designed a hierarchical logging structure:

~/.config/devKata/logs/
  └── kataLog_2025-10-06.json
      ├── date
      ├── appVersion
      └── sessions[]
          ├── sessionId
          ├── kataType
          ├── startTime
          ├── endTime
          ├── tasks[]
          │   ├── taskId
          │   ├── description
          │   ├── status (mastered/deferred/abandoned)
          │   ├── duration
          │   └── details{}
          └── summary{}

The Solution: I created a logging system that:

Creates a session object at the start
Appends task entries as they complete
Calculates summary stats at the end
Saves to a daily log file

// Complete the session after all tasks
session.endTime = new Date().toISOString();
session.totalDuration = Math.floor((new Date() - new Date(session.startTime)) / 1000);

// Calculate summary
session.summary = {
    totalTasks: session.tasks.length,
    mastered: session.tasks.filter(t => t.status === "mastered").length,
    deferred: session.tasks.filter(t => t.status === "deferred").length,
    abandoned: 0
};

// Determine session status
if (session.summary.mastered === session.summary.totalTasks) {
    session.status = "mastered";
} else {
    session.status = "partial";
}

// Save the session to log
await appendSession(today, session);

What I Learned:

ISO timestamps are your friend
Calculating metrics at save-time is easier than computing on-read
Daily log files keep things organized
Having detailed logs opens up future analytics possibilities

The logging system also captures task-specific details. For example, when you read an article:

return {
    completed: confirmed,
    cancelled: false,
    details: {
        tags: tagArray,
        article: article.title,
        author: article.user.name,
        url: article.url,
        timestamp: new Date().toISOString()
    }
};

This means I can later analyze things like:

What topics am I reading about most?
Which repos did I review?
What's my completion rate over time?
How long do different tasks actually take me?

Challenge 4: Cross-Platform System Integration

The Problem: I needed to open browsers, editors, and directories from the CLI. But open on macOS, start on Windows, and xdg-open on Linux are all different commands.

My Approach: I initially hardcoded open because I develop on macOS. Then I realized this would break for anyone not on Mac (oops).

The Solution: Platform detection with fallbacks:

export async function openRepoInIDE(repoPath) {
    try {
        const normalizedPath = path.normalize(repoPath);

        // Try VS Code first (cross-platform)
        try {
            await execAsync(`code ${JSON.stringify(normalizedPath)}`);
            return { success: true, message: 'Opened in VS Code' };
        } catch {
            // Fallback to macOS 'open' command
            try {
                await execAsync(`open ${JSON.stringify(normalizedPath)}`);
                return { success: true, message: 'Opened repository' };
            } catch {
                // Last fallback: manual instruction
                return {
                    success: false,
                    message: `Navigate to: ${normalizedPath}`
                };
            }
        }
    } catch (error) {
        return { success: false, message: 'Failed to open repository' };
    }
}

What I Learned:

Always test on multiple platforms (or get friends to test for you)
Graceful fallbacks > breaking the entire app
User instructions are better than silent failures
The VS Code CLI (code) is surprisingly well-supported

Distribution Strategy

Making It Easy to Install

One of my goals with devKataCLI was to make it as frictionless as possible to get started. Nobody wants to clone a repo, run npm install, and figure out linking just to try a CLI tool. So I focused on multiple distribution methods:

npm Global Package

This was the easiest to set up. In my package.json, I defined:

{
  "name": "devkatacli",
  "version": "1.0.0",
  "bin": {
    "devkata": "./src/index.js"
  }
}

The bin field tells npm to create a symlink to src/index.js when someone installs globally. The shebang at the top of that file (#!/usr/bin/env node) makes it executable.

Publishing was as simple as:

npm login
npm publish

Now anyone can run:

npm install -g devkatacli
devkata --help

Homebrew Tap

This was more involved but so worth it for macOS users. Homebrew is the de facto package manager for Mac, and having a formula makes installation brain-dead simple.

I created a tap (a third-party Homebrew repository) at fern-d3v/homebrew-devkatacli and “wrote” (borrowed from the internet) a formula:

class Devkatacli < Formula
  desc "Master dev habits, one kata at a time"
  homepage "<https://github.com/fern-d3v/devKataCLI>"
  url "<https://registry.npmjs.org/devkatacli/-/devkatacli-1.0.0.tgz>"
  sha256 "YOUR_SHA_HERE"
  license "MIT"

  depends_on "node"

  def install
    system "npm", "install", "-g", "--prefix=#{libexec}", "devkatacli@#{version}"
    bin.install_symlink Dir["#{libexec}/bin/*"]
  end

  test do
    system "#{bin}/devkata", "--help"
  end
end

Now users can:

brew tap fern-d3v/devkatacli
brew install devkatacli

And voilà, they're kata masters!

npx for Zero Install

This is my favorite because there's literally zero setup:

npx devkatacli start

It downloads and runs the CLI on the fly. Perfect for people who want to try it before committing to an install.

Why Offer Multiple Options?

Because developers have preferences! Some people love Homebrew, some prefer npm, some just want to try things without installing. By supporting all three, I'm removing friction and letting people use the tool however they're comfortable.

What I Learned

Technical Learnings

CLI Development is a Different Beast

I learned that building a CLI is fundamentally different from building a web app. There's no DOM, no hot reload, no browser DevTools. When something breaks, you're debugging with console.log like it's 2010 (and honestly? It's kinda refreshing).

The interactive prompt libraries like @clack/prompts are game-changers. They handle all the terminal manipulation, cursor positioning, and input parsing so you can focus on the UX.

APIs Are Both Simpler and Harder Than I Thought

Simple because: most REST APIs are just HTTP GET requests that return JSON.

Harder because: handling timeouts, retries, rate limits, parsing errors, network issues, API changes, etc. All the edge cases you don't think about until they break your CLI at 2 AM.

File System Operations Require Paranoia

Always assume:

The file doesn't exist
The directory isn't writable
The JSON is corrupted
The user will Ctrl+C at the worst possible moment

Defensive programming isn't optional in CLI tools. Wrap everything in try-catch, validate all paths, use atomic writes, and always have fallbacks.

ES Modules in Node Are Great (Once You Figure Them Out)

The "type": "module" in package.json unlocks modern JavaScript in Node. But there are gotchas:

You need .js extensions in imports (annoying but whatever)
__dirname doesn't exist (use path.dirname(fileURLToPath(import.meta.url)))
Some old packages don't support ESM

Worth it though. Async/await everywhere, clean imports, no more webpack for CLI tools.

Product Learnings

Default Templates Are Essential

Originally I was going to make users build their katas from scratch. Then I tested with a friend (me) who said "I have no idea what tasks to add, just give me something that works."

That's when I added the default kata templates. Now 95% of users just choose the defaults and start immediately. The option to customize is there, but most people just want to get going.

Progressive Complexity Actually Works

The miniKata → namiKata → devKata progression wasn't just a cool naming scheme. It genuinely helps people build the habit gradually. Start with 10 minutes, then 15, then 30+. By the time you're doing full devKatas, it doesn't feel overwhelming because you've been building up to it.

Feedback Loops Matter

Every completed task shows a success message. Every kata completion gets a cute "see you tomorrow <3" outro. These tiny dopamine hits make the routine feel rewarding, not like a chore.

Documentation Is a Feature

I spent a lot of time on the README, writing clear installation instructions, and creating a CONTRIBUTING guide. That documentation has driven more engagement than anything else. Good docs = people actually using your tool.

Open Source Learnings

Choosing MIT License Was Liberating

I went with MIT because I want people to use this, fork it, remix it, whatever. No restrictions, just build cool stuff. It's freeing to not worry about license compatibility issues.

Issue Templates Help Everyone

When someone reports a bug, the issue template guides them to include:

Node version
OS
Steps to reproduce
Error messages

This saves SO much back-and-forth in comments.

Being Vulnerable Is Okay

This is my first real open source project. My code isn't perfect. There are probably bugs I don't know about. And that's okay! Putting it out there, flaws and all, has been incredibly educational. People are mostly supportive and helpful.

Results and Feedback

My Own Usage

I've been using devKataCLI almost every morning for the last week. The biggest change? I actually start coding sessions now. Before, I'd sit at my desk, scroll Twitter for 30 minutes, maybe check emails, and suddenly it's 10 AM and I haven't written a line of code.

Now I run devkata start, and within 15-30 minutes I'm warmed up, I've seen what I did yesterday, I've learned something new, and my brain is in "coding mode." The routine tricks my ADHD brain into focusing.

The daily goals feature is surprisingly powerful. Just writing down three things makes me aware of what actually matters that day. I still get distracted, but I catch myself faster because I know what I'm supposed to be doing.

The coding sandbox has become my favorite part. It's just a blank file that persists every day. I've been using it to practice algorithms, work through LeetCode problems slowly, and even prototype features for other projects. It's my scratch space, and it's always there waiting for me.

Future Plans

I have a lot of ideas for where to take devKataCLI. Here's what's on the roadmap:

Near-Term (Next 1-3 Months)

🔧 Better Error Handling

More graceful failures when APIs are down
Offline mode that works without internet
Better validation for git repositories

📊 Progress Analytics

Weekly summary of kata completions
Streak tracking (don't break the chain!)
Visual progress charts (open to suggestions!)

🎨 Customization Options

Custom color themes (not everyone loves Dracula purple)
Configurable task durations
Ability to reorder tasks

🌐 More API Integrations

Hacker News top stories
Reddit programming threads
Stack Overflow questions
YouTube coding tutorials

Mid-Term (3-6 Months)

🧩 Plugin System

Let community members create custom tasks
Plugin marketplace (npm packages with naming convention devkata-plugin-*)
Easy plugin installation via CLI

🤝 Integration with External Tools

Todoist/Notion for daily goals
Wakatime for coding metrics
Slack/Discord notifications

📱 Mobile Companion App?

Maybe a simple mobile app that syncs with the CLI
Push notifications for kata reminders
View your stats on the go
(This is ambitious and I don't know React Native, so... TBD)

Long-Term (6+ Months)

🏆 Gamification

Achievement system (badges, levels)
Challenges (complete 30 devKatas in a row)

👥 Team/Collaborative Features

Shared katas for dev teams
Group challenges
Team leaderboards
Morning standup integration

Community Ideas I'm Considering

People have suggested:

Pomodoro timer integration - Start a kata, get Pomodoro breaks built in
Music/playlist integration - Open Spotify playlists for focus
Habit tracking integration - Sync with Habitica or similar

How You Can Help

The roadmap is flexible! If you have ideas, open an issue on GitHub. If you want to build something, PRs are always welcome. Even just using the tool and reporting bugs helps immensely.

I'm also considering creating a Discord community for devKata users to share their routines, tips, and custom tasks. Would people be interested in that? Let me know!

Try It Yourself!

Quick Start

Via npm:

npm install -g devkatacli
devkata new
devkata start

Via Homebrew:

brew tap fern-d3v/devkatacli
brew install devkatacli
devkata new
devkata start

Or try without installing:

npx devkatacli start

Getting Involved

⭐ GitHub: https://github.com/fern-d3v/devKataCLI

Star the repo if you find it useful!
Open issues for bugs or feature requests
Submit PRs (check CONTRIBUTING.md first)

📦 npm: https://www.npmjs.com/package/devkatacli

Download stats help me understand usage
Leave feedback in the npm comments

☕ Support: https://ko-fi.com/fernd3v

Buy me a coffee if you want to support development
All donations go toward making this tool better

Conclusion

Building devKataCLI has been one of the most rewarding projects I've worked on. Not because it's technically complex (it's not), but because it solves a real problem I had.

The core insight is simple: consistency beats intensity. Doing a 15-minute kata every morning is infinitely better than planning an ambitious 4-hour study session that never happens. By making the routine frictionless, progressive, and actually enjoyable, devKataCLI helps bridge the gap between intention and action.

I'm still learning as I go. The code isn't perfect. There are features I want to add and bugs I need to fix. But it's out there, people are using it, and it's helping them build better habits. That's pretty cool.

If you struggle with consistency, give devKataCLI a try. Start with a miniKata. Just 10-15 minutes. See if it clicks. Maybe it'll work for you like it worked for me.

And if you're thinking about building a CLI tool yourself? Do it. The world needs more terminal-based utilities. Plus, it's incredibly fun to build something you use every single day.

Now if you'll excuse me, I have tomorrow's devKata to prepare for.

⛩️

Links:

What are your daily dev habits? How do you stay consistent with practice? Let me know in the comments!

Return;

fern_d3v — Sun, 21 Sep 2025 08:05:22 +0000

When things change

I had to take a small break from writing my weekly blog. I don't know about many of you, but I am a creature of habit, and if that habit is broken or interrupted at all everything goes down the drain. I had gotten a job after taking a couple months to myself, and severely underestimated the toll of working full time again and studying full time webdev / maintaining a weekly custom blog.

While that was a really cool project, and I will probably go back to it at some point. I think from here out, I am just going to be publishing my articles here. My original goal was to catalogue my learning journey and if I feel too overwhelmed to do everything that went into maintaining my blog, then I'm just not going to write the post or upload it.

Looking to the future

While I may have taken a break from writing a weekly blog, I did not take a break from learning and building. I have made a couple fun little CLI tools for learning purposes and am actively working on my first actual CLI app that I will personally be using and hope others find use in it as well (more on that very very soon, probably monday).

I am still not even halfway through my full stack dev path, but I can tell you this right now, I think I want to make CLI tools for devs to use. My biggest thing in life has been that I enjoy being of assistance to others. And in this field, what better way to do that than to work on dev tools?

I recently read this article about how developers don't make things anymore for the joy of learning something new. That really struck a cord with me. I used to be a video editor and one of my favorite things to do in my downtime was to tinker with weird things or to learn a new method for doing something to grow my abilities. I feel my natural desire to assist, coupled with my love of tinkering and learning will lend itself well regardless of what I end up doing as a dev.

Return;

fern_d3v — Sun, 21 Sep 2025 08:05:22 +0000

When things change

Looking to the future

🧠 Getting Git: A Friendly Intro to Git, GitHub, and GitHub Pages

fern_d3v — Sat, 02 Aug 2025 22:04:18 +0000

Version control felt like wizardry when I first started coding. Cryptic commands, weird workflows, and a whole lot of mystery.

But once I got it, I realized: Git is one of the most powerful tools in your developer toolbox.

In this blog post, I guide you through setting up Git and GitHub step-by-step, with real terminal commands and tips for beginners:

💻 In this post you'll learn:

What version control actually means

How to initialize a local Git repo from your terminal

How to connect it to GitHub

How to publish your own website for free using GitHub Pages

No fluff, just a beginner-friendly walkthrough written by someone who recently went through it too.

If you're building your first portfolio, starting dev school, or just need a refresher, this one's for you.

👉 Read the full post here:
🌐 console.git(versionControl)

Let me know what helped (or confused you), I’d love to improve it for future devs just starting out!

Visual Studio Code for Beginners!

fern_d3v — Sat, 26 Jul 2025 23:22:52 +0000

open source-ish...

One of the most important decisions you will make in the early days of aspiring to become a full-stack dev is which IDE (integrated development environment) you will choose. Now, technically it is way more important to find good instruction, but, finding an IDE that has a large community and is widely used is indispensable. Having support in the droves of millions for whenever you have questions gives a peace of mind that I didn't know I needed with this decision.

Originally, I wanted to use WebStorm by JetBrains. An IDE made for JavaScript and TypeScript (but can be used for HTML, CSS, and many others). I have a fondness for JetBrains. Their font "JetBrains Mono" is what this site runs on and I really like the sleek, simple layout of their software. But I was reminded gently by a co-learner over on Codecademy that having the things mentioned above are really more important than what an IDE looks and feels like. Especially if you are just starting out like I am and don't have the first idea what these things really can do.

So we start with Visual Studio Code, made by Microsoft. It is an IDE that feels open source at first look. It has what seems like an endless chasm of plugins and themes to dive into. In this post, we will go over basic install and setup of VS Code as well as some of the plugins that I use daily that make life easier and some that are just fun little QoL things.

If you, like me, had a hard time choosing an IDE at first, then keep reading! I'm sure by the end of this you will either be excited to install VS Code, or even more confused like I was on my first VS Code walkthrough.

If you enjoyed what I have written so far and want to read more, head on over to console.log for the full post!

Happy coding!
-fern_d3v

learning through repetition

fern_d3v — Sun, 20 Jul 2025 00:08:11 +0000

I made a reference site to use for development so I can quickly reference things I need in the future. So far I have made pages for HTML and CSS. I struggled with setting up tables in HTML and had a hard refresher in CSS syntax and proper management, but this project helped immensely.

Strap in, grab a caffeinated drink (don't lie, you were looking for yours just like I am mine), and get ready for a beginners guide to how to make your own quick reference site.

Want to know more?

Check out the full story on my blog at console.log where I dive deeper into:

What is a reference site
Why I am making one
A soft outline of how you can make one too!

Thanks for reading! If you’re on your own learning journey, I’d love to hear from you.

Meet BMO: My Pixel Coding Companion

fern_d3v — Thu, 17 Jul 2025 02:35:42 +0000

This is BMO.

He reviews every commit.

With zero mercy.

I made this pixel art of my cat as a little mascot for my dev journey.

Pixelated, focused, and probably judging my syntax.

Right now, I'm learning JavaScript and building out my personal projects, starting small, but trying to stay consistent.

If you're also starting out or building in public, drop a link to your work below! Let’s connect.

#devcat #pixelart #beginnerdev #buildinpublic

Why I Chose Codecademy to Learn Full-Stack Web Development

fern_d3v — Sat, 12 Jul 2025 23:23:39 +0000

When I started learning web development, I was overwhelmed by scattered tutorials and random YouTube videos. I needed more than information—I needed structure and a clear roadmap to guide me.

That’s why I chose Codecademy.

Their Full-Stack Web Development path breaks down complex topics like HTML, JavaScript, React, Node.js, and deployment into bite-sized lessons with instant feedback. The browser-based IDE means no setup hassles, just focused learning and progress.

“It’s just code, feedback, and progress—one lesson at a time.”

While freeCodeCamp offers deep, free content, I needed a more linear, guided experience to keep momentum and motivation early on. Codecademy’s platform gave me that — helping me build confidence and consistency.

Want to know more?

Check out the full story on my blog at console.log where I dive deeper into:

How I saved money on Codecademy Pro
Why I set a tough 3-month goal
What’s next after finishing the full-stack path

Thanks for reading! If you’re on your own learning journey, I’d love to hear from you.

— </fern>