Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding "trying to solve a problem" agreement #73

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

adding "trying to solve a problem" agreement #73

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions agreements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,28 @@ Developers should also take into consideration the following rules:
- It is recommendable for different developers to look at the subsequent iterations of the same code, as it may help catch bugs or look at the code differently.
- If a staff member realizes that everyone has refused to review a post, they should escalate the issue and discuss it with the team.

## Trying to solve a problem

Even experienced engineers find it difficult to know when to stop trying to solve a problem – but **knowing when to stop is a vital skill for Reef developers** for a simple reason.

Our goal is to **save money for our Clients**, which means that we cannot waste it by banging our heads against the wall and billing hours without getting results or by working incessantly on unnecessary elements of a feature.

In many cases, there are **better approaches** than attempting the same thing over and over:
- Taking a break and returning to the problem with a clear head. You may switch to another project for a while or just go for a walk.
- Reaching out to your colleagues to discuss the problem, find inspiration, or get a confirmation for the way you see the project priorities. You can use #python for that.
- Trying out a suggestion that you personally don’t like, but which may be the right choice.
- Reaching out to the software / tool / library provider and asking for support or a bug fix.

How can you know that you’re stuck and the time has come to try an alternative approach?

It’s impossible to create an algorithm for when to stop working on a problem or to define a maximum amount of time allowed per problem. After all, every project is different.

Knowing when to stop making useless efforts or when to back out from an idea is a tacit skill that we all need to develop and foster. This **self-awareness is an important part of the reason why our Clients trust us** to deliver great software at a fair price.

Currently, there are two things we can do to reinforce this skill in Reef Technologies developers:
- We should all try to maintain an awareness of our working process. If you’re starting to feel frustrated, or if you find yourself trying the same thing as before and expecting different results, refer to this agreement. Give it a short read to remind yourself of the value Reef Technologies brings to our Clients by saving their money. Ask yourself if the way you’re working right now still fits the Reef way. If it is, well, happy coding. If you’re in doubt, maybe you should try one of the methods that you can find in the bullet points above.
- We want to build a culture where backing out of a dead end is not something to be embarrassed about – it’s something to be proud of, and it’s a skill that earns us more satisfied Clients. That is why in every status call, we spend some time discussing instances when we felt stuck or annoyed by a problem and methods we used to fix those situations.


## Maintaining organizational culture

Expand Down