A few years ago I started a new job with a small company as a backend Go developer. One of the first things I did at this job was set up GitLab-CI to run tests automatically for every merge request we created and block the merge if any tests failed. You know… the normal way of using a test automation pipeline with merge requests.
This worked great… for about 2 days.
Then the CTO pulled me over to his desk, quite concerned. He was looking at the CI/CD Pipelines overview in GitLab.
“We need to stop running these tests automatically. It’s cluttering up this page with a bunch of errors.”
He had been using that page as a summary of releases to production (and also to manually trigger deployments to production), rather than for its broader intended purpose of showing a record of all pipelines.
Facepalming on the inside, I replied with “You can filter out failures, if you want, and only show pipelines run on master.”
He thought for a moment then said “No. Just revert the automatic tests. It’s too much hassle.”
I left that company less than 2 weeks after I started.
Last I heard they had hired someone much more junior to replace me, and were happily, if inefficiently, trotting along without their automated tests.
Not everyone wants your solution. You may know a better way to do things, that may solve actual problems. But if the recipient doesn’t feel pain from those problems, they will see no value in your suggestions. That’s okay. You don’t need to convince them.
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (0)