From 865cf75f55049e1b73dc9be86e8459c5f5b27f47 Mon Sep 17 00:00:00 2001 From: Javier Canales Date: Thu, 15 Oct 2026 18:31:42 +0200 Subject: [PATCH] docs(fde): update descriptions and add roadmap links on resource-less nodes Co-Authored-By: Claude Sonnet 5.5 --- .../content/apis-design@_nL7Wf1MG3mofKY9XwGDX.md | 8 ++++++-- .../content/build-your-agent@exOxhFap719ArAhvgsCDx.md | 6 +++++- .../content/business-acumen@bE7j2U28V8Vf9OKHBqLwW.md | 2 +- .../content/communication@iaNbLDFrEDYEKwpkGFWts.md | 2 +- ...mplete-app-with-observability@lWOtIplGjXg139CAr2HaC.md | 4 ++-- .../content/complete-apps@YyPk_MygYb40ALZ2cynmN.md | 6 +++++- .../content/data-pipelines@oqvpmxz-G2wAYZBsvYI-l.md | 6 +++++- .../content/frontend-apps@7JU1cVggMDoZUV-adGsf-.md | 6 +++++- .../product-feedback-loop@U2mQX5_XwmW74HFEM1Uzw.md | 2 +- .../content/prompt-versioning@DKWrSQDE7nFZFGVEUH1od.md | 6 +++++- 10 files changed, 36 insertions(+), 12 deletions(-) diff --git a/roadmaps/forward-deployed-engineer/content/apis-design@_nL7Wf1MG3mofKY9XwGDX.md b/roadmaps/forward-deployed-engineer/content/apis-design@_nL7Wf1MG3mofKY9XwGDX.md index da42dc031..8444dc390 100644 --- a/roadmaps/forward-deployed-engineer/content/apis-design@_nL7Wf1MG3mofKY9XwGDX.md +++ b/roadmaps/forward-deployed-engineer/content/apis-design@_nL7Wf1MG3mofKY9XwGDX.md @@ -1,3 +1,7 @@ # API Design - -API design is the process of defining how services communicate with each other through well-structured interfaces. Good API design involves choosing the right protocol (REST, GraphQL, gRPC), defining clear resource models, handling errors consistently, and versioning carefully. \ No newline at end of file + +API design is the process of defining how services communicate with each other through well-structured interfaces. Good API design involves choosing the right protocol (REST, GraphQL, gRPC), defining clear resource models, handling errors consistently, and versioning carefully. FDEs often need to design or extend APIs quickly in customer environments, so knowing what good looks like, and what to avoid, saves significant rework later. + +Visit the following resources to learn more: + +- [@roadmap@Visit the Dedicated API Design Roadmap](https://roadmap.sh/api-design) diff --git a/roadmaps/forward-deployed-engineer/content/build-your-agent@exOxhFap719ArAhvgsCDx.md b/roadmaps/forward-deployed-engineer/content/build-your-agent@exOxhFap719ArAhvgsCDx.md index 884bb3f3b..443002f78 100644 --- a/roadmaps/forward-deployed-engineer/content/build-your-agent@exOxhFap719ArAhvgsCDx.md +++ b/roadmaps/forward-deployed-engineer/content/build-your-agent@exOxhFap719ArAhvgsCDx.md @@ -1,3 +1,7 @@ # Build your Agent -You have learned the concepts. Now build one. Pick a real task, something you actually want automated, and build an agent that can do it: define the tools, write the orchestration logic, handle failures, and test it against inputs that are likely to break it. It does not matter if the first version is rough. Getting hands-on with a real agent exposes the gaps that no amount of reading covers, and what you learn from debugging a misbehaving agent is exactly the knowledge you will need when doing it inside a customer environment. \ No newline at end of file +Pick a real task, something you actually want automated, and build an agent that can do it. Define the tools, write the orchestration logic, add input validation, a max-step limit, and an audit trail that logs every prompt, tool call, and response with timestamps. Then test it against inputs likely to break it. Resist the urge to use AI at every step. Most of the work should be tool calls, with one LLM call doing the orchestration. The goal is not a polished demo. It is a system that handles failure gracefully and leaves a trace you can debug when something goes wrong in production. + +Visit the following resources to learn more: + +- [@roadmap@Visit the Dedicated AI Agents Roadmap](https://roadmap.sh/ai-agents) diff --git a/roadmaps/forward-deployed-engineer/content/business-acumen@bE7j2U28V8Vf9OKHBqLwW.md b/roadmaps/forward-deployed-engineer/content/business-acumen@bE7j2U28V8Vf9OKHBqLwW.md index 36f1b63b7..7dfd11b45 100644 --- a/roadmaps/forward-deployed-engineer/content/business-acumen@bE7j2U28V8Vf9OKHBqLwW.md +++ b/roadmaps/forward-deployed-engineer/content/business-acumen@bE7j2U28V8Vf9OKHBqLwW.md @@ -1,3 +1,3 @@ # Business Acumen -Business acumen is the ability to understand how an organization operates, what its priorities are, how it makes money, and where technology can create real value. Being able to connect engineering decisions to business outcomes is what makes FDEs different from traditional software engineers. \ No newline at end of file +Business acumen is the ability to understand how an organization operates, what its priorities are, how it makes money, and where technology can create real value. For FDEs, this means being able to connect engineering decisions to business outcomes and speak the language of stakeholders who do not have technical backgrounds. Without it, technically sound work can still fail to land as impactful with the customer. diff --git a/roadmaps/forward-deployed-engineer/content/communication@iaNbLDFrEDYEKwpkGFWts.md b/roadmaps/forward-deployed-engineer/content/communication@iaNbLDFrEDYEKwpkGFWts.md index 474ef6356..81d6ee395 100644 --- a/roadmaps/forward-deployed-engineer/content/communication@iaNbLDFrEDYEKwpkGFWts.md +++ b/roadmaps/forward-deployed-engineer/content/communication@iaNbLDFrEDYEKwpkGFWts.md @@ -1,3 +1,3 @@ # Communication -If you cannot explain what AI can and cannot do to a non-technical VP, you cannot be an FDE. Communication in this role is about translating between two different worlds: the technical reality of what you are building and the business reality of what the customer needs to justify the investment. That means being able to speak about token costs and latency in the same conversation where you are explaining ROI to an executive. It also means knowing when to say AI is not the right answer. \ No newline at end of file +If you cannot explain what AI can and cannot do to a non-technical VP, you cannot be an FDE. Communication in this role is not about simplifying things for people who are less smart. It is about translating between two different worlds: the technical reality of what you are building and the business reality of what the customer needs to justify the investment. That means being able to speak about token costs and latency in the same conversation where you are explaining ROI to an executive. It also means knowing when to say AI is not the right answer, because that honesty is what builds the trust that makes everything else work. diff --git a/roadmaps/forward-deployed-engineer/content/complete-app-with-observability@lWOtIplGjXg139CAr2HaC.md b/roadmaps/forward-deployed-engineer/content/complete-app-with-observability@lWOtIplGjXg139CAr2HaC.md index 793f262fa..09a2aebd0 100644 --- a/roadmaps/forward-deployed-engineer/content/complete-app-with-observability@lWOtIplGjXg139CAr2HaC.md +++ b/roadmaps/forward-deployed-engineer/content/complete-app-with-observability@lWOtIplGjXg139CAr2HaC.md @@ -1,3 +1,3 @@ # Complete App with Observability - -Take a complete application and make it production-ready by building a sandbox first: a replica of the deployment environment where you can run, test, and debug the system before it touches production. Then add the operational layer: structured logging, distributed tracing, error tracking, performance metrics, and alerts. Once it is running, break something intentionally and use those tools to find it. In a real customer engagement, you will not be there forever. Observability is what lets the customer's team keep the system running after you leave. \ No newline at end of file + +Take a complete application and make it production-ready by building a sandbox first: a replica of the deployment environment where you can run, test, and debug the system before it touches production. Then add the operational layer: structured logging, distributed tracing, error tracking, performance metrics, and alerts. Once it is running, break something intentionally and use those tools to find it. In a real customer engagement, you will not be there forever. Observability is what lets the customer's team keep the system running after you leave. diff --git a/roadmaps/forward-deployed-engineer/content/complete-apps@YyPk_MygYb40ALZ2cynmN.md b/roadmaps/forward-deployed-engineer/content/complete-apps@YyPk_MygYb40ALZ2cynmN.md index dfffb8e44..b400d950d 100644 --- a/roadmaps/forward-deployed-engineer/content/complete-apps@YyPk_MygYb40ALZ2cynmN.md +++ b/roadmaps/forward-deployed-engineer/content/complete-apps@YyPk_MygYb40ALZ2cynmN.md @@ -1,3 +1,7 @@ # Complete Apps -This is where everything connects. Take an idea and build it fully, from the database schema to the API to the frontend. No mocking, no placeholders, no "this would normally connect to X." The point is to experience what it feels like to own a full system: making decisions at every layer, dealing with the friction between them, and ending up with something that actually works. Building complete apps on your own is the best way to develop that instinct before you are doing it under customer pressure. \ No newline at end of file +This is where everything connects. Take an idea and build it fully, from the database schema to the API to the frontend. No mocking, no placeholders, no "this would normally connect to X." The point is to experience what it feels like to own a full system: making decisions at every layer, dealing with the friction between them, and ending up with something that actually works. FDEs do this constantly on engagements, so building complete apps on your own is the best way to develop that instinct before you are doing it under customer pressure. + +Visit the following resources to learn more: + +- [@roadmap@Visit the Dedicated Full Stack Developer Roadmap](https://roadmap.sh/full-stack) diff --git a/roadmaps/forward-deployed-engineer/content/data-pipelines@oqvpmxz-G2wAYZBsvYI-l.md b/roadmaps/forward-deployed-engineer/content/data-pipelines@oqvpmxz-G2wAYZBsvYI-l.md index 151ebf4ff..52975e26b 100644 --- a/roadmaps/forward-deployed-engineer/content/data-pipelines@oqvpmxz-G2wAYZBsvYI-l.md +++ b/roadmaps/forward-deployed-engineer/content/data-pipelines@oqvpmxz-G2wAYZBsvYI-l.md @@ -1,3 +1,7 @@ # Data Pipelines -A data pipeline is a series of steps that move and transform data from one place to another, usually from source systems into a warehouse or processing layer. Pipelines can be batch-based (running on a schedule) or streaming (processing data in real time). Building reliable pipelines means handling failures, schema changes, and data quality issues, all of which are common realities in customer environments. \ No newline at end of file +A data pipeline is a series of steps that move and transform data from one place to another, usually from source systems into a warehouse or processing layer. Pipelines can be batch-based (running on a schedule) or streaming (processing data in real time). Building reliable pipelines means handling failures, schema changes, and data quality issues, all of which are common realities in customer environments. + +Visit the following resources to learn more: + +- [@roadmap@Visit the Dedicated Data Engineer Roadmap](https://roadmap.sh/data-engineer) diff --git a/roadmaps/forward-deployed-engineer/content/frontend-apps@7JU1cVggMDoZUV-adGsf-.md b/roadmaps/forward-deployed-engineer/content/frontend-apps@7JU1cVggMDoZUV-adGsf-.md index bd622bd6e..6fed59f98 100644 --- a/roadmaps/forward-deployed-engineer/content/frontend-apps@7JU1cVggMDoZUV-adGsf-.md +++ b/roadmaps/forward-deployed-engineer/content/frontend-apps@7JU1cVggMDoZUV-adGsf-.md @@ -1,3 +1,7 @@ # Frontend Apps -Put the frontend skills together and build something that lives entirely in the browser. A weather dashboard, a personal finance tracker, a Pomodoro timer, a markdown editor. Use mock data or a public API if you need data, but keep the focus on the frontend itself: how you structure components, manage state, handle routing, and make the interface feel responsive and usable. The goal is to get comfortable making frontend decisions on your own, without a backend to hide behind. \ No newline at end of file +Put the frontend skills together and build something that lives entirely in the browser. A weather dashboard, a personal finance tracker, a Pomodoro timer, a markdown editor. Use mock data or a public API if you need data, but keep the focus on the frontend itself: how you structure components, manage state, handle routing, and make the interface feel responsive and usable. The goal is to get comfortable making frontend decisions on your own, without a backend to hide behind. + +Visit the following resources to learn more: + +- [@roadmap@Visit the Dedicated Frontend Developer Roadmap](https://roadmap.sh/frontend) diff --git a/roadmaps/forward-deployed-engineer/content/product-feedback-loop@U2mQX5_XwmW74HFEM1Uzw.md b/roadmaps/forward-deployed-engineer/content/product-feedback-loop@U2mQX5_XwmW74HFEM1Uzw.md index 74637fc50..775bcd2d5 100644 --- a/roadmaps/forward-deployed-engineer/content/product-feedback-loop@U2mQX5_XwmW74HFEM1Uzw.md +++ b/roadmaps/forward-deployed-engineer/content/product-feedback-loop@U2mQX5_XwmW74HFEM1Uzw.md @@ -1,3 +1,3 @@ # Product Feedback Loop -A product feedback loop is the cycle of shipping something, collecting feedback from users or stakeholders, and using that input to improve future iterations. This usually means working closely with the customer to observe how the delivered product is actually being used, identifying gaps between expectation and reality, and feeding those observations back into the build process while still on the engagement. \ No newline at end of file +A product feedback loop is the cycle of shipping something, collecting feedback from users or stakeholders, and using that input to improve future iterations. For FDEs, this usually means working closely with the customer to observe how the delivered product is actually being used, identifying gaps between expectation and reality, and feeding those observations back into the build process while still on the engagement. diff --git a/roadmaps/forward-deployed-engineer/content/prompt-versioning@DKWrSQDE7nFZFGVEUH1od.md b/roadmaps/forward-deployed-engineer/content/prompt-versioning@DKWrSQDE7nFZFGVEUH1od.md index b718dc379..444fe1c7c 100644 --- a/roadmaps/forward-deployed-engineer/content/prompt-versioning@DKWrSQDE7nFZFGVEUH1od.md +++ b/roadmaps/forward-deployed-engineer/content/prompt-versioning@DKWrSQDE7nFZFGVEUH1od.md @@ -1,3 +1,7 @@ # Prompt Versioning -Prompt versioning is the practice of treating prompts like code, tracking changes over time with version control. This makes it possible to roll back to previous versions, compare outputs across versions, and understand what changed when behavior shifted. When handing AI systems to customers, prompt versioning is part of making those systems maintainable after the engagement ends. \ No newline at end of file +Prompt versioning is the practice of treating prompts like code, tracking changes over time with version control. This makes it possible to roll back to previous versions, compare outputs across versions, and understand what changed when behavior shifted. For FDEs handing AI systems to customers, prompt versioning is part of making those systems maintainable after the engagement ends. + +Visit the following resources to learn more: + +- [@roadmap@Visit the Dedicated Prompt Engineering Roadmap](https://roadmap.sh/prompt-engineering)