alt Hacker NewsYour argument is always about:
We need to to task X today, we're going to do Task Y later. But we need both task X and task Y to complete the whole project. But the solution for task X is wrong because it conflicts with task Y. And when we get to task Y, we won't be able to deliver. And Chet know this. But the author don't want to listen to Chet, and the author is wrong for that.
The project is already defined. There's task X to be done, and we have settle on a solution A for it. Chet is the one who will be implementing it. Chet uncovers a situation that leads him to believe that the solution B is better because of a constraint that will come in effect in 3 weeks. He says that he can implement A, but because we're going to need B in 3 weeks, let's scrap A and go with B instead. Now the author knows both A and B (and maybe B was discussed beforehand but Chet don't knows about it),and says that B don't matter, A is good enough.
Instead of asking why, Chet decide to argue for the validity of B. The author reiterates that B doesn't matter. At the end Chet decides to walk away. And never wanted to learn why A is the better choice when B seems to be perfect.
And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why, you don't immediately try to prove your position. Imagine doing that in the army.
> While the situation is
BS. You have no idea if it is the case, you don't listen to Chet. You __assume__ that Chet's solution is motivated by a different goal, but you __shut him down before he said so__.
You now invent things that are never described in the scenario, to try to badly justify that somehow the author's ASSUMPTION is justified. But the problem is that even if what you said happened, the author's assumption is still an assumption: the author is a bad lead for not verifying at 100% that Chet is indeed talking about the same B that the author has in mind. And even if the author does it behind the scene, the author is a bad lead for not being fully aware that he should have writing this step explicitly within the scene, as it is a crucial step for the judgement and should be evaluated before acting as he did.
> Now the author knows both A and B
The author SHUT CHET DOWN BEFORE Chat explains what he is talking about. How does the author even know that Chet's complicated solution correspond to B?
I guess you will say "but Chet told him behind the scene" or a bad argument like that. Which is of course changing the scenario as described in the article (something you were incorrectly whining about but have no problem doing it yourself).
But also it justifies my criticism: even if Chet's explanation happened behind the scene, it means that when you read this scenario, instead of thinking "oh, red flag, the author should make sure he understands exactly what Chet is talking about", you just __jumped to the conclusion__ that this situation was a "constraint from a hypothetical future" situation where what you had behind your eyes gave you no indication it was. And you __invented__ without any justification, that elements that are not within the scene occurred just to justify a posteriori your conclusion.
To take a more extreme example: it is like if the article says "and then this black person is arrested", and when someone says "it is strange, I don't understand on which basis this person was arrested", and someone says "well, when reading the article, I just assumed that the black person is a thief and that they saw it behind the scene". This last person reading of the article has highlighted his prejudice, his bias. Same here: you ignored the possibility that it may be a "Task X vs task Y" situation because you __blindly assumed__ it is the situation that YAGNI has put in your head.
> and maybe B was discussed beforehand but Chet don't knows about it
And maybe the unicorns have whispered to the author's ear what Chet was talking about.
You are so full of shit, you are just making excuses and grasping straws to pretend that the terrible judgement of the author was somehow justified behind the scene. Do you even realise that?
> I was Chet at one time ...
I am not surprised at all. But the problem is that not everyone is as bad developer as you are: sometimes, they found __proper problem__. In the exact dialog, the author shuts Chet down before he can explain the problem. Chet even said "you don't understand ...", trying to say to the author that what he is bringing is not what the author seems to understand it is. That in itself should give you pause: "wait, are we sure Chet is not trying to talk about a problem that the author genuinely missed", but it did not because you were unable to mentally conceive it may be the case.
> And when someone higher than you (and better placed to have more information about the constraint of the project) refuses your idea. You ask why,
Again, if you are a team leader and you think that you will never miss anything or that you are the only ones in position to discover things that has been missed, then you are such a shit team leader. With a fragile ego.
> Imagine doing that in the army
WTF? What kind of argument is that? Your argument seems to boil down to "reSPecT my auTHorItaaa". As a team leader, I am smarter than that: I know that sometimes things will be missed, and I know that it is better for everyone to be in a situation where anyone can bring it to attention.
And, yes, sometimes they will bring to my attention things I already know. But I listen to them first. It does not change ABSOLUTELY ANYTHING, and if someone says the opposite, this person is full of shit and does not know what they are talking about.