Софт-скиллы, которым не учат в курсах
Вот представь, ты прочитал весь мой канал, изучил синтаксис вдоль и поперек, научился виртуозно делать API, освоил Git, знаешь Spring и WebFlux.
Но вот пришло собеседование — и ты... завис.
— Расскажите о себе.
— Ну… я... типа… учился… кодить...
Знакомо?
А теперь еще предположим: ты уже устроился и тебе дали таску.
И ты видишь, что надо уточнить у тимлида детали.
Но в голове:
«А если я спрошу — подумает, что тупой...»
«Лучше погуглю еще 3 часа, чем покажусь нубом»
«Он ведь профи. Я даже не знаю с чего начать...»
Это называется - коммуникативная тревожность.
Она же — тихий киллер карьеры в IT.
Почему ты боишься говорить
Вот тебе правда: страх общения — это не про характер.
Это навык.
Даже самые «разговорчивые» разработчики когда-то:
- боялись скинуть Pull Request с комментариями,
- часами переписывали сообщение в телеграмме,
- репетировали простой вопрос голосом.
Почему некоторым в IT это так сложно?
Потому что IT часто привлекает интровертов, бывших «отличников», людей, которые учились всё понимать сами, без помощи. И теперь, оказавшись в команде — они просто не умеют задавать вопросы или входить в беседу.
Что происходит в голове?
В когнитивной психологии есть понятие self-presentation concern — это тревога из-за того, как тебя воспримут другие.
Именно она:
- заставляет молчать, когда нужно спросить;
- мешает делиться идеями;
- блокирует на стендапах.
А ещё есть спираль молчания — если ты боишься говорить, ты выпадаешь из общения, и из-за этого боишься ещё больше.
Вот пара моих советов если ты чувствуешь что твой софт-скилл слабоват:
Говори, даже если страшно.
Но не вживую, а письменно.
Заведи привычку активно писать: в рабочем чате, в Telegram, в комментариях к pull request'ам.
Так ты приучаешь мозг к выражению мысли — без страха, что тебя перебьют или осудят.
Это снижает тревожность, активирует рефлексивную речь — внутреннее проговаривание и структуру мысли.
Не бойся задавать глупые вопросы.
Как сказал один умный человек: "В IT нет глупых вопросов, есть чересчур ЧСВ-шные отвечающие"
Микроконтакт — это уже общение
Не нужно фигачить речь на 3 минуты.
Просто начни с одной фразы:
«А почему мы сделали вот так, а не так?»
«Спасибо, крутая реализация»
«Подскажи, я что-то путаюсь в этой части»
Это называется anchored small talk — микровзаимодействия, которые создают эффект «я в теме». Даже если ты мало говоришь.
Заготовь фразы. Да, можно и записать
Серьёзно.
Напиши себе в заметках:
Вопрос на стендап: «Ребят, я правильно понимаю, что…»
Начало диалога: «Можно короткий вопрос про фичу?»
Завершение: «Окей, тогда попробую и отпишусь»
В момент тревоги мозг не придумывает речь с нуля. Он вытаскивает готовое.
Подсунь ему нужные заготовки — и увидишь, как снижается стресс.
Найди «одного своего»
Не команду. Не менторов. Одного союзника, с кем безопасно говорить.
Пишете вместе код — обменивайтесь мыслями.
Работаете на проекте — обсуждай идеи.
В сообществе — шутите, делитесь опытом.
Это снижает страх перед всей группой. Есть ощущение, что ты не один. А с этого и начинается уверенное взаимодействие.
Ты можешь спросить: "А зачем мне это вообще?"
Пойми:
Ты можешь быть классным кодером, но без софт-скиллов — останешься «интровертным сеньором без влияния».
Ты сможешь влиять, если умеешь объяснить, услышать, вдохновить.
Продуктивность команд напрямую зависит от психологической безопасности — и ты можешь её самостоятельно формировать.
А еще спроси себя - кого повысят, из двух одинаково скиловых разработчиков? Того кто грамотно и без страха излагает свои мысли или того кто молчит или отвечает невпопад?
Поэтому, не стесняйся, пиши в комментариях, что ты думаешь об это статье! Прокачай навык
#motivation
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6
https://hh.ru/vacancy/135709779
Я вот не понимаю, неужто кто-то соглашается на такие условия?🤪
Крутая, бл, команда.... 🤦♂️
Я вот не понимаю, неужто кто-то соглашается на такие условия?
Крутая, бл, команда.... 🤦♂️
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯1
Ло́уренс Джо́зеф «Ла́рри» Э́ллисон (англ. Lawrence Joseph «Larry» Ellison; род. 17 августа 1944 года, Бронкс, Нью-Йорк, США) — сооснователь и долгосрочный руководитель Oracle Corporation; ключевая фигура в развитии коммерческих СУБД и корпоративного программного обеспечения.
1958 — Pioneer 0 (Thor-Able) — первая американская попытка отправить аппарат к Луне; запуск 17 августа, авария на взлёте.
1970 — программа «Венера»: запуск аппарата Венера-7, первого успешно передавшего данные с поверхности другой планеты — Венеры.
1982 — Германия/Япония: на заводе Philips (Ганновер) начинают серийно прессовать первые компакт-диски (CD); коммерческий старт CD-эры — осень 1982.
#Biography #Birth_Date #Events #17Августа
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Что сейчас, на Ваш взгляд, можно поменять на Devforge.ru?
Anonymous Poll
40%
Цветовую палитру - она вырви глаз
0%
Шрифты - они не очень, можно найти и лучше
40%
UI/UX сайта. Все выглядит глупым и устаревшим
20%
Авторизацию - она работает плохо
0%
Профиль - он выглядит плохо
0%
Чаты - они явно требуют доработки
0%
Я напишу свое мнение в комментариях - >
[Совет по Java #072]
Тема:
Проблема: В отличие от обычных коллекций (
Это означает, что итератор не гарантирует, что отразит все изменения, произошедшие во время итерации, и не бросает исключения при конкурентных модификациях. Разработчики, привыкшие к fail-fast итераторам, ожидают, что при изменении карты во время обхода возникнет исключение, и могут строить логику, полагаясь на это поведение. Однако в
Это особенно опасно, когда предполагается, что коллекция статична во время итерации, но на самом деле изменяется другими потоками.
Решение: Осознайте, что итерация по
Однако для большинства сценариев, где не требуется полная изоляция, поведение
Объяснение:
Вместо этого они гарантируют, что обход будет продолжаться без исключений, и каждый элемент будет посещен не более одного раза, но при этом элементы, добавленные или удаленные во время итерации, могут быть как видны, так и нет. Такая модель подходит для высококонкурентных систем, где важна производительность, а не строгая изоляция.
#Java #советы
Тема:
ConcurrentHashMap при итерации не бросает ConcurrentModificationException — она weakly consistent.Проблема: В отличие от обычных коллекций (
HashMap, ArrayList), итераторы которых являются fail-fast и выбрасывают ConcurrentModificationException при обнаружении структурных изменений во время итерации, ConcurrentHashMap использует стратегию слабой согласованности (weakly consistent). Это означает, что итератор не гарантирует, что отразит все изменения, произошедшие во время итерации, и не бросает исключения при конкурентных модификациях. Разработчики, привыкшие к fail-fast итераторам, ожидают, что при изменении карты во время обхода возникнет исключение, и могут строить логику, полагаясь на это поведение. Однако в
ConcurrentHashMap это не происходит, и отсутствие исключения может замаскировать ошибки конкурентного доступа, приводя к тому, что итерация видит частично обновленные данные или пропускает новые элементы. Это особенно опасно, когда предполагается, что коллекция статична во время итерации, но на самом деле изменяется другими потоками.
Решение: Осознайте, что итерация по
ConcurrentHashMap безопасна в многопоточной среде, но не предоставляет моментального снимка (snapshot). Итератор отражает состояние карты на момент создания итератора, но может видеть изменения, произошедшие после (в зависимости от реализации). Для получения согласованного снимка используйте entrySet().toArray() или создайте копию карты перед итерацией. Если вам нужна строгая согласованность в момент обхода, синхронизируйтесь на самой карте или используйте Collections.synchronizedMap. Однако для большинства сценариев, где не требуется полная изоляция, поведение
ConcurrentHashMap вполне приемлемо и позволяет избежать исключений. Документируйте ожидаемое поведение и не полагайтесь на отсутствие исключений как на гарантию целостности данных.public class ConcurrentHashMapIteration {
public static void main(String[] args) throws InterruptedException {
ConcurrentHashMap<Integer, String> map = new ConcurrentHashMap<>();
map.put(1, "One");
map.put(2, "Two");
map.put(3, "Three");
//Итерация безопасна и не бросает ConcurrentModificationException
Thread modifier = new Thread(() -> {
map.put(4, "Four"); // модификация во время итерации
map.remove(2);
});
// Итератор создается ДО изменений
var iterator = map.entrySet().iterator();
modifier.start();
// Итерация продолжается, несмотря на изменения
System.out.println("Итерация (weakly consistent):");
while (iterator.hasNext()) {
Map.Entry<Integer, String> entry = iterator.next();
System.out.println(entry.getKey() + " -> " + entry.getValue());
// Может увидеть 4, может не увидеть; 2 может быть или нет
// Исключений не будет
}
modifier.join();
// Для снимка: копирование
Map<Integer, String> snapshot = new ConcurrentHashMap<>(map);
System.out.println("Снимок: " + snapshot);
}
}Объяснение:
ConcurrentHashMap использует внутреннюю сегментацию (bucket-level locking) и не блокирует всю структуру при модификации. Итераторы строятся на основе текущего состояния сегментов и не хранят отдельный снимок. Они не проверяют счетчик модификаций (в отличие от fail-fast итераторов), поэтому не бросают ConcurrentModificationException. Вместо этого они гарантируют, что обход будет продолжаться без исключений, и каждый элемент будет посещен не более одного раза, но при этом элементы, добавленные или удаленные во время итерации, могут быть как видны, так и нет. Такая модель подходит для высококонкурентных систем, где важна производительность, а не строгая изоляция.
#Java #советы
👍4
Что выведет код?
#Tasks
import java.util.concurrent.ConcurrentHashMap;
public class task170826 {
public static void main(String[] args) {
ConcurrentHashMap<Integer, String> map = new ConcurrentHashMap<>();
map.put(1, "one");
map.put(2, "two");
map.put(3, "three");
for (Integer key : map.keySet()) {
if (key == 2) {
map.remove(1);
map.remove(3);
}
}
System.out.println(map.size());
}
}
#Tasks
👍2
👍2
Что такое 🤓
Ответ:
Criteria API — это программный API для построения запросов динамически, без использования строковых JPQL.
Использует объекты CriteriaBuilder, CriteriaQuery, Root, Predicate.
Позволяет строить сложные запросы с условиями, которые могут меняться в рантайме (например, фильтры поиска). Пример: cb.equal(root.get("name"), name).
Преимущество: типобезопасность (если использовать Metamodel), динамичность. Недостаток: громоздкость. Используется в сложных приложениях с множеством фильтров .
#собеседование
Criteria API в JPA? Ответ:
Criteria API — это программный API для построения запросов динамически, без использования строковых JPQL.
Использует объекты CriteriaBuilder, CriteriaQuery, Root, Predicate.
Позволяет строить сложные запросы с условиями, которые могут меняться в рантайме (например, фильтры поиска). Пример: cb.equal(root.get("name"), name).
Преимущество: типобезопасность (если использовать Metamodel), динамичность. Недостаток: громоздкость. Используется в сложных приложениях с множеством фильтров
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1