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 collecting somewhere in your house. Maybe a pipe is leaking. Maybe it's a leaky faucet.
You have to call a plumber, which you do, and the plumber takes a look and figures out the problem. You get a quote for the work and you hire the plumber to take it on.
The plumber begins the repair work and you walk in and momentarily stare over their shoulder as they use a wrench on something.
After a minute, you grab the wrench from them and say "No. You're using the wrench all wrong. Here, let me show you how to properly use a wrench." and begin to take over.
This example and variances of it have been used a lot online and otherwise.
I think the example, while perhaps extreme, does have a fundamental truth behind it and that is why it's an oft used one.
The predication
If you're hiring someone to do a job then it means that, most likely, you are hiring that person (or group of people) to do something you cannot do. In other words, knowledge and then practical use of that knowledge to achieve goals are something you typically pay for because you lack it yourself (in certain areas).
That's not 100% true every time. You might very capable of doing something yourself but simply don't have access to the resources required like someone else does or you don't have the time or any other number of reasons here.
But that's not the focus of this topic. The focus is when you really don't know much, if anything, about being a plumber but your awesome skills with a wrench make you think you do.
The problem
This creates a lot of contention and conflict, no doubt.
I have experienced this myself and have seen others undergo this kind of situation.
The whole problem is in the title.
An example
There was a developer who was working on a website as the senior developer. The owner of the company saw an issue on the website before anybody else (just a timing thing). The issue was that lowercase "r"s were being printed on the screen on various parts of the content. This seemed to boil up out of nowhere.
The owner fancies himself a programmer but he is absolutely not. You cannot even stretch your imagination to make him fit that title. His job as an owner is very very distant from being a programmer.
Therefore, it's safe to say his knowledge is limited in the programming field and it makes sense to have a senior developer on board.
However, once he saw this issue with the "r"s he started jumping in to fix it himself. He didn't ask the senior developer to look first and provide feedback. He didn't include anybody. At all. He just jumped in and started hacking away at the code to fix it himself. This was not the first time he's done this and he usually does it because he thinks he can do it faster than anybody on the planet.
After some undetermined amount of time, he finally pulls the senior developer in and tells the developer that it's a javascript issue and the developer has to fix it.
The developer says "Mmmm why?" and the owner says it's because the developer recently did a push to production with a bunch of javascript updates. The developer says "Well I'm pretty confident it's not my code that's causing this and the timing seems off because I pushed my code two days before this issue appeared but I'll look" and off the developer goes to look.
Within 10 or 15 minutes, the developer comes back and says "Ah it looks like a carriage return issue" (as in, \r) and the owner goes "Nope, I already tried to strip that out and it didn't solve the issue, it's javascript" and the developer is scratching his head now.
The owner continues "Plus, when you highlight the text on the screen with the Google Chrome inspector tools, you'll see this '==$0' text next to the 'r' and that's javascript!" implying that this must still be a javascript issue.
The developer retorts with a confident no because that '==$0' thing is Google Chromes fancy way of allowing you to easily select a chosen DOM element in JS for efficiency. It has nothing to do with Javascript outputting "r"s to the screen.
While this exchange was going on, the developer ended up fixing the issue entirely by properly stripping out the carriage returns in the output.
The problem (expanded)
That whole exchange happens (in some form or another) too many times between developers and leaders or employers around them. There are too many people who think they know better than the developers who are trained in the craft.
Look, if you are so narcissistic and you think you know so much about programming to the point where not only are you willing to muck about with what the developer is doing and you're basically willing to pay a developer to sit around while you do their job for them then... save your money, fire the developer, do it yourself! If you're willing to ignore evidence that your developer is doing the right thing then go do it yourself.
Seriously, the entire thing is so nonsensical.
A proper question
As a developer, if you find yourself somewhere like that, you need to ask "Am I being productive and valuable to the company?" and the answer may be no.
Maybe you're being hampered from being valuable. Maybe you need to leave, then.
In particular, if it's so toxic that you take that home with you and you're walking around dejected all day and you hate the idea of waking up in the morning to get back to it, then I would argue you definitely should leave.
But maybe you can put up with it and maybe you can continue to be productive and valuable. That's up to you (and the employer in some small part at minimum) to determine.
But be honest with yourself about it!
The positive
A situation like this does have an upside. We shouldn't be all high and mighty and egotistical as developers and think that every word we utter out of our mouths is golden truth to be worshiped by the masses who should throw money at us.
You should be questioned (in fairness and within reason) and you should be prepared to defend your stance with evidence or proof.
This kind of exchange can train you to build the internal tools you need to do that on a continuing basis. That's not a bad thing.
Conclusion
This kind of thing needs to stop. If you hire someone to do a job, let them do it. It's fine to assist and be supportive. But not to the degree described in this post (or video) and it benefits nobody to treat your developers like that.
Developers, stick to your guns when you can and when you're right. You don't have to accept toxic and hostile work environments but you do have to strike a balance in environments where people are questioning you as part of a healthy process.
Latest comments (11)
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.
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!