Category: it

Category was added automatically. Read all entries about "it".

Карьера Ники Тонского

@nikitonsky описал свою трудовую биографию https://t.me/nikitonsky_pub/80 и я советую почитать её всем, кто в принципе неплохо программирует, но время от времени вынужден ходить по собеседованиям. Позволю себе несколько комментариев, отчасти подкреплённых и моим собственным опытом.

Хорошие программисты запросто оказываются в довольно дремучих местах. Даже если вам повезло оказаться в компании мечты, это не значит, что потом вам не придётся ходить по собеседованиям на общих основаниях. Широкая известность в какой-то мере помогает искать работу, но эффект очень незначительный.

Все прошлые достижения довольно быстро превращаются в тыкву: лет через 5 уже нужно объяснять, почему это было круто, через 10 — объяснить не получится. Смотреть нужно в будущее, надеюсь Никита в JetBrains сделает что-то новое и классное, чем все программисты будут пользоваться.

Как появилась JetBrains

Я так давно работаю программистом, что в начале моей карьеры JetBrains ещё не существовало и вся история этой компании прошла на моих глазах. Я никогда в JetBrains не работал, но всё-таки позволю себе рассказать историю создания компании глазами разработчика приложений.

Началось всё с того, что Sun Microsystems сделала язык Java и приветствовала создания средств разработки сторонними производителями. Лидерство на этом рынке принадлежало JBuilder от компании Borland. Лично я использовал ещё Together от TogetherSoft, в котором делал рефакторинг rename на UML-диаграммах. JBuilder не умел делать rename, а в Together был совсем плохой редактор кода, но вместе они работали нормально, хотя и съедали всю память.

Когда я открыл IntelliJ IDEA, то увидел, что редактор кода лучше, чем в JBuilder, а для того, чтобы сделать rename, достаточно нажать на горячие клавиши. Потребность в UML-диаграммах пропала. Я закрыл JBuilder и закрыл Together. Очевидно, что MVP для IntelliJ IDEA — это rename в Together. Более того, в Together можно было работать с клавиатуры, без мышки, то есть интерфейсное решение тоже было сделано. Я ничего не знаю про взаимоотношения основателей JetBrains и руководства TogetherSoft, но подозреваю, что IntelliJ IDEA и rename в Together делали примерно одни и те же люди.

Я делаю акцент на rename, но нужно сказать, что идеологически выход IntelliJ IDEA был поддержан Мартином Фаулером и его книжкой Рефакторинг, так что нельзя говорить о каком-то случайном успехе. Но вот у компании Borland было очень много времени, чтобы заметить конкурента и принять меры для защиты своей доли рынка. У них было полно денег, чтобы усилить команду разработчиков и просто копировать новые фичи из IntelliJ IDEA. Они могли попробовать купить JetBrains на корню за фантастические по российским меркам деньги (возможно, я просто не знаю об этих попытках). Вместо этого Borland купил TogetherSoft в 2002 году за 185 миллионов долларов, а явная поддержка рефакторинга rename появилась в JBuilder спустя годы. Фактически, Borland просто ждал, пока его уничтожат.

Более достойным конкурентом был Eclipse, но, с моей точки зрения, ему всегда не хватало качества реализации. Опыт использования IntelliJ IDEA всегда был более позитивным, Eclipse не помогла даже бесплатность.

Kotlin в 2020 году

В 1999 году я закончил университет и устроился на свою первую постоянную работу. Так получилось, что я мог выбрать более-менее любой язык и начал программировать на Java. Через год компания решила перейти на ASP, но особых проблем с поиском работы Java-программиста я уже не испытывал. В 2019 году я в очередной раз вышел на новую работу и у меня появилась возможность начать программировать на Kotlin.

Я вижу множество параллелей между этими эпизодами. Ведущие компании и тогда и сейчас уже несколько лет использовали Java/Kotlin, но было много скептиков, которые не верили в светлое будущее или придерживались альтернативных вариантов его развития. Тогда у Java было полное доминирование на рынке Java-апплетов, а сейчас Kotlin является основным языком программирования под Android. Java начали разрабатывать в 1990 году, Kotlin — в 2010.

