3 ms·

I can accept that laying rules like 'Don't touch my server' before people start writing over each other's work does not seem abusive. It makes me wonder: in ca

I can accept that laying rules like 'Don't touch my server' before people start writing over each other's work does not seem abusive. It makes me wonder: in case the senior dev did not disclose this policy to the junior dev prior to the meeting, what was the senior dev expecting? If no rules were communicated, it falls to the senior dev to lay them out. At the point that a junior dev does not follow a previously undisclosed procedure, why would that make the senior dev angry? The senior dev can note that the server is on his list and ask why did not the junior dev check who is responsible for the server?

pluma 11y ago
> what was the senior dev expecting? Ask for permission. Failing that, ask for forgiveness. It's rude to mess with other people's stuff, or even shared property. Imagine it wasn't a server but a conference room he decided to apply his vigilante justice to. The result may have been a positive surprise but being a junior there's also a good chance he was ignorant of the requirements and have made things worse for others. In an ideal workplace every requirement is documented and every policy is written down and laid out to every team member. In the real world it's better to expect not to know everything -- and that's a fairly valuable lesson to take away in a junior role. That said, the response may be blunt but it should never be angry, especially not beyond the scope of the actual intervention itself. If you're about to cause significant damage, it's okay to put that in drastic terms to make sure you stop right there. But it shouldn't be personal and it should be considered a learning experience by everyone involved. Everyone should be allowed to make mistakes. They should just be expected to learn from them and avoid making the same mistakes in the future.
jlarocco 11y ago
Does there really need to be a rule for that? If somebody is working on a server, and you know it, it's common sense not to mess with it.
- greendesk 11y ago
  From the context in the blog, it is not communicated clearly who was assigned to rebuild the server and whether the senior dev communicated that he is working on it. The rule can be a morning stand-up or Jira note, saying that the work is assigned to this person. At the time, developers (probably) were not accustomed to have either.

pluma 11y ago

> what was the senior dev expecting? Ask for permission. Failing that, ask for forgiveness. It's rude to mess with other people's stuff, or even shared property. Imagine it wasn't a server but a conference room he decided to apply his vigilante justice to. The result may have been a positive surprise but being a junior there's also a good chance he was ignorant of the requirements and have made things worse for others. In an ideal workplace every requirement is documented and every policy is written down and laid out to every team member. In the real world it's better to expect not to know everything -- and that's a fairly valuable lesson to take away in a junior role. That said, the response may be blunt but it should never be angry, especially not beyond the scope of the actual intervention itself. If you're about to cause significant damage, it's okay to put that in drastic terms to make sure you stop right there. But it shouldn't be personal and it should be considered a learning experience by everyone involved. Everyone should be allowed to make mistakes. They should just be expected to learn from them and avoid making the same mistakes in the future.

jlarocco 11y ago

Does there really need to be a rule for that? If somebody is working on a server, and you know it, it's common sense not to mess with it.

greendesk 11y ago
From the context in the blog, it is not communicated clearly who was assigned to rebuild the server and whether the senior dev communicated that he is working on it. The rule can be a morning stand-up or Jira note, saying that the work is assigned to this person. At the time, developers (probably) were not accustomed to have either.