logoalt Hacker News

cauchtoday at 8:11 AM1 replyview on HN

> 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.


Replies

skydhashtoday at 11:48 AM

YAGNI means you ain’t gonna need it. And if you can’t ask why A stays and B can’t be accepted, that just means you believe your reasoning is always the correct one, and your team leader is an wrong to not accept it.

And as I’ve said. If you state something and the person in front doesn’t accept it, you ask for his reasons. You don’t rush to prove yours.

You really can’t accept that the author knows about B and have a valid reason to not choose it, evenk if B is completely valid? Software engineering is all about tradeoffs. And it’s on the leaders to choose some, even if you really believe it must lean the other way.

show 1 reply