Building Terminal Graph, a Spatial Development Environment, With Caidan Williams

Building Terminal Graph, a Spatial Development Environment, With Caidan Williams ![rw-book-cover](https://img.youtube.com/vi/fUJRKhjen_I/maxresdefault.jpg) 🔗 **Source:** [Building Terminal Graph, a Spatial Development Environment, With Caidan Williams](https://www.youtube.com/watch?v=fUJRKhjen_I) > [!note]+ Document Notes > tags: [developer-tools, spatial-computing, terminal-emulators, indie-software, career-journey] > author: [MISSING] > source: Overcommitted Podcast (YouTube) > reference: https://www.youtube.com/watch?v=fUJRKhjen_I > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Building Terminal Graph, a Spatial Development Environment, with Caidan Williams >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - Caidan Williams, a partner at the "Internet Development Studio" (indev), built Terminal Graph — a canvas-based development environment where terminals, browsers, file editors, and notes live as connected nodes on an infinite Figma-like surface, with Unix-pipe-style data flow wired between them. - It matters because it's a genuinely novel entry in the "AI coding tool" wave: rather than a fixed three-panel layout (file tree / chat / diff), it treats the workspace itself as a graph the developer composes and rewires, and its differentiator — piping stdout/data between arbitrary node types — has no direct prior art according to Williams's own search. - Key stakeholders: Williams (solo builder turned team lead), indev's other five partners (holacracy structure, no employees/bosses), and a growing public-beta user base providing (often conflicting) feature feedback. - Risks/tradeoffs: feature-creep risk ("everything app") vs. staying primitive-focused; solo-founder bus-factor risk now being addressed by bringing in design/engineering help; monetization pressure since indev is bootstrapped, not VC-backed, and needs product revenue to reduce client-work dependency. - Bottom line: a personally-motivated side project (2 weeks to first working version) that validated itself through the builder's own daily use and is now being productized around a "blueprints" sharing mechanism for team workflows. ## 📖 Main Content Terminal Graph reframes the terminal-emulator problem. Every terminal emulator on the market (iTerm, Ghostty, Kitty, Alacritty, etc.) is fundamentally "a window with a split tree," in Williams's framing. Terminal Graph instead puts every terminal, browser, editor, and note a developer might have open onto one infinite canvas, and — critically — lets the developer draw data connections between those nodes: a terminal's stdout can be grepped by a utility node and piped into a browser node's URL bar, or a `git diff` can flow directly into an AI coding assistant node to draft a commit message. The project began as a personal curiosity experiment rather than a market analysis: could Unix pipe semantics be made visual and multi-way (many-to-one, not just linear piping)? Once the first two-terminal connection worked, Williams treated that as proof of concept and expanded outward — adding a WebKit/Safari-backed browser node (with injected JavaScript for data extraction), file/notes nodes, and utility nodes (switches, gates, delays, collections, template nodes with `{{curly-bracket}}` variable ports, and webhook nodes for external event ingestion). Two forces converged to turn the experiment into a product: a decade-plus of living in the terminal (Neovim, lazygit, fuzzy-finders) left Williams unsatisfied with the current crop of three-panel AI coding UIs (he names Conductor and Codex-style layouts specifically) as too rigid for his workflow; and indev, as a bootstrapped six-partner holacracy with no VC backing, has been trying to shift from pure client-services work toward owned products so the studio isn't perpetually dependent on the next contract. Feedback management became its own design discipline. Williams describes receiving "every opinion" from beta users and resolving the conflict by refusing to build "an everything app" — instead building primitives (nodes + connections, drawing on a personal background in graph theory) that let users compose their own workflows. The most underused-but-powerful primitive is the **blueprint**: a capturable, exportable (JSON), shareable snapshot of a node set — startup commands, URLs, file paths, notes — that lets a team distribute a standardized workflow (a release process, a security audit) as a "download, import, click run" artifact instead of a wiki page nobody reads. The second half of the conversation traces Williams's path into the industry: Minecraft modding in Java at 13 for pocket money, a shift to 2D game development in high school in Durango, Colorado (with a friend who became his long-time collaborator), a gap year (funded by no family money for college) spent applying to roughly 500 companies, landing a QA-engineer internship at Git Prime within 8 months, then a series of jobs (Pluralsight post-acquisition, Overjet doing dental-X-ray data pipelines, Domino Data Labs enabling a blind move to Seattle, a medical-imaging computer-vision role) punctuated by a pandemic-era 80-hour-week burnout and a 2024 layoff. He eventually networked his way into indev via a Seattle meetup and a one-month work trial that included redesigning an open-source monospace font (Server Mono). ## 🗒️ Notes - Terminal Graph's core metaphor: infinite canvas (à la Figma) + node graph, not a fixed pane layout. Nodes observed: terminal, browser (WebKit/Safari-backed), file editor (VS Code–backed), notes, template/variable node, switch/gate/delay/collection utility nodes, webhook node. - The differentiator Williams identifies after his own prior-art search: other "terminals on an infinite canvas" tools exist, but none of them implement cross-node **data flow/piping** — that's the gap Terminal Graph fills. - Concrete data-flow example given twice: (1) dev-server stdout → grep for local URL → auto-updates a browser node's address; (2) `git status`/`git diff` output → piped into an AI coding node → drafts a commit message. - Blueprints = the productization lever: capture a node set + its config as JSON, reinstantiate across projects/workspaces/machines, or hand to a teammate/team for a standardized shared workflow. - Company context: indev is a holacracy — ~6 equal-power partners, no employees, no bosses, no formal hierarchy for decision rights. Not venture-backed; survives on client-services revenue, which is the explicit motivation for pushing toward owned products. - Development timeline: 2 weeks to v1 → private beta (email list, later abandoned as unwieldy) → public beta (Sparkle + AppCast auto-update infrastructure) → currently public beta, with an eventual v1.0/GA planned once "kinks" are resolved. - Feedback philosophy: treat all feedback as signal, but filter through "primitives over features" — avoid becoming an "everything app." Graph-theory background (mathematical graphs, not just visual ones) cited as a direct influence on the node/connection data model. - Career arc highlights: Minecraft Java modding at 13 → high-school 2D game jams with a friend from Durango, CO → gap year with a self-imposed "get a tech job in a year or go to college on loans" deadline → QA engineer at Git Prime (built internal tools mocking GitHub/Bitbucket APIs to dodge rate limits, and a "time-travel" git-repo-recreation tool) → Git Prime acquired by Pluralsight (became "too big/impersonal," stalled promotion) → Overjet (Boston, Harvard Innovation Lab) building data pipelines for dental X-ray computer vision, including reverse-engineering an obscure unsigned-16-bit TIFF format from old digital X-ray machines → pandemic-era 80-hour weeks, underpaid, CEO friction → Domino Data Labs (remote, enabled a no-visit move to Seattle) → laid off in the 2024 layoff wave → 6-month self-directed hiatus → medical-imaging (MRI) computer-vision role → networking at a Seattle "distributed web meetup" led to meeting Jimmy Lee (indev founder) → desk rental → invited to a one-month partner work trial → contributed to the Server Mono open-source font → hired as full partner (~1+ year tenure at time of recording). - Explicit self-assessed lesson: attributes career success to persistence ("~500 applications") rather than innate intelligence; pushes back on the cultural assumption that software jobs are inherently stable or well paid. - Closing "what if this existed IRL" riff: co-host Erica maps it to family/location coordination with her husband and daughter; Williams maps it to ADHD-driven routine automation (laundry/chore reminders) and, separately, to early-parenthood tracking of twins' feeding/sleep ("Sims need bars" analogy). - Contact: kaidan.dev (spelled aloud "c-ai-dan.dev"), with links to Threads, Bluesky, and X from that site. ## 📚 References - [Terminal Graph](https://kaidan.dev) — Williams's site, linked to socials (URL as spelled aloud; not independently verified) - [Git Prime / Pluralsight acquisition](https://www.pluralsight.com) — company mentioned as Williams's first industry job, later acquired - [Overjet](https://www.overjet.ai) — dental X-ray computer vision company mentioned by name - [Domino Data Lab](https://www.dominodatalab.com) — mentioned by name (transcript renders it "Domino Data Labs") ## 🗣️ Paraphrase - Williams built Terminal Graph out of a personal itch: two decades in Linux/terminal tooling left him wanting to see every window he'd ever open — terminal, browser, editor, notes — on one shared canvas, and to wire them together the way Unix pipes wire commands together, but visually and many-to-many rather than one linear chain. Once the first proof-of-concept (two terminals piping to each other) worked, he treated his own excitement as validation and kept layering node types on top, eventually showing it to others and getting the same reaction. - The business case sits alongside the technical one: indev is a bootstrapped, employee-less, boss-less "holacracy" of six partners that survives on client contracts, and Williams has been explicitly pushing the studio to build owned products so it isn't perpetually dependent on the next deal. Terminal Graph, and its blueprint-sharing feature in particular, is his bet at doing that — while trying hard not to let user feedback pull it into becoming an unfocused "everything app." ## 📰 Newsletter Ever wished your fifteen open terminal windows could just... talk to each other? Caidan Williams — partner at the Internet Development Studio and self-described "Linux nerd" — built Terminal Graph, a canvas-style dev environment where terminals, browsers, editors, and notes sit as nodes you can wire together like Unix pipes, minus the one-line-of-text limitation. Grep your dev server's logs straight into a browser node's URL bar, or pipe a `git diff` into an AI assistant node to draft your commit message — all without leaving the canvas. Built solo in two weeks, now in public beta with Sparkle auto-updates, Terminal Graph's "blueprints" feature lets teams package and share entire workflows (think: release checklists or security audits) as a single importable, runnable file instead of a doc nobody opens. Williams's own path here — Minecraft modding at 13, ~500 job applications during a self-imposed gap-year deadline, and a hard-won QA-to-partner career arc — is a good listen for anyone who thinks they need a CS degree or a "genius" streak to break in. Give it a listen, and if you're the type who keeps twelve tabs and eight terminals open at once, go poke around kaidan.dev. ## ✅ Action Items #### DevRel - Developer advocacy: Williams's own public-beta narrative (built for himself, shipped a private-then-public beta) is a reusable case study for "dogfood-first" advocacy talks/demos. - Developer experience: blueprint export/import (JSON) is worth studying as a low-friction onboarding/sharing pattern for any devtool with configurable workspaces. - Community management: the "conflicting feedback, filter to primitives" approach is a concrete talking point for any community-facing roadmap-prioritization discussion. #### OSPO - Not applicable — no open-source governance, licensing, or compliance topics surfaced in this source (Server Mono font contribution is mentioned only in passing as a personal anecdote). #### Community - Contributors: Williams's own on-ramp (meetup attendance → desk rental → work trial → partner) is a usable template for "how we actually bring people into a small studio" community-building content. #### WordPress - Not applicable — this source contains no WordPress-specific content (Core, Performance, AI, Mobile, Playground, Community, Training, Marketing, Support, Design, Documentation, Photos, TV, Polyglots, Accessibility, Meta, CLI, Hosting, Tide, Openverse, Themes, Plugins). #### The WPCC - Not applicable — no WPCC programs, projects, or funding topics discussed in this source. ### FAIR - Not applicable — no FAIR technical independence, policy, or governance-artifact topics discussed in this source. ## 🧪 Hypotheses 1. Developers who currently juggle many terminal/browser/editor windows will show measurably faster task-switching or lower reported cognitive load when using a node-graph workspace like Terminal Graph versus a traditional tiled/tabbed setup. 2. The "blueprint" sharing mechanism reduces onboarding time for team-standard workflows (e.g., release processes) compared to text/wiki documentation of the same process. 3. Visual data-flow tools (piping stdout between arbitrary node types) lower the barrier to building small personal automations for non-expert scripters compared to writing equivalent shell pipelines. 4. Holacratic, partner-only studios (no employees, equal power) produce different product-prioritization outcomes than conventionally-managed studios when a single member champions a self-initiated product. 5. Career persistence (measured in application volume) is a stronger predictor of breaking into a self-taught tech career than credential possession (e.g., a CS degree), at least in the pre-2022 hiring market Williams describes. ### 📊 Methodology - H1/H3: A/B usability study — matched task list (e.g., "run dev server, check logs, verify in browser, open a related file") completed by developers in Terminal Graph vs. their existing terminal+editor+browser setup; measure time-to-completion, window/context switches, and a post-task cognitive-load survey (e.g., NASA-TLX). - H2: Field study with 2-3 teams — introduce a blueprint-packaged workflow to one team and a documentation-only version of the same workflow to a matched team; measure time-to-first-successful-run and error rate. - H4: Comparative case study across several bootstrapped software studios with differing governance models (holacracy vs. traditional management), tracking how self-initiated product ideas move from prototype to funded internal project. - H5: Would require a much larger, non-anecdotal sample (e.g., survey of self-taught engineers) correlating application volume, credential status, and time-to-first-offer — this single transcript is anecdote, not evidence. ### ❓ Questions - What happens to Terminal Graph's node-graph model at scale — does a canvas with 30+ active nodes remain navigable, or does it need its own zoom/grouping/search affordances? - How does Terminal Graph handle secrets/credentials flowing through piped connections between nodes (e.g., a webhook node receiving an API payload)? - What's the actual adoption curve for "blueprints" once they're marketed as the core team-sharing feature, versus their currently "underutilized" status? - Does indev's holacracy model change how Terminal Graph's roadmap gets funded internally (partner time allocation) compared to a company with a formal PM/eng-manager hierarchy? ### 🔮 Future Research - Longitudinal study of Terminal Graph users' created blueprint libraries once the sharability features mature, to see what workflow categories (release, security, onboarding, etc.) actually get standardized this way in practice. - Comparative UX research on canvas-based dev environments generally (Terminal Graph vs. other "terminal on infinite canvas" tools referenced but unnamed) to isolate whether the data-flow/piping feature specifically drives retention. ### 💡 Implications - Practice: teams could reduce "workflow tribal knowledge" loss (a departing engineer's undocumented release steps) by exporting the steps as a shareable blueprint instead of relying on institutional memory. - Security: any tool that pipes command output (including logs, diffs, or webhook payloads) between nodes needs a clear story on secret redaction/scoping before teams adopt it for anything sensitive — not addressed in this source. - Funding/business models: the "bootstrapped studio building an owned product to escape client-work dependency" pattern is a recognizable and repeatable small-agency strategy, worth a dedicated case-study writeup. ### 🧠 Learning Styles Assessment - Reading level estimate: conversational spoken-register transcript; approximate Flesch-Kincaid grade level 8-9 (short-to-medium sentences, frequent filler words, low jargon density outside of specific dev-tool nouns). #### 👀 Visual learners - Present: none in the transcript itself (audio/video source, no diagrams). - Improve: a simple node-graph diagram of Terminal Graph's example pipeline (dev server → grep → browser URL) would clarify the core mechanic far faster than prose description. #### 🔊 Aural learners - Present: the source is itself a podcast/interview — well suited to aural learners as-is. - Improve: a short (2-3 min) audio pull-quote of just the "data flow is the most unique aspect" segment could serve as a standalone teaser. #### 🗣️ Verbal learners - Present: strong use of analogy throughout ("like Figma," "Sim bars," "three-panel coding apps"). - Improve: a short glossary of terms used loosely in speech (holacracy, blueprint, node, webhook node) would help verbal learners anchor definitions. #### 🧩 Kinesthetic learners - Present: none — no hands-on exercise accompanies the interview. - Improve: a "build your first blueprint in 10 minutes" companion walkthrough would suit this audience. #### 🧠 Logical learners - Present: the graph-theory framing (nodes/connections) is inherently logical/structural. - Improve: a decision table mapping "workflow need → which node type to use" would help logical learners self-serve. #### 🧑‍🤝‍🧑 Social learners - Present: the interview format itself, plus Williams's account of networking his way into indev via meetups. - Improve: a linked community/Discord prompt for beta users to swap blueprints would extend the social angle. #### 🧘‍♀️ Solitary learners - Present: Williams's own account of solo late-night/weekend building is a relatable solitary-builder narrative. - Improve: a reflective prompt ("what's the one repetitive dev-workflow you'd blueprint first?") would suit self-paced processing. #### 🌿 Naturalistic learners - Present: none directly — no sustainability/ecosystem framing in this source. - Improve: not a natural fit for this content; skip rather than force a tie-in. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: N/A — this note is derived from an audio/video source, not itself a web artifact with markup to assess. - Improve: if Terminal Graph's own UI is a visual canvas of nodes, its accessibility story (screen-reader traversal of a spatial graph) is an open question not addressed in this interview and worth a dedicated audit. #### Keyboard navigation - Present: not discussed. - Improve: unknown whether Terminal Graph's canvas supports full keyboard-only navigation between nodes; flag for follow-up. #### Contrast and readability - Present: not assessable from a transcript. #### Text resizing and reflow - Present: not assessable from a transcript. #### Media and captions - Present: this note is generated from a transcript, implying captions/transcript exist for the source video — good baseline access. - Improve: verify the published video includes synchronized captions (not just an offline transcript) and a downloadable transcript link on the video page. #### Forms and interactions - Present: not applicable to this source. #### Standards reference - Given the lack of any visual/interactive artifact in this source, WCAG 2.2 AA mapping is not meaningfully assessable here; it would apply to a future review of the Terminal Graph app UI itself, not this podcast episode. ### 🌍 DEIB Assessment #### Cultural breadth - Present: single-region (US, Colorado/Boston/Seattle), single-perspective narrative. - Improve: the episode would benefit from a companion segment featuring builders from other regions/backgrounds working on similar spatial-dev-tool ideas. #### Inclusive language - Present: plain, jargon-explained-in-context language throughout ("holacracy" is defined inline when introduced). - Improve: a couple of dev-tool nouns (Sparkle, AppCast) are used without definition; a glossary would help non-specialist listeners. #### Neurodiversity support - Present: Williams openly discusses his ADHD and how it shapes both his working style and his hopes for Terminal Graph's real-world automation use case — a notable, unprompted piece of representation. - Improve: none needed; this is a strength of the source as-is. #### Representation - Present: Williams's origin story (low-income family, oldest of five, no college funding, self-taught path) broadens the "how people get into tech" narrative beyond the conventional CS-degree pipeline. - Improve: none — this is already a valuable representation data point for DevRel/community narrative work. #### Psychological safety - Present: respectful, low-pressure interview tone throughout; no adversarial framing. - Improve: none needed. ### ✅ Logical Validity #### Strong reasoning - Causal/inductive: Williams's claim that data-flow/piping is Terminal Graph's key differentiator is backed by a stated method (his own prior-art search found "terminals on canvas" tools but none with data piping) — a reasonably strong inductive claim given the explicit methodology disclosed, though it rests on one person's search rather than a systematic market survey. - Analogical: the Unix-pipes-made-visual analogy is used consistently and clarifies the mental model well — a strong explanatory analogy, not just a rhetorical flourish. #### Fallacies - Hasty generalization risk (not a hard fallacy, but a caution): the claim "persistence matters more than intelligence" is drawn from a single case (his own ~500-application job search) and, while explicitly caveated by Williams himself ("I'm not going to say whether or not I'm intelligent"), a listener could over-generalize it into universal career advice without controlling for market conditions, timing, or luck. #### Tone of voice - Warm, reflective, and unguarded — Williams narrates failures (burnout, stalled promotion, layoff) without defensiveness, and the hosts respond with validating, non-interrogative follow-ups throughout. ### 🛡️ DARVO Analysis - Not applicable. This is a cooperative, friendly interview with no accusation, conflict, or dispute structure present — there is no deny/attack/reverse-victim-offender dynamic to analyze. The closest adjacent moment (Williams describing friction with a former CEO over hiring/workload) is reported briefly, one-sidedly, and without any counter-party present to evaluate; it is not framed as a DARVO exchange. ## 🎯 Conclusion Terminal Graph is a solo-built, personally-validated bet that the real bottleneck in modern dev workflows isn't which AI model sits in your sidebar but how scattered your workspace is — and that Unix-style piping, made visual and spatial, is a genuinely underexplored answer. Its near-term test is whether "blueprints" can turn that personal tool into a team-sharing product without indev, a bootstrapped six-partner holacracy, having to compromise the primitives-over-features discipline that's kept it from becoming an everything-app. Practical next step for readers: if you maintain a repetitive multi-tool workflow (release process, environment setup, audit checklist), Terminal Graph's blueprint model is worth a trial specifically for that use case rather than as a wholesale terminal replacement. ## 🔄 Refactor Appendix — Building Terminal Graph, a Spatial Development Environment, with Caidan Williams ### 📚 Literature Atoms (H3) #### Data flow between nodes is Terminal Graph's key differentiator > [!quote] > "I do truly think that the data flow is the most unique aspect that separates itself from others." **Context & use**: - Mid-interview, in response to "what sets it apart from other apps." - This is the single clearest positioning claim in the whole episode — the thing to cite if summarizing Terminal Graph in one sentence. **Tags**: #xref  #### Build primitives, not an everything app, when feedback conflicts > [!quote] > "I'm trying to make sure I'm not building like an everything app... The way that I'm trying to focus on building this is I want to build the primitives such that other people can build out what they need with it." **Context & use**: - Said while describing how he filters contradictory beta-user feedback. - Directly actionable design-philosophy statement, reusable for any product-prioritization discussion. **Tags**: #xref #aphorisms  #### Blueprints let teams share whole workflows as one importable file > [!quote] > "You download terminal graph. You import it and just click run and it just does the thing... there wouldn't be the need to like have that kind of like friction of teaching somebody this process." **Context & use**: - Introduced as the "next" focus area after core node/connection functionality. - Ties directly to Hypothesis 2 above (blueprint vs. documentation onboarding speed). **Tags**: #xref #articleseed  ### 🧠 Permanent Candidates (H4) #### Primitive-first design absorbs conflicting user feedback without scope creep **Claim** (one sentence, Courtney's voice): When user feedback conflicts, building composable primitives instead of point features lets users resolve the conflict themselves by combining primitives their own way, rather than the product having to pick a winner. **Evidence pointer**: [[#Build primitives, not an everything app, when feedback conflicts]] **Scope & conditions**: Holds for tools with a genuine underlying compositional model (graphs, pipes, blocks); breaks down for products where the conflicting requests are about core information architecture or business logic that can't be decomposed into neutral primitives. **Links** (≥1 with annotation): - [[Blueprints-as-workflow-packaging]] — because applies-in team-onboarding contexts  ### ✏️ Fleeting Queue - [F1] Investigate whether Terminal Graph's canvas UI has a documented accessibility/keyboard-navigation story — https://kaidan.dev #xref - [F2] Watch for Terminal Graph's v1.0/GA release and blueprint-marketplace maturity as a follow-up story #articleseed ### → Things 3 (max 2 actions) - [ ] Check kaidan.dev for Terminal Graph's current beta status and blueprint feature docs — background research #things --- ## Full Transcript [00:00] Welcome to the Overcommitted Podcast, [00:02] your weekly dose of real engineering [00:04] conversations. [music] I'm your host [00:05] this week, Erica, and I'm joined by [00:07] >> Hey, I'm Britain. [00:09] We met while working on a team at GitHub [00:11] and quickly realized we are obsessed [00:13] with getting better at what we do. So, [00:15] we decided to start this podcast to [00:17] share what we've learned. We'll be [00:18] talking about everything from leveling [00:20] up your technical skills to navigating [00:22] your professional development, all with [00:24] the goal of creating a community where [00:26] engineers can learn and connect. Today [00:28] on Overcommitted, we are joined by Kaden [00:30] Williams, partner at Internet [00:32] Development Studio Company and the [00:34] creator of Terminal Graph. Welcome, [00:36] Kayen. [00:37] >> Hi. Thanks. [00:39] >> To kick us off, we'll ask you what we [00:41] ask everyone. What's one thing you're [00:44] currently building or obsessed with [00:46] learning right now? [00:47] >> It has to be Terminal Graph. I've been [00:49] working on it for a couple months now [00:51] and I'm spending weekends and nights uh [00:54] just getting it out there, working on [00:55] improving it every day and doing a lot [00:58] of like experimentation. This is a tool [01:02] that I don't think I've ever really seen [01:03] anyone build before. So the prior art [01:06] for it is very slim. And so it's been an [01:09] incredible engineering challenge and [01:10] very fun to flex the creative process [01:13] and like play and experiment and see [01:17] what feels good and like even just [01:20] trying to figure out the direction of [01:22] where to take some of the features. [01:24] >> Very cool. For listeners who may not be [01:26] familiar familiar with it, could you [01:28] describe terminal graph and what it [01:31] does? Yeah. So my elevator pitch is it [01:34] is the next generation of development [01:36] environments is how I like to think [01:38] about it. Essentially uh the think about [01:41] it is starting from the problem, right? [01:44] Every developer has uh you know their [01:46] own workflow, their own ways of [01:48] developing different tools, different [01:50] apps, whatnot. But the underlying root [01:53] cause of it all is that it's all [01:56] scattered. You have, you know, 10 apps [01:58] open and 30 browser tabs. you have [02:01] multiple workspaces and various, you [02:03] know, your desktop's just cluttered. [02:06] I thought, wouldn't it be really cool if [02:08] you could just take all of those and put [02:10] it on a giant canvas kind of like Figma. [02:13] Have each window there, you have [02:15] terminals, you have browsers, you have [02:17] notes, you have file editors backed by [02:19] VS Code, you have tons of different ways [02:22] to do development on a single canvas. [02:24] And to take it a step further to be able [02:27] to connect them and pipe data between [02:30] each of the nodes, you can connect a [02:32] terminal standard out to a utility node [02:35] that GPS for, you know, like a a local [02:39] dev link and then pipe that into a [02:41] browser node to update the URL so that [02:43] you know every time you run your dev [02:45] server, it automatically opens this uh [02:47] browser node. I was working on [02:49] redesigning the uh terminal graph [02:51] website and it's just been such a [02:53] pleasure to do web development in this. [02:55] I have claude open in one window. I have [02:57] lazy git in another. I have neoim in [03:00] another node. And then I have the dev [03:02] server in another one. And then I have [03:04] the full screen desktop browser node and [03:06] then a mobile version of the uh browser [03:08] node there. And it's just all in one [03:10] little view. And honestly, I love it. I [03:13] I built this tool for myself as a bit of [03:15] an experiment to kind of see if this was [03:18] even really possible. And I started to [03:20] realize that tons of other people are [03:22] very excited about it and also get a lot [03:24] of joy and utility out of using a tool [03:27] this kind of way too. [03:28] >> Yeah, for sure. You know, we talk a lot [03:30] about context these days and like as it [03:33] relates to agents and giving your agents [03:35] context, but ultimately it comes down to [03:38] can you keep everything in your head at [03:39] once and how are you managing all the [03:42] various windows and terminals. So having [03:45] that so visually clear and then also [03:47] having the connection between all of the [03:51] all of the things talking to each other [03:53] does sound really valuable. [03:54] >> Yeah. So, you said you you're basically [03:58] building this for yourself, but you're [04:00] also releasing it. Private beta is [04:03] happening this month or is out now. [04:06] >> I built the first version of it in 2 [04:08] weeks. After the two weeks, I collected [04:10] a bunch of emails and I did a private [04:12] beta just to iron out some of the bugs [04:14] and then I realized I didn't want to [04:17] manage emails and, you know, send out [04:19] updates that way. So, I was like, uh, [04:21] what the heck, you know, I'll make a [04:22] public beta. Um, and so built out a [04:25] website, added Sparkle and AppCast [04:27] updates and all the stuff. Um, and after [04:31] that it's been in public beta since [04:33] then. Uh, I do have plans to release it [04:36] as like um, a V1 eventually, but there's [04:40] still a lot of uh, kinks to iron out [04:42] first. [04:43] >> Cool. So, what took you from idea to [04:46] execution? What was the thing that took [04:48] you from, hey, this would be really cool [04:50] to build to actually I'm going to sit [04:52] down and do this? [04:53] >> Yeah. Oh, what a great question. I think [04:56] it's a it's a combination of a few [04:59] things. It was a little bit just driven [05:01] by my internal desire to build. I just I [05:03] love building things. I'm a bit of a [05:05] Linux nerd. So, this is like backed by [05:07] Unix pipe files. And I was like, [05:09] wouldn't it be cool if you could like [05:10] connect two terminals and like pipe data [05:13] between them? And I was like, well, you [05:15] know, like, oh, you can just do that [05:16] with Unix pipes on command line. Like, [05:18] that's not very intriguing, but what if, [05:21] you know, you could connect multiple [05:22] terminals to one output, right? Doing [05:25] parallel processing and such, which is I [05:28] I've seen people do it online with [05:30] various CLI tools, but is not intuitive. [05:32] It's not easy to reason about, and [05:34] there's no visualization. So, making [05:37] bigger connections is really tricky with [05:40] just a line of text. So, that was a big [05:42] inspiration. It's like, is this even [05:44] possible? Like, is this something that [05:47] can be done? And once I built out that [05:50] initial iteration and kind of proved [05:52] that it works, I got really excited and [05:54] I was like, okay, cool. I have two [05:55] terminals connected and are sending data [05:57] to each other. Like, awesome. Uh, what [06:00] else can I do with this? And so, I [06:01] added, you know, a browser node. I add a [06:03] WebKit um Safari WebKit uh web view [06:06] which is super nice and allows me to [06:09] like I kind of have to inject some [06:11] custom JavaScript to like get some data [06:13] in there and pipe it out and whatnot but [06:17] added that added you know file notes uh [06:20] added a bunch of utility nodes to like [06:22] help manage things like switches, gates, [06:24] delays, collections, you know a bunch of [06:26] other stuff to help with the the data [06:29] flow. And partly the other big [06:31] inspiration was that uh indev we've been [06:34] doing a lot of client work for a long [06:35] time and as one of the partners I've [06:38] been wanting to push us towards doing [06:40] more product work so that we're not so [06:42] heavily rellyant on maintaining like [06:45] continuously getting contracts to to [06:47] keep our studio alive. And so I'm hoping [06:51] that I can turn this into a successful [06:54] product that not only developers love [06:57] and benefit hugely from, but can also [07:00] help our studio survive cuz we're not [07:02] venture-backed, we're just a small team [07:04] of folks who are keeping the shop open [07:08] with the hard work we do. So those are [07:10] the big inspirations and kind of why I [07:14] went down this direction. Was there [07:15] anything in particular that drew you to [07:17] like yes, this is the project to to get [07:19] that product work done or is it just [07:22] like you started building it and you're [07:23] like wow this is very useful for me. [07:25] >> Yeah, I think it's just uh it came from [07:28] a desire to have a better workspace uh [07:30] for myself. I I've been living in the [07:33] terminal for the better part of a decade [07:35] now. Um I use Neom, I use Lazy, I use [07:38] all the CLI tools, you know, FuzzFinder, [07:40] like name it, I've probably tried it. [07:42] And so I love it. I I don't have [07:44] anything against GUIs, but I kept seeing [07:46] all of these three panel coding apps, [07:49] right? Like conductor and codeex and [07:51] it's like left side is like the [07:53] workspace or like some list of things. [07:56] You have the middle is like a chat app [07:57] and then on the right it's like kit or [07:59] something and that's fine. I think [08:00] they're really approachable and they [08:02] definitely have their target audience. [08:04] But for me personally, having the [08:06] flexibility of a terminal and being able [08:08] to modify it so much, I really wanted to [08:12] take it further. I've been used to I've [08:14] used pretty much every terminal emulator [08:15] on the market. You know, iTerm, Ghosty, [08:18] Kitty, Elacrity, a ton of other ones on [08:20] Linux and they all kind of do the same [08:23] thing. Fundamentally, they're a window [08:26] with a split tree. And I wanted to try [08:28] the experiment of like, well, what if I [08:30] could see every terminal I've ever had [08:33] open like on one canvas? And it was just [08:36] kind of that curiosity that led me down [08:39] the start of the path. And once I got [08:42] the initial version, it kind of felt [08:45] like I'd struck gold. I was like, "Whoa, [08:46] there's something here." You know, I [08:48] feel like this is exciting. Like I'm [08:50] excited about it, which is a really good [08:53] signal for myself. And then I started [08:55] showing people and I were like, "Wo, [08:56] this is really cool." So I just felt [08:58] like I had to pursue it. Yeah, I I can [09:00] definitely identify with that experience [09:02] where when it's in your head, it's kind [09:04] of this like amorphous thing and then [09:07] once you get it down on paper, it really [09:11] builds steam on itself of getting [09:13] excited about it and then really wanting [09:15] to work on it, having trouble putting it [09:17] down. Um, definitely can be a good [09:21] feedback loop for yourself when you're [09:23] working on something that you really [09:25] enjoy. [09:25] >> Yeah, definitely agree. Were there any [09:28] points where like the project [09:30] significantly changed? Like any of that [09:33] feedback that you got? Did it really [09:35] like change your vision at all? Or did [09:37] you pretty much stay on on one path? [09:40] >> Yeah. Um, that's such a good question. [09:44] I've gotten so much feedback and I think [09:46] every founder, everybody that builds a [09:50] product experiences this to some degree. [09:52] I've gotten every opinion, every [09:54] differing op I've had so many [09:55] conflicting opinions about like, oh, it [09:57] should do this and like, oh, but it [09:59] should do that. And it's like trying to [10:00] find the balance of like what to [10:03] actually build and what to like filter [10:05] out. Like it's all good signal. Every [10:07] every bit of feedback is all good to [10:10] take into account, but for myself, I'm [10:14] trying to make sure I'm not building [10:15] like an everything app. I don't want [10:17] this to like have every feature possible [10:20] under the sun. I the way that I'm trying [10:22] to focus on building this is I want to [10:26] build the primitives such that other [10:29] people can build out what they need with [10:31] it. And so that's kind of where I've [10:33] built out the like the whole start of it [10:35] is like nodes and connections, right? [10:38] I'm I'm a big graph theory nerd as well. [10:40] So I took a lot of those ideas too and [10:42] I've been building graph-based [10:44] applications for a long time like [10:46] mathematical graphs, not the visual [10:47] graphs. And so that was a big [10:50] inspiration. I love building graphs, so [10:51] it felt very natural. One of one of the [10:54] features that I think is still a little [10:57] underutilized for users that I think is [11:00] incredibly powerful is the concept of [11:02] blueprints. So you can select any set of [11:06] nodes and create a blueprint from it and [11:08] it will capture all the details such as [11:11] like the startup commands for a [11:12] terminal, the URL for a browser, you [11:15] know, notes, the file path for editor, [11:17] all of that and will allow you to [11:19] instantiate copies of that blueprint and [11:22] you can take it across projects, you can [11:24] take it across workspaces, you can [11:26] export it as just a JSON file and send [11:28] it to somebody and they can import it [11:30] and create the exact same workflow. And [11:32] so this is what I'm focusing on next is [11:35] kind of building out this sharability [11:37] aspect and making it so that my goal is [11:40] to have teams be able to have common [11:43] development workflows like release [11:44] workflows or security audits or anything [11:47] that's like kind of tedious to do that [11:49] you'd have to have a documentation page [11:51] written up for about anyway. You just [11:53] have a blueprint. You download terminal [11:55] graph. You import it and just click run [11:57] and it just does the thing right. It's [11:59] very visual. It's very easy. You can [12:00] have notes there alongside every step of [12:03] the process, but there wouldn't be the [12:05] need to like have that kind of like [12:07] friction of teaching somebody this [12:09] process. It would be hopefully a bit [12:11] more intuitive [12:13] and then also keeping those blueprints [12:15] up to date across multiple machines and [12:17] across the whole team. [12:18] >> Yeah, I definitely think that's really [12:20] relatable trying to take feedback and [12:23] apply it in any situation. [12:27] could be customers, it could be product, [12:29] it could be like any number of [12:31] stakeholders and everyone has an opinion [12:33] and yeah at the end of the day you need [12:35] to deliver something and you can't make [12:38] everyone happy. So um you have to have [12:41] that judgment. Were you the sole [12:42] developer on this? [12:44] >> Yeah. So I guess maybe it'll help to [12:46] explain the structure of our company a [12:48] little bit. Um we're a hocracy. Uh, and [12:51] for anybody that's not familiar with [12:52] hocriscy, it essentially means that you [12:55] are a team of equal power and [12:59] responsibility. So there's uh six of us [13:04] currently I believe uh and we all are [13:06] partner levels. We have no employees, we [13:08] have no bosses and we all have this [13:10] freedom to do whatever we want that we [13:13] think is best for the company. And so [13:16] with that power, as I said before, I've [13:18] been wanting to build products. So [13:19] building this has been kind of that that [13:23] uh desire to make some make a change for [13:26] our company. And so I've been the solo [13:29] developer on it for the uh current time [13:33] of his life. It's a couple months now. [13:35] And um I'm like it's getting enough [13:38] traction that I'm pulling in other team [13:40] members to help me with design and [13:42] branding. I'm getting some help to like [13:44] do some more engineering work. Um, but I [13:46] wanted to prove that this was like [13:48] actually [13:50] taking first before kind of pulling [13:52] their time [13:53] >> forward. Like having at least one other [13:55] person for a lot of decision-m that can [13:58] impact other people. [14:02] >> Yeah, totally totally agree. I've been [14:04] needing some help. some of my ideas are [14:06] maybe a little hairrained and not fully [14:09] developed of just like wouldn't be cool [14:11] if I could do this and then realizing [14:13] actually maybe that's not that useful [14:15] but [14:17] >> yeah is there anything that you feel [14:19] like you've brought into terminal graph [14:21] that you like you haven't seen in other [14:23] apps or like what is the thing that like [14:25] sets it apart from what is out there? [14:28] >> Oh my goodness, another great question. [14:31] Let me let me think about this because I [14:33] personally feel like so much of it is [14:35] unique. I think really the most unique [14:39] aspect of this is the data flow. Being [14:41] able to pipe data across different [14:44] categories of applications is what I [14:47] hopefully see a incredibly powerful [14:49] utility for the future. Being able to [14:52] run a dev server, GP the logs, grepping [14:55] for the URL and piping into a browser is [14:58] like so powerful, right? or being able [15:00] to have a template node where you can [15:03] put little curly brackets around any [15:05] name, any variable and it'll create a [15:07] new port, right? Uh, and pipe data in. [15:09] So you can say like, hey, analyze this [15:12] git diff and write a commit message as a [15:14] rudimentary example. And then you run [15:17] git, you have a run node that runs git [15:19] status or git diff, pipes that in, and [15:21] then you pipe that to like clock code. [15:23] is simple but I think shows the power of [15:28] how this can kind of scale into larger [15:30] more intricate automated systems and [15:34] I've even added like a web hook node [15:36] that allows you to you know connect to [15:39] external systems and get events that you [15:41] can pipe through into the entire system [15:44] of whatever automation you want. So I I [15:46] do truly think that the data flow is the [15:49] most unique aspect that separates itself [15:52] from others cuz I when I was building [15:54] this initially I did look from prior art [15:56] of has anybody built something similar [15:58] and what I came across is there's a [16:00] handful of other projects that do the [16:02] terminals on an infinite canvas kind of [16:05] approach but none of them do any sort of [16:07] data data flow or data piping. [16:09] >> Yeah. It it makes me think of why MCPS [16:13] are so popular and why they've taken off [16:15] so much. The parallel in my mind is a [16:17] single session, a single agent, a single [16:20] whatever is great, but when you can make [16:23] those connections and like pull in data [16:26] from other sources to help. It's how we [16:29] operate too. We don't stick in the [16:31] terminal and when we say I don't know [16:33] how to do this, we stop. You know, you [16:35] got to go find out what you what you [16:37] don't know and pull that information in. [16:40] Yeah. So, uh, you mentioned earlier [16:43] that, you know, you've been developing [16:45] for a long time, that you started when [16:47] you were really young, and clearly [16:50] you're you're passionate, you're fired [16:51] up about the work that you do. Um, so [16:56] tell us a little bit of where you [16:57] started and how how you've changed [16:59] throughout the years. maybe starting [17:01] with like what kind of got you into [17:03] programming in the first place and maybe [17:05] some some lessons you've learned over [17:07] the years that you you have top of mind [17:11] as you go through your your work [17:12] dayto-day now [17:13] >> when I was 13 unsurprisingly I was a [17:16] huge Minecraft nerd and that was like [17:18] the only thing I wanted to play so I [17:20] kind of reached my limit with it and I [17:22] was like I've played everything you [17:24] could want to do I've modded it to you [17:27] know in every way you could possibly [17:29] want and I was like I want to do more. [17:31] And so I started learning Java to create [17:35] my own mods and my own plugins. That [17:37] went on for a couple years and I made a [17:40] ton of mods. I, you know, had a lot of [17:42] community. I worked for some uh [17:45] Minecraft servers making custom plugins [17:47] and I made maybe a couple hundred which [17:49] as a teenager was great money to have. [17:52] Um definitely very underpaid for the [17:54] looking back. Um, and [17:58] after those few years, I kind of got [18:01] burnt out on Minecraft. I I done [18:02] everything. I built every mod I could [18:04] want, you know, I was just like, it's [18:05] time to move on. Um, and [18:09] I don't think I initially kept [18:10] developing at that time. I kind of went [18:12] off and did school and other things like [18:14] that, but I don't know what it was. It [18:16] just kind of like kept pulling me back [18:18] in. I kept thinking about it. I was [18:19] like, "This is, you know, that was [18:20] actually really fun. Like, I should try [18:22] to make more stuff." and not really [18:25] having an interest in like web [18:26] development or app development or any [18:28] kind of like business development stuff [18:30] at that time, I naturally gravitated [18:33] towards making video games. So, I booted [18:35] up Java. I started making 2D games and [18:39] building out tons of very simple ones, [18:42] nothing that's really that impressive. [18:43] And eventually during high school, I met [18:46] one of my best friends who was also a [18:48] developer. And I grew up in a really [18:50] small town in Colorado, uh, Dango, [18:52] Colorado. I don't know if anyone's ever [18:53] heard of it. Very tiny little cute [18:55] mountain. So, no coding. There was like [18:58] nobody knew anything about it and he was [19:00] like the only other kid that like had [19:02] experience with it and he was a much [19:03] better coder at that time than I was. [19:05] So, we kind of became best friends. He [19:07] taught me a lot and we still started [19:09] making a lot of games together and [19:11] eventually we started doing a lot of [19:12] game jams as well. So, that was the [19:15] majority of my high school and a little [19:16] bit after it was just like making games [19:18] all the time. I did a lot of I create a [19:20] lot of art too. So, I was making pixel [19:22] art. I was making like animations, you [19:24] know, other things of that sort. And I [19:27] graduate high school and uh I come from [19:29] a pretty poor family. I'm the oldest of [19:32] five boys, so there wasn't really any [19:36] money to go to college. So, I was [19:38] looking at my options like I can take [19:41] out money, student loans, and try to pay [19:44] them back. And like I maybe that would [19:46] have been a decent route, but I was also [19:48] like, you know, I have this experience, [19:50] maybe I could get a job in tech on my [19:52] own, even without a college degree. And [19:54] so I uh decided to take a gap year and [19:57] give myself a year to just try and get a [20:00] job in tech, get anything for a year [20:03] while I was working at like a a chicken [20:04] restaurant, a wing restaurant. And I [20:08] spent that year working and building my [20:11] portfolio. I was still working on like [20:13] some games that I was liking and [20:16] eventually about uh so the the gap year [20:18] I the promise I made to myself was if I [20:21] don't get a job in a year I'll bite the [20:23] bullet take the loans go to college. I [20:25] got a job eight months into that gap [20:27] year and it was just an internship at a [20:30] local tech company that surprisingly I [20:33] didn't know they existed but I was [20:35] intern for 3 months during the summer [20:37] and towards the end of it I talked to [20:38] the CTO and I was like hey I would love [20:41] to like keep working here once this [20:43] internship ends and he kind of suggested [20:45] and pushed me be like you should go to [20:47] college and I was like okay so took his [20:50] advice and like I didn't go to college I [20:52] I went for like he was like I'll give [20:55] the job, but you should also consider [20:56] going to college. So, I got the job as a [21:00] uh QA engineer, which I don't know if [21:02] that role even exists anymore, but I was [21:04] writing unit tests and a bunch of other [21:07] stuff. I eventually kind of branched out [21:08] and was doing a lot of like internal [21:10] tools because the the company at the [21:12] time was Git Prime, uh, which was [21:14] acquired by Pluralsight like a couple [21:16] years later, so they're not really [21:18] around anymore, but they were a Git [21:20] based company, so analyzing like Git [21:22] metrics and stuff like that. So, I was [21:24] building out a bunch of internal tools [21:25] to like help mock Git APIs for like [21:28] GitHub and Bitbucket because we were [21:30] hitting rate limits with all their [21:32] testing and other stuff. And um like I [21:34] built a little tool to basically [21:36] recreate git repos from scratch like [21:39] time travel back like creating commits [21:41] at any point in time, stuff like that. A [21:42] ton of fun. I learned so much. Like it [21:45] was incredible that I had that [21:47] opportunity because in just the one year [21:49] of working at that job, I learned more [21:52] than I had my entire time on my own. It [21:55] was so valuable for me. And so [22:00] that was an incredible job. I learned a [22:02] ton. And then the company got acquired [22:04] by Pluralsight. I worked there for a few [22:06] months, but they were too big. You know, [22:09] they were like too impersonal. I was [22:11] still stuck as like a low-level QA [22:14] engineer. I was supposed to get a [22:15] promotion right before the acquisition [22:17] and then they acquired us and then that [22:20] never happened and they're like, "Oh, [22:21] you have to be here a year before you [22:22] can move." And I was like, "I don't want [22:23] to do that." So, uh, I was looking for [22:26] jobs and I eventually found a role at [22:29] Overjet in Boston, which was a startup [22:32] that was working out of the Harvard [22:34] Innovation Lab, creating, this was back [22:36] in like 2020, so even before like the [22:39] big LLM started hitting the consumer [22:42] market. We were creating computer vision [22:44] models to analyze dental X-rays uh, to [22:47] look for early signs like gum disease [22:49] and tooth decay. And I don't have a PhD [22:52] in any of that. [clears throat] So I was [22:53] not I was not doing any of the like [22:55] actual uh generative model stuff, but I [22:58] love data and I love Linux and I love [23:01] processing. So I actually this is kind [23:03] of where I started to really fall in [23:05] love with this concept of like piping um [23:08] and data transformation is uh I had [23:11] built out a very custom data pipeline to [23:15] process these images from all the [23:17] various sources. I can't talk about the [23:19] sources, but it would be, you know, we'd [23:21] get like an FTCP server. We would get [23:23] like a random link to this like third [23:25] party vendor, you know, that would host [23:27] all these images and we would have to [23:29] get it into our system. Uh, and it would [23:31] land into like a Google bucket and I had [23:34] some cloud functions that for each [23:36] notification on that bucket would load [23:38] it up and process it like multiple steps [23:41] along the way. It would start with um [23:43] okay, let's go through and convert every [23:46] image to JPEG, right? That's what we [23:48] were standardizing on. And it was really [23:50] fun because there was tons and tons of [23:53] different formats that I did not know [23:55] existed, including uh it's been a [23:58] minute, so I may get this wrong, but it [24:00] was [24:01] TIFF files, I think, uh which are it was [24:05] a well, it was a specific type of TIFF [24:07] file. was like an unsigned six integer [24:10] encoded TIFF file which was like I was [24:12] trying to find where these came from and [24:14] they're incredibly old X-ray machines [24:16] like some of the first ever digital [24:18] X-ray machines and I was using pillow [24:21] the uh Python library to convert all of [24:23] them and nothing uh like like would not [24:26] read this it was like what's going on so [24:28] I went this was the preAI days so I was [24:30] like what is this format like no I [24:32] couldn't I could barely find any [24:34] information I think after like 3 days of [24:35] frantic searching I eventually land on [24:38] this super obscure forum with somebody [24:40] being like, "Oh yeah, here's like some [24:41] information about it and blah blah blah [24:43] and like here's a numpy function that [24:46] will allow you to transform it to JPEG." [24:48] And so I copied that and was able to [24:52] basically just like cut off half thetes [24:54] and then like strip the header metadata [24:56] and stuff like that. And then you know [24:59] that was like the first part of the [25:00] pipeline I built out all this and then [25:02] it would go down to like uh removing [25:04] patient health information. We would [25:06] like send it to Google to like analyze [25:09] text and we just black it out. And [25:11] anyways, so that's kind of where I fell [25:13] in love with data pipeline. It was [25:14] incredible job. Eventually, I got burnt [25:18] out because the pandemic hit and I was [25:20] working like 80our weeks and I was [25:22] underpaid uh because I was so young and [25:24] I'd been asking for like 6 months like, [25:26] "Hey, can you please hire more people? I [25:28] need help with this work." Um, and [25:31] unfortunately the CEO and I had [25:32] disagreements. So I started looking for [25:34] a new job and I eventually ended up [25:36] landing at another company. Uh was there [25:39] for a few years. I was at um uh Domino [25:41] Data Labs which was uh like [25:45] uh I won't go into it. It's a [25:46] complicated job. But um I [25:51] learned a lot there. I uh realized that [25:55] actually I didn't need to be in Boston [25:56] anymore because that job was remote. So [25:58] that's how I ended up moving out to [25:59] Seattle. I actually had never visited [26:01] Seattle before moving. I kind of was [26:03] just like, I have a friend out there. [26:04] One of my best friends that I met in [26:05] high school was living out here. And so [26:07] I was like, yeah, why not? And I just [26:09] sold everything I had because I looked [26:11] into shipping it. And it was going to be [26:14] more expensive to ship from Boston to [26:16] Seattle than it would to just actually [26:18] buy it all again cuz it was I was a [26:20] young kid with not very expensive [26:22] things. So I sold or gave away almost [26:25] everything I had. Uh, and I hopped on a [26:27] plane with a duffel bag and like a [26:29] backpack, landed in Seattle and found an [26:32] crashed my friend's couch for two weeks [26:34] and found an apartment and kind of [26:35] rebuilt it up again. Um, and I've been [26:38] in Seattle for about six years now. Um, [26:42] roughly, I think, well, maybe like five, [26:44] something like that. Um, and I was with [26:47] that company for a while until, uh, I [26:50] think it was like 2024 layoffs were [26:52] hitting everybody. Our company got hit. [26:54] I was laid off. I had some severance and [26:57] I decided to take a hiatus for about 6 [27:00] months. I had been working hard and kind [27:02] of just really needed a break and wanted [27:04] to explore some of my own projects and [27:06] do some of my own things. So did that [27:09] for a while and then eventually got [27:12] another job working for actually another [27:15] medical tech companies surprisingly uh [27:17] which was doing MRI images or computer [27:20] vision on MRI images as well. So that [27:22] was a lot of fun. And I worked there for [27:25] almost two years. And I [27:29] kind of realized as I went into that [27:31] job, I was like, I don't really have a [27:32] great professional network. I should go [27:34] socialize and mingle and meet people. [27:36] And so I started just going to a bunch [27:38] of tech events here in Seattle. And [27:40] eventually that ended up leading me to [27:43] uh the internet development studio. I [27:44] went to the distributed web meetup that [27:46] we host every couple months. And I go [27:49] in, you know, I don't know anybody, but [27:51] I sit down, I watch some of the talks, [27:53] and I get up and I'm like, "Okay, cool. [27:54] Time to mingle." And I walk around and [27:56] the first person that I end up talking [27:58] to and meeting was uh Jimmy, Jimmy Lee, [28:00] the guy who started the studio. And so [28:03] we hit it off immediately. We're just [28:05] both very passionate about the web, [28:07] passionate about building. And so he [28:09] invited me to come hang out at the [28:11] studio. And so I started coming back. [28:13] Eventually, I start renting a desk [28:14] there. And then about six to eight [28:17] months into renting a desk there, the [28:19] studio was looking to hire more [28:21] partners. And so they asked me if I [28:23] would be interested. And so they uh, you [28:25] know, I said yes. That's it was like so [28:28] cool, very exciting. And so they put me [28:31] through a one-mon work trial. Uh, and [28:34] they killed it. They loved it. Uh, I I [28:36] did great work. I worked on a lot of our [28:39] open source projects. I helped further [28:42] develop out one of our fonts, Server [28:44] Mono. um because it was missing a [28:45] handful of glyphs. I had never made or [28:47] worked with fonts before, but I I'm an [28:49] autodidact. I just love learning and [28:51] love building. So, I got some font [28:53] software and I like started designing [28:55] and trying to match it to like the the [28:58] feel of the text and like was putting it [28:59] out there, getting community feedback. [29:01] Um and so that was a lot of what I did [29:03] during my work trial for the first [29:04] month. But they loved me. so uh hired me [29:07] on full-time and I've been with the [29:09] studio since and it's about um been [29:12] about over a year now that I've been [29:14] with the studio as a partner. [29:15] >> Thank you so much for sharing that whole [29:17] story. I can you know there's there's so [29:20] many things that like I got from from [29:24] your story and and the way that you tell [29:27] it. I can I can tell your agency in it [29:30] as well as all these situations that [29:33] kind of came up and and what you got [29:35] from each situation too. Uh it's a very [29:38] unique path. I mean yeah and very cool [29:42] to hear how you know that that foot in [29:45] the door moment uh with your first job [29:49] like really got you into the [29:50] professional side and was really a [29:52] launching pad. But really each step [29:54] along the way, you kind of took [29:56] something from each each job, each [29:58] situation that has really gotten you to [30:01] this point now. Whether that's the [30:04] technology you were working with or sort [30:06] of the people situations, [30:08] you know, and didn't let any of these [30:11] sort of potential setbacks get you down [30:13] with, you know, several situations you [30:15] mentioned vying for a promotion and [30:17] instead of waiting around, you moved on [30:19] to the next thing. you looked at what [30:22] else was out there, what you could what [30:24] you could do. And yeah, it's very cool [30:26] hearing hearing you sort of move through [30:28] all those moments and stay focused on on [30:32] what you're still so passionate about. [30:34] Even you even mentioned a couple periods [30:36] of burnout and then you kind of [30:38] >> ramped back up again and got back into [30:40] it. [30:41] >> Yep. Yeah. Well, thank you. Yeah, it's [30:43] it's been a a long journey. Um, and I [30:47] think the the one piece of advice I like [30:48] to give when I tell this story is a lot [30:51] of people will say like, "Oh, you're so [30:53] smart. Like, oh, you like must be so [30:55] intelligent that you're able to do this [30:56] and like that you taught yourself [30:58] coding." And I'm not going to say [31:01] whether or not I'm intelligent. I don't [31:03] think that that's super relevant. But [31:05] what I think I would attribute to that [31:07] more is the persistence. I have this [31:11] passion and this dream and regardless of [31:14] how many times I failed like getting [31:16] that first job, getting that first [31:18] internship, I must have applied to like [31:20] 500 different companies. And this was [31:22] even back when like the job market was [31:24] still pretty good. And it really is just [31:27] like that persistence of like trying and [31:29] trying and trying and trying and failing [31:31] and failing over again until succeeding. [31:34] And it it broke me a little bit, but it [31:38] did work eventually. and it paid off and [31:40] so I'm very grateful for never having [31:43] given up. [31:45] >> For sure. There's a lot of like cultural [31:47] perception around software development [31:50] jobs in general. One of them is being [31:53] that people think software development [31:55] jobs are really stable and that's not [31:57] necessarily true for a lot of people or [31:59] that they're really well paid and that's [32:01] also not necessarily true in every [32:03] situation. So yeah, it's it's it's [32:06] sometimes frustrating hearing that and [32:09] being like, well, that's not my [32:10] experience. But, you know, you can't [32:12] change can't change the industry [32:14] necessarily or people's perception on on [32:17] the whole. You can only kind of operate [32:20] with with what you have and and do the [32:23] best with with the opportunities [32:24] available. And um yeah, definitely [32:27] sounds like you've been really smart [32:28] about that throughout your career, which [32:29] is refreshing. [32:30] >> Yeah. Thank you. [32:32] >> Yeah. [32:33] For sure. Well, we are getting up on the [32:37] end of time, which is crazy. This has [32:39] gone by so fast. And uh we always wrap [32:42] up with a bit of a fun segment where uh [32:47] today we're going to take the question [32:49] of what if we could apply terminal graph [32:52] this idea of like graphical interfaces [32:56] organized and and node data flow um and [32:59] apply that to some kind of real life [33:02] situation off of a screen. I guess I [33:05] mean developing is also real life but uh [33:07] if you could kind of take this idea and [33:09] apply it to some yeah some nonverirtual [33:12] environment uh what that would look [33:14] like. [33:15] >> Yeah that's my goodness I don't think [33:17] I've ever thought about this before. [33:18] Give me give me a moment here. [33:20] >> Yeah I have thought about this because [33:22] I'm the one who wrote the question. So, [33:23] I have a daughter and you know there are [33:26] times when it's like I would love to [33:28] kind of know where everyone is at all [33:31] the time, you know, and it's not all the [33:33] time. We're pretty good about [33:34] communicating between me and my my [33:37] husband, but like, you know, it'd be [33:39] nice to kind of like have have these [33:42] these communications where I can know [33:44] where she is and he can know where she [33:46] is and I can know where he is and we're [33:48] all kind of like communicating without [33:51] without necessarily being in the in the [33:53] same place. So, that's that's that's [33:56] sort of my my take on it. [33:58] >> Yeah. So, I think for me personally, I I [34:02] have ADHD and have struggled with it for [34:05] a long time. And I kind of view it as [34:07] both a bit of a superpower and a [34:09] detriment. Like, it kind of helps me [34:13] have a lot of creativity and explore a [34:15] lot of options and like kind of go down [34:18] weird tangents, but that usually leads [34:20] me to something interesting. But, it's [34:22] also kind of hard to like sit down and [34:24] do a thing if I'm not like deeply [34:26] invested in it. And so I think if I [34:30] could have the power of turn graph [34:31] outside in the real world, it would be [34:34] to help augment that like getting, you [34:37] know, just connecting everything in my [34:39] life that needs to be done of like, oh, [34:41] my laundry is overflowing. like send me [34:44] a reminder or like force me to like [34:46] start the washer dryer like automate [34:49] that in some way you know automate like [34:52] how I can make breakfast or automating [34:54] like just various aspects of like the [34:56] routine that's um hard for me to keep up [34:58] with I think would be uh probably the [35:01] most useful for myself [35:03] >> but when the twins were really young [35:05] when I had a very young baby like [35:07] everything was so much like is the when [35:12] was the last time they ate are Are they [35:13] hungry? Do they get enough sleep? Like [35:15] there's just so much involved that you [35:17] feel like you're just like have those [35:18] little like Sim bars or something like [35:20] that when you're playing the Sims and [35:21] you're trying to keep them all green and [35:23] happy all the time. Especially when [35:25] there was two babies at once. Like that [35:27] would be a fantastic tool to have to [35:30] have, especially having the data flow. [35:32] Like there's a lot of tools out there. [35:34] So that would be like an early [35:36] parenthood terminal graph I think would [35:39] be really nice. This has been so much [35:41] fun. Kayen, thank you so much for [35:42] joining us. Where can folks find you on [35:44] the internet? [35:46] >> Yeah, I'm on most of the socials, [35:49] Threads, Blue Sky, Twitter, or X. And if [35:52] you go to my website, kaden.dev, that's [35:54] c ai dan.dev, [35:57] I have a link to all my socials there, [35:59] too, to make it easy. Awesome. Cool. And [36:02] we'll link that in the show notes as [36:04] well. [36:06] Well, listeners, thank [music] you so [36:07] much for tuning in to Overcommitted. If [36:09] you like what you hear, please do [36:11] follow, subscribe, or do whatever it is [36:13] you like to do on the podcast app of [36:14] your choice. Check us out on Blue Sky [36:17] and share with your friends. Until next [36:18] week. Goodbye.  📄 **Full text:** [[Full Document Contents/Articles/Building Terminal Graph, a Spatial Development Environment, With Caidan Williams.md|Building Terminal Graph, a Spatial Development Environment, With Caidan Williams by YouTube]] ## Highlights - every bit of a feedback is all good to take into account, but for myself, I'm trying to make sure I'm not building like an everything app. I don't want this to like have every feature possible under the sun. ([View Highlight](https://read.readwise.io/read/01ky2nx8swnd8fd780xvr2yn6b)) - Note: Product-discipline principle: resisting the "everything app" temptation, scoping deliberately. - Tags: atom/literature/h2 - out this shareability aspect and making it so that my goal is to have teams be able to have common development workflows. It's like release workflows or security audits or anything that's like kind ([View Highlight](https://read.readwise.io/read/01ky2nxeex9n6es5xadbrs9atx)) - Note: Vision: shareable common dev workflows (release, security audits) as reusable graph templates for teams. - Tags: atom/literature/h3 - And I've even added like a webhook node that allows you to, you know, connect to external systems and get events that you can pipe through into the entire system of whatever automation you want. ([View Highlight](https://read.readwise.io/read/01ky2nx2p65zrghk1bng2rqpws)) - Note: Terminal Graph's extensibility: webhook nodes pipe external events into any automation flow. - Tags: atom/literature/h1