docs(fde): update descriptions and add roadmap links on resource-less nodes

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-24 01:08:07 +08:00 · 2026-10-15 18:31:42 +02:00
parent 42b0d7809d
commit 865cf75f55
10 changed files with 36 additions and 12 deletions
@@ -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.
+
+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)
@@ -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.
+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)
@@ -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.
+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.
@@ -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.
+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.
@@ -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.
+
+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.
@@ -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.
+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)
@@ -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.
+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)
@@ -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.
+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)
@@ -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.
+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.
@@ -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.
+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)