Lately, I've been reading several Ralph Kimball books on data warehousing. If you want to learn about data warehousing, you start and often end with Ralph Kimball.
Years ago, when you wanted to learn about Oracle PL/SQL, you had to read Steve Feuerstein. For advanced SQL knowledge, Joe Celko was the dominant guy.
When Java was being democratized, Bruce Eckel reigned for a while, at least in my neighborhood.
I remember them because they were the top experts in their niche, so their names came up constantly. Truly remarkable knowledge, excellent teaching techniques, and unremitting enthusiasm on their topics, which they turned into great careers.
Now think about you career. It might be tough to be the national leader on C# or real-time trading, but how about something smaller?
How about being the expert in your own department on your internal data feeds or reporting capabilities? Or even better, a business-facing issue, like how you've implemented risk calculations or the workflow tracker?
To get there, first you have to know so much on your subject that meaningful conversations about it can't happen without you. But second, and this is easily overlooked, you have to be able and willing to teach everyone else, constantly and creatively.
Without the first, you're not an expert. Without the second, you're not someone others really want to confer with regularly. Combine the two, and you can discuss your subject at 14 different levels, from intern to senior management. Powerful.
The subject, of course, has to be somewhat deep and difficult, otherwise there's no need for your expertise. If there's a subject / business module / set of jobs that comes up a lot, and when it does, other developers try to deal with as quickly as possible (throw a patch at it and get out), that could be a good place to start.
No comments:
Post a Comment