Нет, не так. Задавай тимлиду вопросы, чтобы понять, что и зачем ты делаешь. Написать успешный и прибыльный продукт одному очень сложно, приходится работать в команде. Facebook, Google, Yandex — всё это продукты слаженной командной работы, и без коммуникации в среде разработчиков всё развалилось бы на части.

Коммуникация — это наорать и хлопнуть дверью. Коммуникация — разобраться с проблемой и решить её. Тебе про какую рассказать?

Навык коммуникации — это набор умений. Умение задавать вопросы, слушать и слышать, аргументировать своё мнение и не быть «токсичным».

Токсичностью называют отравляющую коммуникацию. Обесценивание чужой работы, манипуляция людьми, негатив, неконструктивная критика — всё это токсины, отравляющие атмосферу. Не будь бочкой с токсинами.

Писать код ты начнёшь после того, как устроишься на работу. А на собеседовании и во время испытательного срока тебя обязательно будут проверять и на умение взаимодействовать с коллегами. Например, вот это исследование [http://bit.ly/38Ekx5g] говорит о том, что коммуникация входит в топ-5 самых важных скиллов джуна.

Не всякая коммуникация одинаково полезна. Она может быть непродуктивна — отнимает время, но не приближает к цели.

Можно и без телевизора. Например, ты говоришь про апельсин, твой коллега — про синхрофазотрон, и вы спорите часами, обсуждая функционал.

Если ты не согласен — изложи это так, чтобы твой коллега сфокусировался на решении проблемы, а не личной обиде.

Твоя задача — решить проблему, а для этого, как минимум, диалог должен быть конструктивным. Нравиться всем необязательно.

Результатом спора должна стать решённая задача. Создать вокруг себя нормальную рабочую атмосферу можешь только ты. Без этого даже самые глубокие знания не защитят тебя от увольнения.

Не возражай, пока полностью не поймёшь чужое мнение.

Задай дополнительные вопросы и подумай: ты точно понимаешь, с чем именно ты не согласен?

Это субъективно. Даже если ты дизайнер — обоснуй свою точку зрения. Позицию «Я художник, я так вижу» могли себе позволить Стив Джобс и Пикассо. Но даже Стива, кстати, однажды за это выгнали из Apple.

«Большое количество операций плохо влияет на производительность» — это объективно.

Не погружайся в детали раньше времени. Если ты верно изложил ситуацию — не углубляйся в детали, если это никак не влияет на результат. Точно так же и с доводами коллег: придираться к деталям вместо того, чтобы обсуждать принцип — это и есть одно из проявлений токсичности.

Аргументируй, с чем конкретно ты не согласен.

Конечно. Например, если мнение оппонента основано на неполной или ошибочной информации, не учитывает существующих условий и данных — у тебя в руках есть доводы, чтобы исправить ситуацию.

Не переходи на личности, это не поможет решить задачу.

Например — если есть чёткое понимание и обоснования того, что при реализации идеи собеседника просто всё сломается.

Иногда при разработке можно принять неидеальный, но действующий вариант. Главное, чтобы он был жизнеспособным. Для этого даже придумали специальный термин: MVP, minimum viable product. Если предложение коллеги не дотягивает до этого уровня — можно и поспорить.