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.