Этой осенью я снова пошёл на новую работу и здесь Kotlin уже даже и без первых версий на Java. Я не буду говорить о технически достоинствах Kotlin, сейчас этим занимаются серьёзные профессионалы. Но с точки зрения рынка труда могу предсказать, что через год-два сравняется количество вакансий на Kotlin и на Java для серверных разработчиков в Петербурге. Если вам сейчас 40-45 лет, то программировать на Java до пенсии у вас вряд ли получится. А вот Kotlin ещё лет 20 может быть в очень хорошей форме.

Советы дерьмогрёба

Александр Баумгертнер задал мне вчера вопрос, на который я хочу развернуто ответить:

У меня сейчас проект, где файлы по 15 тысяч строк, нет тестов и сложная асинхронная логика.
Думаю над стратегией улучшения кода (сейчас исправить баг — как сдать iron man).

Какой первый шаг сделал бы ты?

(я думаю начать с end-to-end тестов основной функциональности).


Сначала немного о себе, чтобы очертить границы применимости моих советов. Я стремлюсь делать работающие решения и спать спокойно. У меня действительно есть опыт переработки проектов с трудной судьбой, но все они были разработаны на Java и я пользуюсь отличной IDE, которая сильно мне помогает.

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

В начале работы я отталкиваюсь от известных багов — это помогает разобраться в системе, быстро нанести пользу и начать работу с активно используемых частей кода. В старой системе запросто может быть код, который генерирует какой-то бред, но все уже привыкли и не обращают на него внимания.

Я ненавижу баги и вам советую. Потратили весь день на борьбу с тяжёлым багом? Задержитесь на работе и поправьте ещё 2 маленьких.

Всегда благодарите тестировщиков. Даже если описания бага не очень хорошее, даже если баг минорный, даже если исправить его очень тяжело. Даже если вас за баги штрафуют. У всех должна быть уверенность, что баги будут беспощадно побеждены.

Не отгружайте код, пока IDE не прекратит подсвечивать вам проблемы в нём. Так проект потихоньку станет «зелёным».

Адаптируйтесь ко времени релизов. Перед релизом должна быть стабилизация, основную пользу в ядре системы нужно причинять в начале релизного цикла. Лучше сначала переработать, а потом неспеша доделывать что-то неопасное.

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

Мне IDE подсвечивает неиспользуемые куски кода и это часто влечёт каскад изменений. Удалил неиспользуемую переменную? Опа, а тут у метода ненужный параметр. Опа, у нас тут два одинаковых метода и в одном бага не исправлена. Опа, а вот эти 2 класса теперь совпадают. Опа, а теперь можно выкинуть код, который решает, какой класс создать.

Большая удача, если приходит бизнес и говорит, что поддержка вот этой психбольницы нам больше не нужна и можно её из кода убрать. Это может очень сильно упростить проект.

Не вставляйте костыли.

Если бизнес просит разработать новую функциональность, сделайте такой рефакторинг, чтобы она добавилась тривиальным образом.

Не жалейте сил на поддержание базы в порядке, в первую очередь — удаляйте ненужные объекты. Один из моих наиболее впечатляющих проектов был связан с переписыванием на Java десятков тысяч строк PL/SQL.

Избавляйтесь от лишних зависимостей. Часто программисты добавляют какие-то устаревшие библиотеки вместе с их зависимостями ради какого-то синтаксического сахара.

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

Изничтожайте Hibernate и другие ORM. Любой программист может освоить SQL, а вот ORM имею свойство преподносить сюрпризы в самое неподходящее время.

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

Демотивация изменений

Недавно слушал подкаст Цинковый Прод и там была история про разработчика, который за неделю радикально переписал весь проект, в который годами с мучениями вставляли разные костыли. И меня поразило, что это обсуждалось исключительно с точки зрения облегчения жизни программистов. О том, что у компании снизились риски, о том, что разработчиков можно направить на другие задачи, о том, что бизнес стал немного больше стоить — об этом речь не идёт. Наверняка героя похвалят, возможно выплатят премию и даже может быть поднимут зарплату. Но не более того.

