For example, there is a common snippet in JS to get a default value:

function f(x) {
    x = x || 'default_value';
}


This kind of snippet is not easily understood by all the members of my team, their JS level being low.

Should I not use this trick then? It makes the code less readable by peers, but more readable than the following according to any JS dev:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}


Sure, if I use this trick and a colleague sees it, then they can learn something. But the case is often that they see this as "trying to be clever".

So, should I lower the level of my code if my teammates have a lower level than me?

Ok, here goes my take on this big and complicated topic.

Pros for keeping your coding style:

Things like  x = x || 10 are idiomatic in JavaScript development and offer a form of consistency between your code and the code of external resources you use.
Higher level of code is often more expressive, you know what you get and it's easier to read across highly trained professionals.
You'll enjoy your job more. I personally value creating pretty code. I think it brings me a lot of satisfaction in my work.
Generally it creates more readable style. Sticking with the idioms of the language can be very valuable - they are often idioms for a reason.

Cons for keeping your coding style:

It'll be harder for the lower-level programmers to keep up. These are often the people maintaining your code and the ones who'll have to actually read the stuff you write.
Maintainers of code, often JavaScript code come from other languages. Your programmers might be competent in Java or C# but not understand how and when JavaScript differs exactly. These points are often idiomatic - an immediately invoked function expression (IIFE) is an example of such a construct.


My personal opinion
You should not lower the skill of your code. You should aspire to write code that is expressive, clear and concise. If you have any doubts about the level of your team  - educate them. People are more than willing to learn than you might think, and are willing to adapt new constructs when convinced they are better.
If they think you are 'just being clever,' try to argue your point. Be willing to admit that you're wrong sometimes, and no matter what, try to keep styles consistent throughout your work environment. Doing so will help to avoid hostility.
The most important thing is to stay consistent.
A team's code should be written as if one person coded it. You absolutely have to agree on coding guidelines. You should abide by those guidelines. If the coding guidelines specify that reading optional parameters should be done in the 'less clever' way, then that is the way.
