As a Software Development and Support Engineer (SDASE), I’m bullshitted.
There’s a social economic pattern that applies to being a SDASE, that I want to share here.
The pattern is that of a SDASE being bullshitted(*) by the SDASE’s colleague. For example this pattern may be performed by the colleague in an attempt to see whether the SDASE knows they’re being bullshitted.
Once a SDASE is aware that this pattern is commonly practiced by their colleague, they can act properly and call the colleague out for bullshitting, confront their colleague for testing them, or call the colleague out for being incompetent or unknowledgeable.
Why blog about this? Isn’t this something most people learn about before age ten? I think that one’s never too old to bullshit, be bullshitted, to learn/recognize for the first time that being bullshitted is a “thing”, or to revisit the concept. Some things, some people learn when they’re a child, and other people don’t learn the same lesson until well into adulthood.
This raises some questions. How do I recognize bullshit? Looking back on my life, which were the times when someone was bullshitting me and I didn’t know it? If I didn’t think it was bullshit, then what did I think was happening?
Reflecting back on my life, there have been numerous times when a colleague has said something to me that directly contradicts something that I know we both know. Without suspecting bullshit, in the past I would have reacted one of two ways: A., I felt that the colleague was unknowledgeable or incompetent, or B., I was confused why they would say that when I had thought they knew otherwise. Not suspecting bullshit, I’d need to ask for clarification.
Going forward, as a SDASE now that I know that occasionally, as a routine test, people will bullshit me, what I’ll do is point out to them that they’re bullshitting me — point out to them that I know that they’re testing me — and then get on with what matters.
There is a beauty in bullshit though. That is the person being bullshitted only has one real option — to call the bullshitter out on it. This is because whether or not its a test, the bullshittee, being a professional, should be correcting the bullshitter on the misinformation or on the discrepancy.
Another thing I’ve found is that looking back I can’t help but think of those times when someone had in the past bullshitted me, and I failed the test — failed to call them out. Thereupon they (the bullshiter) saw that I (the bullshittee) had failed their test. After they realized that I had been easily bullshitted, that I had failed their simple test, I can’t remember one of these colleagues/people calling me out for being easily-bullshitted.
That raises another thing about bullshitting. One can’t expect the colleague to take one aside later and say something like “Hey, by the way, this morning when I said that I was bullshitting you — I was testing you to see how you’d react.” Maybe because after the colleague sees the result of the test, there’s no added value in addressing the interaction any further.
In conclusion, I’ve noticed a social economic pattern that is a colleague bullshits a SDASE — tells a little lie to test how the engineer will react. As a Software Development and Support Engineer, now that I know that this kind of testing in some professional circles is a common practice, I’ll be able to react appropriately.
(*)being bullshitted: 1. When a colleague asks me a question to which they already know the answer, to see how I will respond, I am being bullshitted. 2. When a colleague makes an untrue statement and observes to see whether I will point out the falseness of the statement (see whether I will call bullshit on them), I am being bullshitted.
Edit: This post was previously published at: w̶i̶e̶l̶d̶l̶i̶n̶u̶x̶.̶c̶o̶m̶/2016-05-18-software-engineer-being-bullshitted.php
[2019 edit: Moved to: https://investorworker.com/2016/... .html.]