Я сам много чего за свою карьеру переписал и должен признаться, что желание сделать работающий продукт и спокойно спать по ночам является для меня достаточной мотивацией. Но давайте посмотрим на картину в целом. Чтобы что-то объёмное переписать, нужно сначала договориться с коллегами и начальством, придумать свой план и всех убедить. Если можно справиться за день-два, то есть шанс напрячься и показать уже готовый результат, а если нужен месяц? Потом нужно действительно всё переписать, это обычно довольно напряжённая работа, отличающаяся от перемещений между кофе-пойнтом и совещаниями. После этого нужно пройти тестирование и так как код совсем новый, то баги будут. И нужно их исправлять очень быстро, потому что они ставят под сомнение всю идею масштабного переделывания. А при внедрении оказывается, что тестирование выявило не все проблемы и тут уже надо совсем срочно чинить. И когда уже все немного забудут, какой кошмар был раньше, запросто могут найтись желающие покритиковать сделанные решения, с разной степенью конструктивности.

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

Java в 2020 году

Спрос на Java-программистов настолько усилился, что соответствующие курсы растут как грибы после дождя. Казалось бы, ничего сложного: Spring Boot, Maven, GitHub, немного SQL, учимся работать с Jira и вот уже новый специалист на 80% проинициализирован.

Должен признаться, я всегда крайне скептически относился к подобным курсам и моё отношение не изменилось. Допустим, что человек пошёл на такие курсы, значит он не получил приличного технического образования, иначе его научили бы всему этому в университете, по крайней мере он мог бы не тратить деньги, а разобраться самостоятельно, благо обучающих статей и видео по этим темам великое множество. Если человек учился в плохом университете, значит у него были низкие баллы за ЕГЭ, что тоже настораживает.

Однако в концепции этих курсов есть рациональное зерно. Все они рассказывают о зарплатах более 100 тысяч рублей в месяц и с разной степенью наглости гарантируют трудоустройство. И в российской реальности такие деньги кажутся пределом мечтаний. Но фактическая ситуация на рынке такова, что Java-программист с опытом и с навыками прохождения собеседований легко может претендовать и на 200. Многие компании не могут платить такие зарплаты и вынуждены нанимать новичков, в том числе и с курсов. И это очень хорошо, потому что у людей появляется шанс войти в профессию.

Фундаментально здесь есть проблема, что про новых программистов неизвестно, смогут ли они решать инженерные задачи. Разобраться в баге с какой-то внешней библиотекой? Придумать не совсем тривиальный алгоритм? Оценить, справится ли сервер с пиковой нагрузкой? Обнаружить узкое место в коде? Большинство разработчиков далеко не каждый день с такими задачами сталкивается, но подобные трудности могут оказаться большой проблемой.

Итак, есть много задач для программистов, которые приходится поручать неопытным специалистам. Как повысить шансы на успех? У меня есть 2 технических совета и первый из них — не используйте Hibernate. Это дискуссионный вопрос, я сам успел много копий сломать в спорах об этом, но в данном контексте считаю важным высказаться. Возможно, Hibernate поможет что-то разработать быстрее, но когда с ним возникнут проблемы, то новичкам будет очень тяжело с ними разобраться. Даже если не прилетит что-то экзотическое вроде кэширование запросов с переменным числом параметров, выкачать всю базу в память можно легко и незаметно.

Другой совет более радикальный, но вряд ли вызовет большую волну споров. Если вы разрабатываете что-то новое — переходите на Kotlin. Kotlin цинично сделали лучше, чем Java. В Java есть много тонкостей, которые в Kotlin новички могут просто избежать: сравнение строк только по equals(), тема про checked exceptions, ключевое слово volatile и так далее. Я уж не говорю про NPE. Новые версии Java нет смысла принимать в расчёт, потому в индустрия до сих пор в основном используется Java 8. И опытные программисты новые разработки сейчас тоже начинают на Kotlin.

Здесь стоит вернуться к теме обучения. Понятно, что основная часть вакансий до сих пор на Java, даже если учесть, что в мобильной разработке Kotlin давно доминирует. Это вполне объяснимо, потому что переписать на Kotlin уже существующий микросервис — совсем не очевидный шаг. И курсы, да и университеты продолжают во все тяжкие учить студентов Java. К сожалению, обычно существующий код не является образцом для подражания, а создаёт дополнительные барьеры для новичка.

