As a dev, I have definitely had those moments... So I get it...
But trying to put the owner/exec/leader/supervisor in their place isn't the job of the dev.
If they want to spin their wheels on that stuff and the business is ok with spending the time and resources on it, then just sit back and enjoy the show. Lol.
You can only do so much. No sense getting worked up about it.
Using the plumber analogy from earlier, you are paying that person per hour most likely. If you want to slow down the process by showing off your wrench-skills, it would be silly of him to stop you, really.
A better response after looking into the issue would have been something along the lines of:
"You were right. There was definitely something wrong with the content. Great catch! It ended up being a new-line character that was breaking things. Not sure how we missed it, but it is all working as expected now. Let me know if you hear of any other issues."
And, really, if it's the owner of the company finding issues like that rather than the dev team, maybe that isn't the right moment for a senior dev to declare how highly-skilled they are...
Hmm yeah. Not sure how I feel about sitting back and watching a show if you know you can make it right. Maybe it's an incomplete perspective and I certainly don't have all the facts.
In the particular example I employed, the only reason the owner found the issue first was simply because he was on the website at exactly the right moment at some wee hour of the morning. I am not 100% sure how long that issue would've gone un-noticed otherwise so I cannot speak to that. But I would agree that, under normal circumstances, the dev team should be catching that rather quickly.
Yeah, I mean, we all certainly want to do what is best for the project/team/company but if someone higher up wants to call the shots, that's their call to make. Sucks sometimes. But I have personally never witnessed the "I know better than you!" approach work in the long-term.
Gotta' play the game and just not internalize it when folks want to argue or go a different direction.
I think he's referring to the fact that an issue so visually obvious should have been caught before being pushed live. I've definitely worked with an annoying owner finding bugs at 3am, but if something so obvious can make it to production, then perhaps your release pipeline is broken. If you have a proper staging environment that matches production and you always push to staging first, this should have been caught before going live. I get that we work in an era where QA jobs just don't exist because companies think devs are trained to provide proper QA, but this issue could have been noticed by just clicking through each page.
Not a judgment by the way. I've worked in environments in which the release cycle is so quick that it's often easier to just push it live and fix it later, and the owners want you to somehow fix the bugs that are pilling up but without giving you extra time to do them. But if the owner gives you shit, counter by asking for time to design and implement a proper release pipeline. If he doesn't give it to you, then you remind him every time he catches a bug "A proper release pipeline would have caught this early."
As a dev, I have definitely had those moments... So I get it...
But trying to put the owner/exec/leader/supervisor in their place isn't the job of the dev.
If they want to spin their wheels on that stuff and the business is ok with spending the time and resources on it, then just sit back and enjoy the show. Lol.
You can only do so much. No sense getting worked up about it.
Using the plumber analogy from earlier, you are paying that person per hour most likely. If you want to slow down the process by showing off your wrench-skills, it would be silly of him to stop you, really.
A better response after looking into the issue would have been something along the lines of:
"You were right. There was definitely something wrong with the content. Great catch! It ended up being a new-line character that was breaking things. Not sure how we missed it, but it is all working as expected now. Let me know if you hear of any other issues."
And, really, if it's the owner of the company finding issues like that rather than the dev team, maybe that isn't the right moment for a senior dev to declare how highly-skilled they are...
--Kevin Fairchild
Hmm yeah. Not sure how I feel about sitting back and watching a show if you know you can make it right. Maybe it's an incomplete perspective and I certainly don't have all the facts.
In the particular example I employed, the only reason the owner found the issue first was simply because he was on the website at exactly the right moment at some wee hour of the morning. I am not 100% sure how long that issue would've gone un-noticed otherwise so I cannot speak to that. But I would agree that, under normal circumstances, the dev team should be catching that rather quickly.
Yeah, I mean, we all certainly want to do what is best for the project/team/company but if someone higher up wants to call the shots, that's their call to make. Sucks sometimes. But I have personally never witnessed the "I know better than you!" approach work in the long-term.
Gotta' play the game and just not internalize it when folks want to argue or go a different direction.
That's my take on it, at least.
I think he's referring to the fact that an issue so visually obvious should have been caught before being pushed live. I've definitely worked with an annoying owner finding bugs at 3am, but if something so obvious can make it to production, then perhaps your release pipeline is broken. If you have a proper staging environment that matches production and you always push to staging first, this should have been caught before going live. I get that we work in an era where QA jobs just don't exist because companies think devs are trained to provide proper QA, but this issue could have been noticed by just clicking through each page.
Not a judgment by the way. I've worked in environments in which the release cycle is so quick that it's often easier to just push it live and fix it later, and the owners want you to somehow fix the bugs that are pilling up but without giving you extra time to do them. But if the owner gives you shit, counter by asking for time to design and implement a proper release pipeline. If he doesn't give it to you, then you remind him every time he catches a bug "A proper release pipeline would have caught this early."
The premise here is that the owner actually listens to you, even once, let alone on a repetitive basis. That's not the case.
Thanks for the comment.