You just made a role change.
Or a job change.
Or an environmental change.
The name has changed.
But the problems remain.
The problem may be your practice. Your culture.
Don't be a victim of rename and shame.
Renaming is a responsible step to change
Rename those variables and functions.
And shame the need for comments.
A good change that is.
Who is going to write those comments or documentation anyway?
The team named LEAN?
Rename that bug to a known issue.
Rename that known issue to a non-issue.
Isn't that what it is anyway?
Since the Devs are saying the issue is from not being code-first,
While the business says it is not being product-first,
And the men in the middle ask, are we not all humans first?
Rename and shame the bug,
Make it a test case that must be passed,
Shame it for what it is worth,
Before it ever gets to production,
Before it is up,
As a downtime means the ups are down,
means an all-nighter- the Devs are up,
Low morale - the Ops are down,
Should call it something else, if that would get the Devs Up,
Call it SRE, if you may, call it DevOps.
Refactor it if you want, but first, rename it,
Replatform, repurchase, rehost, retire it if you want, but first rename it,
Rename it because the culture is in the name,
The culture is not in the technicalities or the technology,
The culture is in the theme, the purpose,
And that's what the name is all about.
But with the name comes a newfound responsibility,
A responsibility that the brain is not used to,
And at least memories may help us not to forget that,
that is what the name is all about.
And when we are used to the newfound culture, we don't dwell,
Because that is what shame is all about.
So....rename it.
But don't be a victim of rename and shame.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (0)