Ever feel like you're just not listened to. That your warnings fall on deaf ears and the wrong decision is being made. This is something that a lot of developers feel, it's called the Cassandra Syndrome.

Unfortunately, it happens to all of us because we're not good at selling our ideas and selling ourselves. We're shrugged off with various reasons. The unfortunate truth is, this is the right call, not because we're wrong. More often than not, we're completely unable to properly reason and sell what we believe. We often claim trust we haven't yet deserved this. Our challenge is to break through this pattern.

First and foremost, we have to choose our battles. Sometimes there are certain political reasons (whether valid or not), that this happens. Sometimes things are decided, whether or not we agree to them.Trying to change these or (constantly) warn against what is about to happen, tends to cost you credits. Credits in fact are very important and you need credits when you pick a battle you feel you can win. Getting credits then is very important, a good way to get credits is fulfilling promises and getting done what is asked. Really, just doing your job is the best way to get credits.

What in fact doesn't get you a lot of credits is knowing something is going spectacularly wrong and fixing it before it becomes a real problem, that actually doesn't help you a lot. As someone that's committed to a successful product, you want to do the best thing for the product, which means fixing problems as well as you can. There's just a problem with that strategy, you're not doing what is good for you nor the product. Ironically, if you hide the problems there are, you're not just taking credits away from yourself, but also preventing problems that need fixing from being visible. You want (and need) the visibility and opportunity to show that you:

• Know what's going on,
• Know how to fix it,
• Show that it's in the best interest of the product (and thus its users),
• Show that it's necessary for the success of the product.

Then there's being right, "nagging" and being right is something I often did, but rarely helped me. What did and does help me is being able to get done what I promise. Given a problem or feature to fix or implement, I can give relatively good estimates about how it's going to get done (when and at what cost). This helps me most of all, because people started trusting my opinion on what I can get done, how it's done and the subsequent quality. I'm also in an environment where this trust _can_ be granted, also very important. If you earn a lot of trust, but work in an environment that doesn't cherish this, you can never apply this. In my experience, projects done in ITIL environments tend to focus on the quality of the process instead of the quality of the product (as the quality of the process should guarantee the quality of the product, rarely this holds), these environments do not cherish credits.I certainly have a lot to learn still. Like trying to focus on what I can do, instead of complaining about what can't be done. But these things have helped me to act in better interests of those that I work for.