DEV Community: changelogHW

I Tried Textual for a Weekend. Here's Why I'm Not Going Back to Plain CLI Output

changelogHW — Tue, 28 Jul 2026 00:54:39 +0000

I've been writing Python CLI tools for years the same way: print() statements, maybe some argparse, and if I was feeling fancy, rich for colored output. Then I actually sat down and built something with Textual, and it changed how I think about terminal apps.

If you haven't heard of it, Textual is a Python framework (from the same team behind rich) for building full TUI (Terminal User Interface) apps --- think dashboards, forms, file browsers, all running inside your terminal, but with actual layout, widgets, mouse support, and CSS-like styling.

Why I picked it up

I wanted a quick internal tool to monitor some background jobs --- nothing worth a full web dashboard, but plain log output wasn't cutting it either. Textual felt like the middle ground I didn't know I needed.

So instead of just reading docs, I built something real with it: a command-logging utility --- a TUI where you can log commands you run (with context/notes attached) without breaking flow to open a separate notes app. Code's on GitHub.

Setting it up

pip install textual textual-dev

That's it. No extra system dependencies, no weird terminal config. textual-dev gives you a live console for debugging, which honestly saved me a lot of guesswork and the devtools lets you serve an app launched directly from a Python file.

The part that surprised me: CSS

Yes, actual CSS. You style widgets with .tcss files:

Screen {
    background: $surface;
}

#sidebar {
    width: 30;
    border: solid green;
}

Coming from years of manually padding strings to "layout" a CLI, this felt like cheating. Widgets snap into place, you get flexbox-like sizing, and you're not fighting with \n and spaces to align things.

A minimal example

from textual.app import App, ComposeResult
from textual.widgets import Header, Footer, Static

class DemoApp(App):
    CSS_PATH = "demo.tcss"

    def compose(self) -> ComposeResult:
        yield Header()
        yield Static("Hello from Textual", id="body")
        yield Footer()

if __name__ == "__main__":
    DemoApp().run()

Run it, and you already get a header, footer with keybindings, and a styled body. No boilerplate hell.

What actually impressed me

Reactive attributes : change a variable, and the UI updates automatically. No manual redraw logic.
Built-in widgets : DataTable, Tree, ListView, Input, all ready to use. I didn't have to build a table renderer from scratch.
Works over SSH : since it's still a terminal app, no port forwarding or browser needed. That alone makes it worth it for remote/server tooling.
Hot reload : textual run --dev app.py and CSS changes reflect instantly without restarting.

Where it got tricky

Debugging layout issues (widgets not sizing how you expect) took some trial and error — the docs help, but you'll spend time in the CSS live-reload loop.
Testing TUI apps isn't as straightforward as testing a normal script; Textual has a test harness (Pilot), but it's a different mental model.
Quitting the application (Ctrl+q) is sometimes tricky due to some similar key bindings.

The project: a command-logging utility

The idea was simple; I run a lot of one-off commands (debugging, ops, random scripts) and kept losing track of why I ran them. So I built a small Textual app that lets you:

Log a command + a quick note in one input
Browse past entries in a scrollable list
Delete entries without leaving the terminal

Nothing groundbreaking, but it's exactly the kind of tool that's annoying to build with plain print() and perfect for Textual's widget set: Input for capture, and reactive state to keep the list in sync as you add entries.

Should you use it?

If you're building anything more than a script that prints and exits — a monitoring tool, an admin utility, a game --- Textual is worth the few hours it takes to get comfortable. It's actively maintained, the community's responsive, and it makes terminal apps feel like a legitimate UI surface instead of an afterthought.

Note: I'm not affiliated with Rich/Textual in any way and these are my personal opinions.

Map out of the IDE: My DevRel Transition Roadmap

changelogHW — Sun, 05 Jul 2026 00:18:14 +0000