Таким образом, изучая сейчас Java вы рискуете или начать карьеру с познания проблем старого проекта, или переучиваться на Kotlin. В то же время, если вместо Java изучать Kotlin, то можно сразу стремиться попасть на новый проект на Kotlin. Но для этого придётся всё-таки заниматься самостоятельно, а не просто потреблять продукты образовательной индустрии. К счастью, учебных материалов по Kotlin вполне достаточно, а с точки зрения Spring Boot между Kotlin и Java просто нет разницы.

Тимлид, разработчик

Я никогда не гнался за должностями и по моей довольно длинной карьере менеджерский опыт раскидан несвязанными островками. Зато у меня много индивидуальных программистских достижений: на прошлой работе я написал всю финансовую часть сервиса, да и на этой будь здоров сколько сделал. Конечно, мастера прошлого автоматизировали в одиночку целые заводы, но мне уже не хочется двигаться в сторону больших личных подвигов.

Когда делаешь что-то большое, то необходимо кому-то об этом рассказывать. Раньше я много выступал на конференциях, но сейчас хотел бы начать делиться опытом с командой в промышленных масштабах. Так получилось, что я много обсуждал производственные вопросы на уровне CTO и это мне представляется порочной практикой. У CTO много проблем другого уровня и технические детали могут оказать ему не очень интересны.

Я давно заметил, что когда начинаю работать на новом месте, то есть большие возможности для подвигов: то ли берут меня когда ситуация критическая и руководство готово к радикальным переменам, то ли новый человек свежим взглядом сразу видит, что можно исправить. Очистка авгиевых конюшен с большой вероятностью помогает быстро поднять зарплату, но меньше чем через год начинаются неожиданные производственные проблемы, частично объясняющие, как тут всё запачкалось. У меня есть высокоуровневое объяснение, что на самом деле героев просто не любят: они делают странные вещи и в общении часто не самые приятные люди. Сейчас я хочу найти работу, где необходимость геройских подвигов можно предотвратить на корню.

Обновил своё резюме на hh, обозначил склонность к позиции тимлида. Разработчиком тоже могу, но требуемый уровень героизма нужно обсуждать заранее. Последний год я разрабатывал на Kotlin и возвращаться на Java уже не очень хочется. Если нужна SQL база данных — то мне больше всего нравится PostgreSQL с его поддержкой JSON. Последние 4 года использовал Spring Boot, но это уже минорные детали.

Коммиты против тестов

Я недавно разрабатывал новую функциональность и хочу рассказать, как это было. Задача довольно объёмная, но раскладывается в цепочку последовательных шагов. Основная часть работы заняла 2 дня, но перед этим я успел подумать, что и как делать. Я сам вносил изменения в 3 компонента, ещё с 3 компонентами нужно было взаимодействовать, один из них существенно менял мой коллега.

Так как я сам придумывал и сам программировал, то на письменной постановке задачи мы сэкономили. Если бы у нас было время и я мог бы сделать только постановку задачи, то у меня легко получилось бы 4 разных подзадачи, которые можно было бы теоретически отдать разным людям. К сожалению, 3 из них были бы достаточно маленькими, а 4-ая — весьма объёмная. Это из-за того, что в одном компоненте всё завязано на новую таблицу в базе данных. Если создание таблицы сделать отдельной задачей, то оставшиеся изменения разбились бы на 3 маленьких кусочках.

3 основных коммита я сделал в первый же день. Дальше по коммитам можно восстановить, какие баги пришлось поправить. Первый баг был тривиальный и давал о себе знать потоком ошибок в логах, исправил сразу в одну строчку.

Дальше обнаружилась проблема, которая потребовала передачи ещё одного параметра для компонента, разработкой которого занимался мой коллега. Первый коммит не помог, потому что надо было передавать в JSON только строки, а я засунул число. Исправил ещё одним коммитом и это уже был 2 день разработки. Надо признать, что это косяк в проектировании и не очень понятно, как его было избежать. Наверно, если бы я выделил день на то, чтобы подробно всё расписать, то у меня были бы шансы заметить проблему и принять меры, но без гарантий.

