Know Thine Product's Language

As a technical tester (SDET), you are expected to help find bugs that are written in the programming language used by your product team (SDETs commonly contribute by writing test code and tools). To this end, you truly need to understand and master that language (especially if working with inexperienced developers). As such, your test code and tools should be written in the same language as the product code. In fact, let me Noguchi Rage that:

Your test code and tools should

 be written in the same language

as the product code.

Some of the very best testers I've ever worked with are awesome developers and know many of the languages' vulgarities that often plague others. Unfortunately, I've also seen a lot of testers spend their time writing tools in unrelated languages. Now, of course, there is some balance that needs to be maintained around picking the right tool for the problem, but if multiple tools fit just fine, choose wisely. If you are splitting your efforts across multiple technologies it will be harder to become an expert in the language that matters the most for your product's success.

This also comes into play while debugging the application code. Without continual exposure, it will be much harder to diagnose and root cause bugs in your areas of responsibility. And in a very timely fashion, Dmitry made a similar comment about this on his crash dump analysis blog: "The lack of sufficient unmanaged [re: native] code programming experience might partly explain many analysis mistakes".

To be exceptional at your job, you will want to condition yourself appropriately. A sports metaphor fits nicely here; there is a significantly small percentage of professional athletes that can successfully compete in multiple disciplines. The technology profession is no different here - professionals need to train to be the best they can be, and so do you. Choosing the correct (daily) training regimen is import to you and your team's success.