For years I operated as a pure frontend engineer — React, CSS, browser APIs, the occasional dive into bundler configuration — and for most of that time it was genuinely enough. As I moved into more senior roles, though, I kept running into situations where a shallow understanding of the backend limited how useful I could be: reviewing a PR that touched an API contract, weighing in on an architecture decision spanning both sides of the stack, debugging a production issue originating in a service I'd never opened. In each case I could contribute part of the conversation but had to defer to backend specialists for the parts that mattered, which meant decisions got made without my input even when they directly affected the frontend. Seniority that stops at the API boundary isn't really seniority; it's a specialized role with a senior title.

The goal was never to become a dedicated backend specialist. It was to become dangerous enough — in the useful sense — to ship a complete feature end-to-end, understand what a backend engineer was telling me in a design review, and prototype a full vertical slice without waiting on someone else's availability. The roadmap was deliberately paced: three months of NestJS to learn API design in a familiar language, four months of Go to learn a different paradigm, and five months of RAG to learn the LLM application stack.

NestJS felt surprisingly familiar coming from React. Modules, services, controllers, and dependency injection all map onto concepts a frontend developer has intuition for, which meant the learning curve was mostly about backend-specific concerns — database access patterns, request validation, HTTP semantics — rather than fighting an unfamiliar programming model. Within a few weeks I had a working CRUD API with validation, pagination, and PostgreSQL integration. The validation layer was the most valuable thing to learn in detail, because frontend developers tend to underestimate how much of backend engineering is carefully validating input. A frontend form validates for user experience; a backend endpoint validates for security and data integrity, and the failure modes are different.

Because both frontend and backend were TypeScript, we could share type definitions for API request and response shapes, eliminating an entire category of bugs where the frontend's assumptions silently drifted from what the backend returned. The shared types also made refactoring safer — changing a response shape on the backend produced a compile error on the frontend. That end-to-end type safety is one of the most underrated benefits of a full-stack TypeScript setup.

Go was a noticeably harder adjustment, and the first month was genuinely frustrating. Its simplicity is deceptive — the language has very few constructs to learn, but it takes real time to build intuition for goroutines and channels instead of promises and async/await, and to get comfortable with Go's explicit, less magical error handling. I kept reaching for abstractions Go deliberately doesn't provide and feeling like the language was fighting me. By the second month, I started to see that the verbosity was the point — Go optimizes for readability by someone who didn't write the code, not for writability, and that tradeoff pays off in long-lived codebases where the original author has moved on.

The payoff was tangible: a Go service that replaced an existing Node.js microservice handled roughly 10 times the throughput while using about half the memory, running on the same hardware. Go's standard library is also unusually complete — for the kinds of services we were building, it consistently required fewer third-party dependencies than any comparable JavaScript project, which meant a smaller attack surface and fewer version-compatibility headaches. The standard library includes production-grade HTTP serving, JSON parsing, crypto, and database access, all maintained by the Go team and covered by the Go compatibility promise.

The final stretch was building a retrieval-augmented Q&A system for our internal knowledge base, using pgvector for embeddings and OpenAI for generation. The hardest part by a significant margin was prompt engineering — small, seemingly cosmetic changes in wording could shift the quality of generated answers noticeably, in ways that weren't always predictable. Adding "Answer based only on the provided context" measurably reduced hallucinations. Asking the model to "cite the chunk number for each claim" produced more grounded answers than asking it to "be accurate." None of these changes were intuitive, and most I discovered by accident.

That pushed me to start treating prompts more like code: version control, structured A/B comparisons, and a small evaluation set of representative questions with known-good answers so I could measure whether a prompt change was actually an improvement rather than relying on gut feel. The evaluation set was the single most valuable thing I built during this period, because it gave me a way to detect regressions that would otherwise have slipped through. Treating prompts as code with tests and version control is more work than treating them as strings, but it's the only way to iterate on prompts without eventually shipping a regression.