Дальше было 3 тривиальных проблемы (2 были связанны с SQL), которые я сразу исправил за 3 небольших коммита.

А вот дальше случилась проблема интеграционного характера, которая поставила меня в тупик, 4 коммита ушло только на то, чтобы улучшить логи в попытках разобраться. И после этого я внезапно заметил, что ищу файл без расширения, а он с расширением, тривиальный коммит сразу решил проблему. С большой вероятностью помогла бы хорошая спецификация.

Дальше последовательно открылись ещё 3 проблемы, которые я легко исправил 3 коммитами. В одном месте потребовалось понимание предметной области, но так как у меня уже скопился некоторый опыт, то я сразу разобрался. На этом закончилась основная разработка.

К сожалению, через неделю оказалось, что в предметной области я ещё плохо разбираюсь и потребовалось ещё 3 небольших коммита, чтобы это исправить. Самая большая боль, как это можно было предотвратить — непонятно, с нашей точки зрения эту беду нельзя увидеть.

Итого, очевидно, что разработчик должен самостоятельно проверять свой код. Если бы перед каждым моим коммитом тестировщик должен был бы завести тикет, мы бы не то что в 2 дня, мы бы в 2 недели не уложились. У нас по каждому коммиту происходит обновление в интеграционном контуре и это очень удобно. Разворачивание на локальной машине в нашем случае имеет существенные ограничения.

Если смотреть по количеству, то большинство ошибок можно было бы поймать юнит-тестами. Тут есть некоторое смещение терминологии, речь идёт о тестах одного компонента, но это компонент со своей базой и REST-интерфейсом. И если бы разработчиков было много, то такие тесты приносили бы пользу, Васе не нужно было бы ждать, чтобы Петя дёрнул его сервис, чтобы увидеть, что ничего не работает.

Однако, нужно заметить, что самые трудные для исправления ошибки носят интеграционный характер и поймать их простыми тестами нет шансов. Для их предотвращения лучше писать более ясные спецификации. Это не решит проблему полностью, но я не верю, что можно успешно работать программистом и не сталкиваться время от времени с необходимостью разобраться в чём-то нетривиальном.

Паттерн проектирования цепочка перекладываний

В большой компании стоит большая база данных. Она настолько древняя, что стоит огромных денег и всем очевидно, что надо с неё куда-то мигрировать. Поэтому команда A занимается тем, что перекладывает из неё данные в другую базу, более современную и с разумной ценой владения. Когда B занимается тем, добавляет информацию из других источников, удаляет дубликаты и кладёт в ещё одну базу данных. Команда C складывает всё в совсем современную базу данных, откуда их можно доставать с огромной скорость и через REST. А команда D готовит документы, которые потом индексируются поисковой системой. И так исторически сложилось, что подготовленные командой B данные используют в финансовом департаменте, а командой C — в маркетинге.

Каждая команда делает важную работу, их сервис должен работать быстро и без ошибок. Поэтому в каждой команде нужно по 2 разработчика и 2 тестировщика, если вдруг кто-то уйдет в отпуск или заболеет. К ним ещё нужно по половинке админа и менеджера. Конечно, держать всех этих людей в штате большой компании и оборудовать для них рабочие места в центральном офисе — это нонсенс, поэтому привлекают аутсорсеров. При этом нужно диверсифицировать риски, поэтому подряды отдаются разным компаниям и команды находятся в разных странах. Как следствие, все работают в разных часовых поясах.

Очевидно, что поменять здесь практически ничего нельзя. Если инженер работает в команде D, то он общается с ребятами из команды C постоянно, но чтобы узнать про команду B, ему нужно быть очень любопытным. Команда A для него вообще вне зоны досягаемости. Каждый отдельно взятый сотрудник в принципе не может сделать ничего выдающегося и немного скучает на работе. Зато можно от всей души обсудить стандарты кодирования и выбрать самые лучшие вспомогательные библиотеки.

Конечно, есть риск, что невидимая рука рынка может внезапно прекратить всё это перекладывание, но большие корпорации очень инертны. А пока данные перекладываются, люди получают зарплату, выплачивают ипотеку и едят печеньки.

