The difference between "knowing" and knowing

Let's explore the dangerous land of the elitist in the workplace. I've been one, how about yourself? Do you do enough to defend against one?

The difference between "knowing" and knowing

I don't think I have ever talked about work personalities. There is a lot of them out there. In the software engineering realm, you will probably find a lot of people who are confident in what they say until they are proven otherwise. But there is another personality type that I want to touch on that I have had the great pleasure of working with lately. That would be the "I'm better than you" personality or better yet, the elitist.

I struggle with that personality a bit. Partially because in our line of work, you have to prove it for me to really give anyone credit. And no, it's not this massively high bar. It's usually pretty obvious if you know your stuff or if you are hiding behind talking the loudest. So after working with a bunch of different people you start to recognize those that really understand things and those that act like they know things. Hell, I was - or am I still 🤔 - one. (Someone please, I need to know)

You might know these kinds of people as those that often come to you. They come to you because they were trying to integrate with something you wrote and its not working. And they always act like they did everything perfectly.

"You're shit's broke", they might say in a passive aggressive professional way.

Being the astute person you are, you would begin asking questions, concerned about the quality of service you have provided these people. You are concerned because you value quality and being on the other side of that, you understand immediately where their frustration might be justified.

Alas, it can't be justified... Not with their reasons.

You slowly start to unravel the long thread they wound around themselves to place them in this exact predicament. You begin to look further and immediately look at dates of your last release.

Aha! You haven't deployed in over two months. You even went out to prod. So it begins to be less and less likely that you caused any of this kerfuffle. You also remember you have three other services using this project without issues. So you ask a few more questions.

"What kind of error did you receive"

They show you a graphical interface that has red text on it.

"Internal Server Error"

"Is there anything else you can provide me? A stack trace? A network call?"

They shuffle around each other trying to figure out how to see internal errors. They hand over a massive sum of text completely unformatted. You spend a few seconds placing it into your favorite text editor, formatting it and extracting the pieces you care about.

The very hard to decipher message reads, "401 - Not authorized"

"What kind of things have you change recently?"

"We change a lot of things on our releases"

"Well it says here your login token is bad. Did you login?"

They sit there for a second and ponder about... Well who knows, because they next thing they say shakes you to your core. You probably won't be able to have children after such a shaking.

"Oh, maybe we didn't run that script that we run once a day to login"

You begin the ritual of your people, 🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦🤦.

This is only one of many experiences you may have experienced with these kinds of people.

I don't mind helping people discover the issues they are running into. I am very open to the fact that any service I write may have a bug. But I also have a pretty high confidence level in my products. There is a particular practice I like to follow that allows me to shift the blame away from me or my services. So long story short, lets go over that.

When you are building a service, first make sure you understand the business requests. If you don't know what your service is supposed to do and why then you are going to have a hard time being confident when someone comes up to you about your shit being broke. But that's not even the most important thing you should do.

Let me ask you this, where does your confidence come from when these kinds of situations occur? Do you assume you know what is going on in your service and preemptively turn away someone blaming their implementation?

I've done it. Nothing to be ashamed of. Just be aware that it starts to discredit your word. That's the biggest problem I have with the people from the example above. They immediately jump to the conclusion that the service they are integrating with is the issue. Even if they notoriously fail on a variety of things and it's more often than not their issue. Check yourself before you wreck yourself. But that isn't even the most important thing you should do either.

The most important thing you should do is make sure you have written enough tests. Testing is something that I could talk about in another blog post because you can write incorrect tests. Or I should say, you can write tests that are not useful. They fluff the stats. So as a rule of thumb your tests should be covering at least the contracts you provide in and out of your service. You should also have at least 2 test cases for every business requirement. A pass  and a fail test. But I am sure you can find a lot more than that.

The reason testing is the most important is because you will never regress on a test corrected. That is where I get my confidence. I know I can deploy my stuff out every time knowing that I didn't introduce a bug around core business logic. And if I did, I can't deploy because my build fails and won't allow me to push.

Three things. That's all you need. Test your domain. Know the domain and why it exists. And check yo' self before you go blaming someone about your problem.

If we were working together, my dear reader. By the time I come to you at your desk, I know there is something wrong with your stuff. I'm not just coming over to your desk because I think that it's your fault. I know it is.

You can be the person that comes to my desk and tells me my stuff is broken. But man, sending you away when it isn't my problem and it is actually yours is my favorite part of the day.

Just to be fair I don't aim to do that to people. If someone was to come up to me and ask me a question about something that I had worked on. I am more than willing to help out so they can understand what is going on. Sometimes it is a journey for both of us to rediscover something and maybe even discuss how business requirements have changed.  You help me and I'll help you kind of trust.

I feel like most people can kind of tell what mindset a person is in when they approach someone. At least the ones at the beginning of this story seem to be transparent. So my tolerance for the kind of person who goes blaming others when they haven't done their own homework on why, is particularly low.

Being on the receiving side of the accusation, there is also something else to keep in mind. You should really try to understand them and their point of view. I've fallen into this where the above example has happened a few times and I start to dismiss their concerns as soon as they approach me. I become the elitist. It's important to not lose sight that you could still be wrong. That they are actually coming to you with a valid problem.

So with that, Check yourself before you wreck you self. Test the business logic to a near disgusting but valuable amount. It will save you in the long run. Understand the domain and why you are implementing it. Lastly, keep things in perspective, you can be wrong too.

With that, I know - you know that I know, you know your shit.