# Attitude

## Effort

Sometimes people ask for help without trying to solve an issue themselves. Attempting to solve issues yourself is always the first step you should take, no matter what the issue is. Peer help should be a last resort; you shouldn't involve others if it's not necessary.

Putting in effort is the only way you can make progress. If you immediately give up and never try, you'll also never improve. If you don't push yourself you won't make any progress. Giving up guarantees failure.

And, once people are helping you, continue to try. You don't get to sit back and watch while others do the work for you. There is no magic process you put your code in and it comes out fixed.

> &#x20;                              *"If you are not willing to learn, no one can help you.*
>
> &#x20;                                       *If you are determined to learn, no one can stop you."*

Your attitude going into this has an astronomical effect on the outcome. If you expect to get stuck then you will. If you believe in yourself, chances are you'll pull it off. It might take a few tries or a nudge in the right direction, but perseverance leads to success.

{% hint style="info" %}
See the [Errors](/syntask/issues/errors.md) and [Debugging](/syntask/issues/debugging.md) pages to learn how to solve errors and debug your code.
{% endhint %}

***

## Learning & retainment

Don't get angry when told to read the documentation or look through a tutorial. Remember you are here to learn. If you can't be bothered to learn how to code or understand your project, the best solution would be to hire and pay a developer to make it for you.

These tutorials and projects are not one-timers, you keep what you learned from them to use in future projects—that’s the only way learning can happen. To grow, you can’t ignore or discard what you've learned. Make sure you treat this as a learning experience and take something away from it to help you in future projects.

Many new programmers often feel overwhelmed and opt to "just get this done"; disregarding whether their code is poorly-written or inefficient as long as it functions, and neglecting opportunities to learn and improve. While exasperation is understandable, if you always take the easiest route: never pushing yourself, you'll never be able to improve, and the things that confuse you now will always seem out of reach.

If nothing you do seems to work, that's great! While this may seem counter-intuitive, it's true. Learning comes from experience, and (if you have the correct attitude), each failed attempt is still a learning experience you can take something away from.

{% hint style="info" %}
These people are here to teach you how to write better code and solve issues. If you don't want to learn, why should they bother helping?
{% endhint %}

***

## Improvements

Don't just settle for functional code. You want pristine, efficient, and easy-to-read code. So many people think that as long as code works, it's good code. This is far from the case; 'functional' is not a synonym with 'good'. There is always room for improvement and optimisation, and everyone should strive to have neat, efficient code.

Just because code is minimally functional does not make it unworthy of improvement. Optimised code will run faster, and is always easier to debug and fix issues, or modify in the future. You also want your code to be tidy and legible—especially if you are asking someone else to read through it.

{% hint style="info" %}
See the Organisation page to learn how to write neat code.\
-> The organisation page is not yet completed
{% endhint %}

Have an open mind. These people are here to help you, but you have to let them. If they implore you to change a part of your code, or make a suggestion, you must understand that there is a justified reason. If they recommend doing something, just because it requires additional effort doesn't mean it's not worth it.


---

# 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://x8ight.gitbook.io/syntask/issues/peer-help/attitude.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.
