zerocracyWe at Zerocracy, as you know, are strong advocates of freedom and the “No Obligations” principle. You, as a developer, are supposed to work only when you feel like it. If you don’t like the task assigned to you, you simply refuse it. No strings attached. However, Zerocrat will penalize you for such a refusal with a few negative reputation points, according to the §6 of the Policy. Why so? Here is the logic explained.
First of all, the penalty you are getting for refusing the task is not monetary. Your wallet doesn’t lose any dollars if you refuse a task. It’s only the reputation points that are deducted.
Second, ask yourself, why do you have to refuse tasks sometimes? In most cases, this happens when you can’t find a way to complete them within their allocated budgets. Why can’t you do that? Well, sorry for being harsh, but you can’t do that because you are not as good as Zerocrat expects you to be passionate enough.
I wrote a blog post about it some time ago, on my personal blog: Either Bugs or Pull Requests … or You Are Out. It basically suggests to call programmers “good” if they can find an exit from any situation. If the code is easy to understand, they make the changes required. If the code is too messy or the problem is too complex, they create new bugs, wait for their resolution and then continue. Eventually, they solve the problem anyway. Read the article, it’s short and will definitely help.
Thus, if you refuse a task, you are not skilled enough to solve the problem that is more complex that your average expectations. Do you deserve a punishment? I believe you do. Not merely for the sake of punishing, but in order to help Zerocrat understand who is who.
Zerocrat relies on the reputation of programmers in order to make the election decision for the next task. The higher your reputation the bigger the chance you will be assigned to the next job. Your refusals demonstrate your unreliability.
Thus, even though we don’t blame you for refusals, we want to know who is refusing more frequently, in order to make our management decisions. Sounds fair?
