If you want the youtube version of this video, just click here and enjoy.
Context
You are at home and notice that there is water collec...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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've experienced this far too often. The formula usually goes like this: company hires me for specific reason, and to accomplish specific tasks. I was hired for this because they recognized the current team lacked these skills and I had years of experience. When I go to do those tasks, my approach is endlessly questioned, and my ideas are ultimately rejected because they aren't something other folks on the team have seen/done before (well no shit!).
Now, this would be understandable if I was introducing an entirely new stack or new programming language, but no, I was working with the exact same stack.
I could always defend my ideas successfully, but I would still be treated this way. At one point I was just thinking "Ok, so you actually want to do this job yourself, so I don't see why you hired me."
This kinda thing is also very hard to avoid when you're evaluating whether or not you want to take the job. In the beginning a rosy picture is painted of all the cool things you'll be building, and the autonomy you'll have, but after 6 months it wears off.
Long story short, good engineering managers and teams are a rarity!
I don't see much of an issue here...
This sounds like you don't want to work on a team, honestly. There is nothing wrong with other people editing your code and attempting to improve it, whether successful or not. Sure, it would have been more efficient to go straight to the senior dev, but if the inexperienced devs don't attempt to tackle these small bugs, they won't learn. You're advocating for robbing people of a learning opportunity, because you think you know better and were hired to handle everything. That's the irony here. The one with the ego here is you...
In your example, the senior dev exhibited poor communication skills. If they thought it was a carriage return issue, and the other dev says they've already tried that, then the first question the senior dev should have is "How did you strip it? Can you show me? I just want to double check so we can rule it out." The issue then would have been fixed even quicker AND the other dev would have learned how to properly handle this issue in the future. If the owner / dev gets pissy, that's his problem. Soft skills work wonders in these situations.
Judging the owner's programming skills and talking down about his abilities sounds petty; the fact that he even thought to try to strip carriage returns, whether he succeeded or not, puts his skills at least on par with some of the junior devs I've seen.
Calling the owner in this situation narcissistic is also petty. Being wrong about what a bug is doesn't make you a narcissist, nor does disagreeing with another dev even if they were right. We're all human and we're all fallible. This whole story could have easily gone the other way with the senior dev refusing to believe it was their code, when it was; I see it all the time.
The senior dev could have worked with the owner to diagnose the issue. Or when the owner said that it was a javascript issue, the dev could have said "I'll take a look, thanks" and then just moved on. Or the dev could have told the owner they could both try to tackle the bug at the same time, and see who could fix the issue first (a tactic I prefer, as it protects everyone involved.)
"Developers, stick to your guns when you can and when you're right." - I think this is your problem; devs should never assume they are right, especially on the senior level. Always question your own work, and the work of others. Be humble and accept that you may be wrong.
That's my opinion on the matter. shrug
This whole comment is based on the premise that the owner wants to work with others and listen to what they have to say. When you have someone who dismisses you without letting you finish, there's no amount of soft skills to counter that.
Thanks for the comment.
Sure, but that's a different issue than what you've described. That's an issue that's only fixed by finding another job. I had that at my last job. The environment was so toxic, we had an employee assault one of the co-founders; wrestled him to the ground. And the thing was, no one felt he was unjustified. It's easy to get into that toxic mindset where you hate your boss, and the way you interact with them is "justified" because they're a jerk. But at the end of the day, you should just leave the company. It can be hard, especially if you're not in a tech heavy city, but that's the best thing for you.
Your post is advocating to "stick to your guns when you can and when you're right" in the face of a boss who "dismisses you without letting you finish" and who doesn't want to work with others. That is, in my opinion, bad advice. It's not going to make him listen to you, it's not going to make your day more enjoyable, it's not going to make you feel appreciated. It's going to make the owner more pissy, make the environment more toxic, and then you'll go home complaining about how much of you hate your boss. Life's too short to settle for that, especially in our field in which developer unemployment is SUB 1%. The grass is greener, and you will find a job where either your boss leaves you alone, or will listen to you and work with you.
I can appreciate what you're saying. A lot.
I'm not sure why I don't fully agree with it so I'll think on this some more and try and articulate my position better.
Still, your opinion here is well taken and I especially appreciate the attitude you're trying to push forward here which, if I may sum up, is: "At least don't make things worse!"
Couldn't agree more. :)
Yes, don't make things worse but more importantly, look out for yourself. You owe nothing to your boss. If he's difficult to work with, and working with him makes you loath your job, please leave. It may shock your boss into being better with future hires, but at the very least you'll find something that makes you happy. Maybe I'm just projecting a bit here after dealing with a similar situation for 3 years, but I felt it necessary to stick around and deal with it because I had something to prove. Ultimately I was fired for publicly telling our CEO to stop sending passive aggressive chain emails to the entire company. It sucked at the time but I've been so chill and happy now for 3 years at my new job; now I wish I had left sooner. I could have saved my self from so much anxiety, depression, and anger if I had just left sooner.