I think his point is valid even if slightly tongue in cheek. Bugs are defined by the contract / specification not wishful thinking.
If this is how you do your work, you are asking for a computer to replace you! We should aspire to be better than this. It’s crazy to me that people take massive salaries and expect other people to spoon feed their tasks to them.
I remember being one of two software engineers working on a project in a small company. We were cooperating with two bigger companies delivering other parts of the system.
I kept asking myself: "These guys have hundreds of well paid engineers working on this, and they never deliver! Are they sabotaging the project?".
In the end we delivered the finished prototype and the customer ran a 48h acceptance test, their parts fizzled out almost immediately, while ours just kept running.
It took me a few years and joining a bigger company to notice that thinking about what you're doing is not expected in bigger corporations, where everything is bureaucratized. Also if the company is big enough it can shift the deadlines set by its customers. It drove me near madness whenever a colleague said something "wasn't their job". I never heard such an attitude before, and these people were paid twice as much as in my previous company.
I still, to this day, hope that a lot of these people get replaced by computers. Defective programs can at least be improved.
“Not my job” people tend to be the most frustrating folks to work with. While I understand wanting to mainly do the work you were hired for, there are always going to be times where you have to roll up your sleeves and do something different.
I wish I was the kind of person who would thrive in that environment because it sounds nice, but I’m not wired that way.
"When I pass X in, I'm not getting anything back - no error, I can't see the logs. Can you assist?"
"Not my job - you figure it out. We can't be expected to know how everything works."
"Yes but... this is literally something your team wrote in the last 3 weeks to support the larger project we're all on, and I was told to make my code work with yours. Have you ever tested taking input? If so, what am I supposed to pass in to your system?"
"Not my job - we're not here to babysit you - go read the code."
Later... someone else...
"Why are you spending all the time trying to trace through this code? You just have to ask. You have to learn to talk to people."
I sent over screenshots of the previous 'conversation' and got nothing back.
Thankfully this doesn't happen very often, but I'd realized that this org had segmented some teams so poorly, and put such deadlines on, that the culture of half the teams was "do minimal work and throw it over to someone else". It was more confusing because I interacted between a few internal teams, and some teams literally did not believe other people behaved this way. Even with written evidence, the problem was always assumed to be "oh, you're just not asking the correct way".
I’m not sure where in my comment you got the idea that I was advocating for engineers to have their tasks spoon fed to them by other people. My comment is simply about reading comprehension and not arguing against strawmen.
Do you categorize thinking that JSON parsing takes at most O(n log n) time as wishful thinking as well?
It's humanly impossible to code for contract, that's why generally it's important to strive for no surprises in an API. This is the only way to build more and more complex software over time.