# Attention is the most precious resource in a project

Once you've decided [what to build](https://thekarel.gitbook.io/best-practices/the-big-picture/principles/business), you need to dedicate your attention to turn it into reality. You need to focus on what matters and ignore everything else.

Writing software requires long periods of uninterrupted concentration. Developers need to consider complex ideas in detail, imagine and experiment with various solutions to find the one that works. Finding answers often requires research and the learning of new concepts. All this is impossible without paying attention.

Considering the need for attention helps understanding why adding more people to a project lowers productivity: it introduces distractions and increases the amount of required communication.

There are several symptoms of the lack of proper focus and care. Developers will feel annoyed and frustrated, running in circles, starting and restarting work, getting stuck with the same problem for too long. The choice of tools and libraries will ignore existing patterns. The implemented solutions will be inconsistent, buggy and fail in many cases.

If everybody seems busy, but there is no progress: people are not focusing.

It helps to divide activities by the kind of attention they need. There is time for high-level planning involving a lot of communication, then for slower, more detailed investigations involving far fewer people. Finally, there is time for actually creating solutions in code that requires the least amount of communication but the highest level of concentration. These stages also involve the handling of a very different set of ideas - they are different contexts.

It's difficult, inefficient and for many, very frustrating to switch between these different modes of operation. Context switching is slow and costly.

There is no such thing as multitasking. You can do one thing well or many things wrong in parallel.

Successful developers work in attention-friendly environments without unnecessary external interruptions. They also learn how to manage and direct their focus on what's relevant: they are disciplined.

When the problem at hand is hard (or just not very exciting), it's easy and tempting to find distractions. Typical diversions are over-engineering some parts, introducing unnecessary technologies "just to try", inventing problems that are more comfortable (more interesting) to solve, or starting on a new task without finishing the current one.

Watch out for attention wasters: inconsistent code, untidy structures, lousy formatting, misleading or useless documentation. Replace broken tools. Automate every repetitive task, regardless of how trivial or complicated they are.

Without distractions, a good developer becomes a firehose of solutions. Move the barriers - yours and others' - out of the way.

Immersing in your creative task allows you to [experience the Flow](https://www.amazon.co.uk/dp/0712657592/) every day, forever turning a "job" into an enjoyable activity.

Create and maintain [simple things](https://thekarel.gitbook.io/best-practices/the-big-picture/principles/simple) because they require less attention.


---

# 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://thekarel.gitbook.io/best-practices/the-big-picture/principles/attention.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.
