Antipatterns should be ameliorative. For that matter, patterns should be too. For that matter, so should you, at least in the way you do your job.
Ameliorate (verb): to make a situation better or more tolerable
I've been talking about antipatterns. It's not just enough for an antipattern to give a common solution, to say "Bet you did this, didn't you? D'oh!" It then needs to offer a preferred solution. This makes the document ameliorative; it helps the reader understand not just why their situation sucks, but also figure out how to make their situation better.
Any pattern should be ameliorative. It tells the reader what to do to make their situation a good one, perhaps better than it was, in any event better than it would be if they applied a less-than-best practice. If a pattern documents an approach which is not ameliorative, whatever it's documenting is not much of a pattern.
When you're doing your job, are you ameliorative? Are you making the situation better? Or worse? Perhaps you're trying to make it better but the situation fights back; that's just a bad (but common) situation. But in a reasonable situation, if you're not helping to make things better, why not? See the importance of leadership. Leaders ameliorate.
So, be ameliorative. Get out there and ameliorate.
Bobby Woolf: WebSphere SOA and JEE in Practice
Matching: leadership X
It seems to me that there are two main aspects to doing a good job in a technical role: Technical proficiency and leadership ability. Many of us tend to focus on the first one; we need to focus on the second one as well.
By "leadership," I don't necessarily mean "being in charge," I mean being influential and persuasive. You've probably at some point worked for a manager who was a poor leader but nevertheless was still your boss. Leadership is not a title that can be bestowed upon you by your company or community; it's a quality of how you conduct yourself and work with others. Many development teams have someone who, when he/she speaks up, everyone listens to what they're saying and is inclined to go along because they're usually right; such a person may be "just a programmer" like everyone else, not a project lead or a manager, but they are a leader because they suggest a course of action that the rest of the team tends to follow. That's leadership.
There's a fairly extensive thread on leadership on Ward's wiki. For example, see What is leadership? and Books on leadership. Another Web site, The Art and Science of Leadership, looks pretty good.
In my author spotlight, about half of my recommended reading list is non-technical books, many of them on leadership and related topics: see Becoming a Technical Leader, The Fifth Discipline, and The Servant. Heck, even The Pragmatic Programmer has a lot of leadership aspects to its technical advice; so does Extreme Programming Explained.
So maybe this sounds great but unrealistic. Maybe you feel like just a lowly programmer on a lowly team; what can you do? Here are some concrete suggestions:
It's really just that simple. Think about it: Aren't these the kind of people you'd like to work with? Think about someone you do like to work with: I bet they do these things.
Some organizations may not be very supportive of this. For example, when you report problems like you ought to, the organization may avoid addressing the problem and instead shoot the messenger (which is you). In this case, you have an even more challenging leadership opportunity; as one friend of mine likes to put it, "You can either change your organization, or you can change your organization."
Three new authors have been added to WebSphere: Author spotlight: Joey Bernal, Steph Parkin, and me.
The Author Spotlight highlights people who have published a lot of articles about WebSphere products. Each author usually has his or her themes, so it's good to find an author whose themes match your interests. For example, Joey writes about Portal, and Steph writes about how to use tooling like RAD 6.
The spotlight on an author is useful in two ways. One, it lists in one place all of his/her articles and other publications, so that you can more easily find what all he/she has written. Two, it lists other publications the author finds helpful, which makes a good reading list of other stuff for you to go check out. For example, both Joey and Steph recommend The Soul of a New Machine, so that sounds like a good book to go check out.
In my recommended reading list, I've listed the books I think any J2EE developer should have on his bookshelf. Need to learn UML? I've listed a book for that. Use cases? A book for that too. Lots of patterns books. And some books on leadership too, because I'm finding that ability to be as important to a project's success as technical ability.