Отзыв на отзыв: Яндекс

На Хабре появился рассказ уволившегося сотрудника о работе в Яндексе, а потом ещё и ответные комментарии работающего. Я тоже выскажу несколько соображений, может быть кмоу-то будет полезно. Должен сказать, что у меня у самого есть опыт работы в Яндексе, но это было больше 10 лет назад.

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

Если компания оплачивает сотруднику релокацию, то это эквивалент солидной такой годовой премии, только не в конце года, а сразу. И знаете, далеко не везде выплачивают годовые премии. Если вам платят настолько ниже рынка, что вы считаете, что по результатам 1 года вас недооценили несмотря на помощь с переездом, то просто через 1 год и 1 день принимаете очевидные меры по повышению своей зарплаты.

Я понимаю, что многие скептически настроены относительно RSU, опционов и всего такого, но это гораздо лучше, чем ничего. Поверьте, бывает обидно, когда сворачиваешь на работе горы, а тебе за это дают компенсацию за неиспользованный отпуск и выходное пособие. И если дают выходное пособие, то это, можно сказать, повезло. Но идея соглашаться на меньшую зарплату ради строчки в резюме кажется мне очень странной.

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

Тем не менее, я за свою карьеру разгреб несколько эпических куч дерьма. И говорю вам: разгребайте дерьмо и воздастся вам. Я не знаю, почему вы всё время перерабатываете, но, возможно, вам надо больше времени тратить на разгребание дерьма. Ваши оценки «выше ожидаемого» ничего не стоят, пока проект утопает в дерьме.

Есть точка зрения, что если программист хорошо работал, то ему полагаются всякие бонусы независимо от успешности проекта. А теперь представьте, что менеджер проекта сначала подсчитывает убытки (провалившийся проект в нашей индустрии это довольно много денег), а потом идёт к своему менеджеру и начинает рассказывать про премию для Васи и повышение для Пети. Я на такой сценарий не надеюсь и стараюсь избегать провальных проектов. Такие строчки мне в резюме не нужны.

В жизни программиста каждый новый проект бывает связан с определёнными неудобствами. Я рекомендую по возможности адаптироваться к ситуации и стараться избегать боевых действий по пустякам. Например, для серверной разработки можно запросто обойтись без Windows. Если вдруг на Windows работать не удобно — просто выкиньте Windows. Если всё лежит в монорепе — не надо устраивать бурную дискуссию: никто ничего нового не услышит и ничего не изменится. Многие популярные проекты выложены в публичный доступ гигантами, но не всегда гиганты сами их используют. Если вам не хватает Cassandra или Kafka, хорошенько подумайте, есть ли у вас достаточный опыт их эксплуатации в проектах такого объёма. Конечно, отказать от Kibana может быть довольно неприятно, но это инфраструктурно достаточно тяжёлое решение.

Но если уж говорить о технологиях, то в 2020 Java-программист должен спрашивать себя, почему он не программирует на Kotlin? Это точно важнее, чем используемая операционная система на компьютере разработчика.

В конце автор говорит о том, что познакомился с крутыми разработчиками. Я считаю, что крутые — это те, с кем можно мир поменять. Если вы всей командой перерабатывали, потому что на проекте всё время какие-то проблемы, то в чём крутость-то?

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

Дальше говорится о ситуации, когда 2 человек делают примерно одно и тоже, но один получает в 2 раза больше. Так действительно бывает, например, если у компании прямо сейчас нет для них работы и они занимаются саморазвитием. Но гораздо чаще зарплаты сотрудников в одном отделе различаются чисто символически, даже если они вносят совсем разный вклад.

Совет торговаться на собеседовании не имеет практического смысла. Если у кандидата есть альтернативный сценарий с лучшими условиями — он и так займёт жесткую позицию. Если на самом деле других вариантов нет, то о чём речь?

И дальше описывается совершенно кошмарную картину: 15 классных разработчиков не хотят знать как устроена система целиком. И их не увольняют, им ставят задачи по перекладыванию данных отсюда туда! Более того, им могут поставить оценку «выше ожидаемого»!

Если придёт новый человек, что он может сделать, кроме как перекладывать вместе со всеми и развивать soft skills?