| description | Pablo implementing user commands |
|---|---|
| tags | note incident qoj |
Faster iteration cycles is what makes a team progress
But many things can get in the way especially in a (soon to be remote) team where collaboration on a single project is kind of a new things
Let's come back to an incident from last week and see what we can learn from it
#redmine #575 User shall be able to login into the system and perform configuration tasks Some configuration changes needed the user to reboot the system, whereas restarting the services would be enough to get it done.
- Pablo took up the task.
- He strated implementing a wrapper around restarting the scripts in order to keep the principle of least privilege
- René thought of a an easier solution: having a file watcher that restart the services automatically
- Pablo started to work on it and noticed this wouldn't allow to inform the user if restarting the services failed or succeeded
- From then on he had zero feedback from the rest of the team
- He worked on a compromise between his and rené solution
- While implementing this, he stumbled upon unrelated problems that ended up in this merge request
- During a daily, Pablo was asked what was the status of this merge request, to which he replied : well it's fixed on my branch, but there is no one to review it or give me feedback.
- As it turns out until now there were not real feedback on existing merge requests
- We were pressed by the DATEV deadline so we end up giving Pablo greenlight to merge his work without peer-review, which is not the correct thing to do but was also what was done before in practice
- René saw the requests being merged, no peer review, a merge request doing too much at once, and reverted it
This caused friction in the next daily, the arguments being
- As a professional team we can't just self review our work.
- Fair enough how this was done was frustrating from the receiver side
- Well we didn't have the manpower.
- Well we don't have yet the skills / done the knowledge transfer that would make review possible
- We had no time to do the right thing
The issue is not a disagreement that we need to have some git flow guidelines and request and provide feedback
It's about removing the friction so that they can realistically happen in practice.
If as a developer, I have no confidence that we will get feedback in time, then we will fall back up working on our branch in cowboy mode
This will become especially important in a remote team where it can quickly become isolating if you are a lone developer who can't rely on being unblocked from your colleagues.
Therefore unblocking the colleagues should be seen as a priority, also it's nice to have them unblock me on a daily basis :)
On the other hand, it should not feel like this is yet another bureaucratic chore that prevents me from doing my work
There are practices and collaboration tools that help to do that
- Merging from main regularly so that my work don't diverge too much from my colleagues
- Doing 30%-ready pull requests to ask for early feedback and not get deep into a rabbit hole that will turn out to be a waste of time
- Splitting up a redmine ticket into smaller gitlab merge requests upfront
- Splitting up after the fact if we started to work on something and had to fix other things on the way
- Bidirectional links between redmine issues and gitlab issues and merge requests to enable to understand what's going on
- Having templates on issues and merge requests (see below)
- Gitlab is where the work happen and here there are lots of tools that are built-in that improve tracability
- Gitlab gives a dashboard that shows you in the morning what your tasks are, who asked for feedback, who gave you feedback on issues and merge request
- This enables devs to be in the flow and know exactly what they need to do on a communication level
- And then they can go back to a state of deep work
See https://gitlab.qoj.internal/dashboard/merge_requests
I see a changelog of what changed but that's about it.
I have no idea of what smash and pmt_client are, why the change was needed, how I can test that it works.
My review could consist in just asking the right questions