# Build and Program the Solution

<figure><img src="/files/PVc2aZQ0XFvMLSCboJYP" alt=""><figcaption></figcaption></figure>

This criteria area has two subsections that some teams forget to take into consideration. The first is build which is the primary area teams focus upon. The second area, program, is where teams often fall short.

### *Build*

When considering what to include in this area there are varieties of depths that a team can explore. It can be as simple as providing some images of a subsystem or completed solution or go as far as providing step by step instructions around how to put the solution together with a full parts list down to the screws and nuts being used.

When deciding what is enough detail to provide, consider what you would need if you had to rebuild/recreate your own solution. Would you need a few sentences describing a solution with accompanying sketches or detailed CAD with a full parts list and build instructions?

***

### *Program*

For programming teams may vary from putting in a couple functions describing key features to placing their entire code. While the latter is nice, it may be overkill for what is needed from a recreation perspective.

What is a good approach to documenting a team’s code base?

* Use Pseudocode to give the reader an understand of what is trying to be accomplished
* Create path maps to go with the Pseudocode
* Provide snippets of code and not an entire file
* Comment code, not only is it a good practice but can help the reader understand what is taking place in a particular section of a code

One consideration to keep in mind is that many teams are starting to use coding templates. As the growth of these continues to be leveraged by more and more teams, the diversity in coding and showing/explaining what is being developed for use may shrink. To show how a team is using that code or any modification or unique approach it is worthwhile to comment as much as possible or even create markups that can go alongside the code in the notebook. Additionally it is also a good idea to provide credit to the author or team of the template.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://iiwii-robotics.gitbook.io/engineering-notebook/vex-engineering-notebooks/understanding-the-engineering-notebook-rubric/engineering-design-process-categories/build-and-program-the-solution.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.