After staring at the JDs of Developer Relations(DevRel) Engineers for hours and doing a quick check of my own transferable skills, I started this week researching into specific DevRel roadmaps and resources.

Out of the 4+1 DevRel key responsibility areas (Advocacy, Education, Community Support, Content Creation and Feedback Loop), I selected the following core pillars to focus on first:

Pillar#1. Technical Writing:
Documentations, articles or blog posts; Like how you would learn to write the first 'hello world' in any programming language, I started to build a consistent writing habit in developer-centric language.
Whether it's Developer Education or Content Creation, knowing this always helps.

Pillar#2. Public Speaking:
Whether you're making a tutorial, giving a quick demo or presenting your product to developers - knowing presentation techniques like storytelling, engaging your audience through a 'hook' and handling Q&A helps you communicate your message effectively in public settings and is a very important part of DevRel.

Pillar#3. Community Metrics:
Instead of measuring system performance or uptime like a Software Engineer, this pillar is learning how to measure 'human interaction'. This is the part that gives you accountability with leadership. This may involve tracking things like community growth through retention rates, developer engagement through forum participation and content impact through views on technical tutorials or documentation.

If you're just starting like me, here are some of the resources I found really helpful:

Courses/Guides

Communities

Developer Relations Foundation on LinkedIn
DevRel Collective

Any other pivoting engineers who are also going through a similar experience, feel free to share any resources or follow along as I write while I learn.

Deconstructing the DevRel Job Description: A SWE’s Perspective

changelogHW — Sun, 28 Jun 2026 23:16:50 +0000

As a software engineer, my comfort zone is a dark terminal, a green test suite, and a predictable compiler. Compilers are great. They don't have feelings, and they tell you exactly why they are mad at you.

So, naturally, I decided to look into Developer Relations (DevRel).

If you have ever thought about trading your Jira tickets for developer advocacy, you have probably opened a few job descriptions (JDs) and felt immediate whiplash. I spent the last week auditing modern DevRel JDs to see what it actually takes to bridge the gap.

Here is the breakdown of what I found, minus the corporate buzzwords.

1. The Catalyst: Why look outside the IDE?
Let’s be honest. Building features is fun, but sometimes you realize you enjoy talking about the technology just as much as writing it. I noticed my favorite part of a sprint was explaining a complex system architecture to a junior developer or writing the internal documentation. That spark is usually the first sign of a DevRel pivot.

2. The Tech Stack vs. The People Stack
When an engineer reads a standard SWE description, we look for languages and frameworks. When you look at a DevRel description, the requirements look a bit different:

What we expect: "Must have 5 years of production Python experience."

The reality: "Must be able to build a quick API demo, write a tutorial about it, and present it without sweating through your shirt."

The technical depth is still required, but the output shifts from production-grade code to educational collateral. You aren't shipping enterprise software; you are shipping understanding.

3. The "Aha!" Moment
The biggest takeaway from analyzing these roles is that DevRel is not a marketing job masquerading as engineering. It is a translation layer.

Your job is to look at a product through a developer's eyes, find where it hurts, and help them fix it. You are an engineer whose primary debugging tool is empathy and communication, rather than a linter.

Image credits: designed by Freepik-Magnific.com

To keep myself accountable, I did a quick inventory of my own toolkit.

What transfers immediately:

The technical foundation: Knowing how developer tools work because I use them daily.

Empathy: I know exactly what makes a developer close a tab in frustration (looking at you, broken documentation).

The immediate gaps to bridge:

Public proof of work: It is one thing to write clean code for a private repository. It is another thing to write an engaging public article or record a video walkthrough that keeps a developer's attention for more than 30 seconds.

The next step:
Instead of just waiting until I magically feel ready, I am treating this transition like a engineering sprint. I found some roadmaps, joined the right communities, and I am going to build my way into the role by doing the actual work in public.

If you are an engineer who has successfully made the jump, or if you are currently staring at the same JDs I am, let me know what your biggest roadblock has been!