I know a lot of developers and most of them are "binary" people: They tend to see things as right or wrong, good or bad, elegant or kludgey.
In addition to (or perhaps due to) being binary, they have an opinion on just about everything: .NET vs. Java, emacs vs. vi, MacOS vs. Ubuntu.
Having these opinions and practicing a geek form of the Socratic method serves us very well in the technical portion of our lives. The best programmers I know have both the depth and breadth of knowledge required to support their position against all other arguments. The best developers I know are the ones who know when to be quiet.
One of the secrets to being a Big Swinging Developer is to know when to be null. The realization that you don’t have to be right or wrong is not only liberating, it’s a great boost to your career. The key here is balance. On one extreme you have the folks who jump into every discussion within earshot. At some point they usually get labeled, "likes to hear himself talk". The other extreme is people who literally say nothing. They stop getting included in important discussions because they offer no value. So how do you strike the balance? Start asking yourself if what you’re considering saying will be valuable to anyone other than yourself. Is it actionable? Is it something that needs to be said? Is it relevant? Is it inspirational? The definition of "valuable" will change depending on the context of the discussion, the important thing is to think before you speak.
"Make something people need and you’ll make a living. Make something people want, you’ll make a fortune."
There are lots of developers out there with "job security". You know the type: they’re the ones that know all the system trivia. They’re the keepers of the system’s oral history and when something extraordinary needs to be done with the system, they’re who gets tapped. These developers usually find themselves in this position due to lack of documentation, bad design, planning failures, or some combination of these and a dozen other things. In some situations, they become a "required" component to keep the system running. This may seem like great position at first, but try taking a vacation or getting promoted when you are a required component: at best it’s not fun, at worst it’s impossible. Heck, even getting sick is more miserable if you have to keep things running while trying to recuperate.
While it may seem more risky, you’ll be better off if you’re desired, rather than required. Pretend that every development iteration is your last. At the same time, pretend that you are your own replacement and it’s your first day. What information would you want? Would you know how to find it? Does the body of documentation relay not only what the system does, but what you were thinking when you designed/built it? Does it build easily? Does it have good test coverage? How about a decent installer?
Having all of these things in place makes it a lot easier to transition to new/better opportunities. But that’s just the medium-term benefit. The short term benefit is that by keeping things in order, it will force you to work better and be both a better developer and a better employee. In the long term, your reputation will be well served by being known as the Big Swinging Developer who "does things right" and "leaves things in order".