If you want the youtube version of this video, just click here and enjoy.
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.
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.
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.
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.
While this exchange was going on, the developer ended up fixing the issue entirely by properly stripping out the carriage returns in the output.
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.
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!
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.
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.