Hacker News Reader

> So this "Cult of Positive Attitude" really does exist, can be pervasive in a company to the point of being toxic, and sometimes the best solution is to just leave, which is what I ended up doing.

This. The solution to the Cult of Positive Attitude is not to lament positivity, or long for the day when healthy cynicism is more highly valued. It's to go somewhere where you have legitimate reasons to believe that things are better than they are worse.

Put simply: the problem isn't positive attitude. It's positive attitude that is in direct conflict with reality.

> Put simply: the problem isn't positive attitude. It's positive attitude that is in direct conflict with reality.

I disagree that an attitude in conflict with reality is a problem, not for those that have it. If you haven't seen it already you wouldn't believe just how long a company or group within a company can muddle on without any grasp on reality whatsoever. Of course you are better off leaving while the termite-eaten building hasn't collapsed yet, but in this recession that is easier said than done.

> You can't just say "No". You need to say "No, these are the reasons why, and here are my solutions". It's too easy sitting back and pooh-poohing every idea, and there are a lot of people that love doing that. Coming up with solutions is the right way to approach it, because people really don't like hearing "No".

Because people don't like hearing "No", its even better to not only come up with solutions, but then also to present them in the context of "Yes, we should do what you are suggesting, with these refinements" rather than "No, instead of doing what you are suggesting, we should use this alternative".

The substance is the same, of course, but it provides acknowledgement and validation to the person making the proposal rather than dismissal and rejection. This can make a very big difference in how people respond.

"Yes, we should do what you are suggesting, with these refinements"

That would only work if the proposed solution was somewhat close to being viable. But if the only way to succeed is to throw the existing solution out and start from scratch, it's hard to find a diplomatic way of saying so.

What I find usually works is working back from the proposed implementation to the goal that it is supposed to serve. You can usually do this in a validating rather than rejecting way. Once you've identified and validated the goal you can address cover a with the proposed approach and present alternatives without the proposer viewing it as a rejection since you got to common ground on what you are trying to achieve before proposing alternatives.

Often the problem with an initial "no" to a proposal is that the proposer identifies the proposal tightly with the purpose and suggesting an alternative to the proposal without validating the goal reads as rejection of the goal.

> You can't just say "No". You need to say "No, these are the reasons why, and here are my solutions".

Sometimes, you don't have the solutions. But just because you don't have the solutions doesn't mean the problem doesn't need to be brought up and considered.

Sounds a lot like what I'm experiencing in my current role. We are supposed to be launching in a month and the product is riddled with problems. From creating 5+ threads per user and not being horizontally scalable. Offered many alternate solutions, but none of them ever get noticed.

Many consultancy companies define a project's success in terms of money extracted from the client.

You were probably given a poor performance review because it was actually your vocal opposition that endangered the success of the project.

I'm not saying this is the OP's case, but when I worked for a small dev shop, almost all my co-workers would grumble and complain whenever a client asked us to do more work for them. I'm not talking about scope creep or unpaid additions. I'm not talking about requests that were impossible or incoherent or outside our expertise. Clients would ask us to give an estimate for adding feature X, and everyone would complain! I've noticed the same thing in other developers many times since then, so I've tried to practice saying instead, "We'd be happy to do that for you! It'll be $X." (or more realistically, "I'll get you an estimate by tomorrow/Friday/next week.")

My other favorite technique is to put a price tag on things that are technically hard or "impossible." I like to say that nothing is impossible, but some things are expensive. I think edw gives a similar response to client inquiries.

Your points are all good tips on how to run a 'proper' dev shop.

I was more cynically referring to big consultancies that intentionally complicate/delay a mission critical project in such a way that every time the new budget runs out just enough progress has been made to make the business decide to throw another couple million at it hoping to finally get a product delivered.