@Keppla
So, basically you are saying, that the results (failing or succeeding) do not count (…even if you happen to be right), but only that the team agrees?
No, I don’t say that. What I am saying is that sometimes you don’t need to have a perfect solution in order to succeed. It is better to reach a decision that lets the team move forward than to waste a lot of hours arguing technicalities. So you stop arguing, for the team’s sake.
In the very rare case where 1) a team of professionals are total idiots who are going to fail totally unless they listen to you and 2) they refuse to listen to you, then you should still stop arguing and just quit. For your own sake.
The examples I gave were just examples from Joels article but I still want to respond:
Source control: You use source control because it is effortless and it will save your ass one day. It takes no time at all.
Specs: You write specs because you yourself will want to know what it is you are supposed to do, verify it and make sure it makes sense before you go ahead. You also want to verify your code against it later. You can also show a spec to the PHB and ask him is this what the program should do? and be sure that the pogram is doing just that.
Documentation: You write documentation so that the users know how to use your program, saving you from tons of support calls and also giving the impression that the application is being maintained by someone who cares.
The trick is to stay positive and do the best you can, instead of finding reasons or excuses to NOT do the best you can.
The difference between pessimistic slacker and honest critisism is that the honest critisism will offer an alternative action, not just empty opposition. Let’s do this other thing! instead of What for?
With this in mind, the answer to
Am i a pessimist, a jerk, or a slacker because, or do i just critizize honestly and try to save time?
based on the examples you gave, is in my opinion: Pessimistic slacker.