Комментарии 39
На фронтенде с тестами полегче. Пробовал Playwright на ClojureScript, чтобы писать web-тесты интерактивно с REPL, получилось легко, быстро и удобно.
welcome to REPL Driven Testing 🙏
в соседних палатах до сих обсуждают что Selenium круче, потому что поддерживает IE
не пробовали включить RDT на нативном js/pw, через replete например?
Не пробовал, все делал через Clojure REPL, так как надо было быстро, а я со стеком знаком.
у меня нет тулинга, кроме VSCode+Calva
и использовать cljs+pw получилось только из-за опыта в js/pw
как у вас с автокомплитом в cljs+pw(можно ли в теории, к примеру, подключить d.ts), можете поделиться советом что поставить/развернуть - для эффективной работы в этом направлении?
У меня фронт был написан на Cljs, а PW я запускал из Clojure (Java API). Редактор кода был Neovim, автодополнения были ограниченные (от LSP, который с Java послабее, чем в Intellij Idea).
Наверное, с TS проблем быть не должно, могу порекомедовать спросить совета в https://t.me/clojure_ru/208607
Интересная статья!) Вопрос, как к более опытному - нужно ли тратить время на изучение потенциально полезных технологий, которые популярны на рынке на данный момент, но не нужны в текущих проектах? И что на Ваш взгляд можно считать базовым знанием, которое пригодится и на фронте и на бэке?
Нужно ли тратить время на изучение потенциально полезных технологий, которые популярны на рынке на данный момент, но не нужны в текущих проектах?
Я бы изучал, если бы это еще и интересно было. Просто изучать, потому что популярно, наверное, не стоит. Но надо на контекст смотреть. Например, если занимаешься Android-разработкой и планируешь продолжать, то Kotlin и его корутины — must have. Если backend на Java, то Kotlin можно игнорировать — и ничего не потеряешь.
Что на Ваш взгляд можно считать базовым знанием, которое пригодится и на фронте и на бэке
Понимание основ HTTP, SSL/TLS, OAuth 2.0.
Какая-нибудь одна книжка или несколько статей по паттернам проектирования, чтобы просто понимать, что они есть, и узнавать их в коде. Тут главное не злоупотреблять, с опытом станет понятнее, когда добавлять абсракции, а когда просто решать задачу.
На собеседованиях понадобятся алгоритмы уровня легких и средних задач с Leetcode, в коде теоретически это тоже может пригодиться (но как правило, HashMap хватает).
Для общего развития не помешает несколько проектов реализовать «в паре» с более опытным разработчиком. Например, проходя онлайн-уроки, где что-то разрабатывается с нуля, или читая книгу вроде Build an Orchestrator in Go (From Scratch). Тут можно любую задачу выбрать, руководствуясь скорее интересом, чем ожидаемой практической пользой, потому что долгосрочно сложно предсказать, что именно тебе понадобится.
В случае с джуном нужно решать гору проблем, с выгоревшим сеньором — одну: потерю мотивации.
Только ли одной мотивацией обходится выгорание? Для начала бы неплохо причину узнать, а то через месяцок-другой выяснится, что лечили гастрит путём наложения гипса на ногу.
Я кстати даже не знаю, что такое выгорание. 10 лет работаю, не случалось такого, что работать не могу. Было просто интересно стек сменить, но руки не опускались. Может, кто-то с депрессией путает или еще чем-то. Поэтому мне в статье было проще выгорание связать с потерий мотивации по тем или иным причинам.
Полностью готов подписаться под практически всеми утверждениями в статье. У меня за плечами 30+ лет в разработке (по большей части бэк), и поспорить практически не с чем. И да, до сих пор не понимаю что имеют ввиду когда говорят о выгорании.... Конечно, и у меня "бывают дни когда опустишь руки". Но, обычно это связано с затянувшийся рутиной или банальной усталостью. А значит всегда решабельно.
Из опыта знаю что комбинация сеньер+мидл или перспективный джун , почти всегда дают хороший результат, неся пользу и сеньеру(снимает часть рутины) и мидлу/джуну(рост и перенимание опыта) и компании(качественный продукт).
Джуниоры создают шум и хаос: ошибки в коде, утечки памяти, race condition и data race, несоблюдение конвенций, стиля, push force в мастер, нарушение правил безопасности, плохие абстракции, много вопросов и т.п.
ошибки в коде делают все (кроме Дональда Кнута), иначе человечество бы не придумало тесты
утечки памяти — штука вообще довольно спорная, присутствующая далеко не во всех языках, легко выявляемая профайлером и да, доступная тоже далеко не только джунам
race condition и data race — скорее самоуверенный самопровозглашенный синьёр пропустит race condition, но это тезис недоказуемый; в хайлоаде гонка — это буквально постоянная среда обитания, и джун, почитавший мой код полчасика перед сном, скорее всего, обратит внимание на потенциальный race condition с бо́льшей вероятностью, чем синьёр, двадцать лет перекладывавший джейсон
конвенции и стиль — это один разговор на код ревью, не нужно держать джунов за совсем уж дебилов (а еще есть линтеры и автоформаттеры, да и прекоммит-хуки никто не отменял)
push force в мастер джун может сделать только там, где нет ни одного синьёра
правила безопасности — это что за зверь? Неавторизованный доступ к потрохам? Не верю, что самый распоследний джун об этом не подумает
плохие абстракции — это да, но болезнь общая и для джунов, и для синьёров: абстракции — почти наравне с инвалидацией кэша и именованием переменных же
много вопросов — угу, а еще оно жрать просит.
В общем, я предпочту джух джунов с горящими глазами — даже абсолютно невыгоревшему синьёру с таким апломбом. Джунов можно и нужно обучить хорошему, а синьёр с большой вероятностью уже обучен плохому.
зайду с козырей про утечки памяти да я не до конца читал где именно она ищет) но если создали такое то значит уже были баяны ) mdb-guide/finding-memory-leaks.html на сколько я понял альтернатива только левые приложухи на других ОСках )
how-to-use-dtrace-to-check-malloc-on-solaris-10
на линуксе я видел strace вроде, но не знаю не помню видно ли там, интересно как ловят утечки в винде
есть еще perf, valgrind
правила безопасности — это что за зверь?
А я приводил пример кода в статье, где написали уязвимый к SQL-injection код.
а синьёр с большой вероятностью уже обучен плохому.
В какой-то момент понимаешь, что ложки нет.
уязвимый к SQL-injection код
А у нас имя таблицы пользователь вводит, да? «SQL-injection» — слова очень красивые (и страшные) но это не сакральное заклинание, за этими словами кроется смысл. В приведенном примере — никакой инъекции нет (это не значит, что так надо писать).
Вообще, этот код нужно выбросить на свалку и переписать с нуля, конечно (желательно, на каком-нибудь приятном языке еще). Но из «у нас один джун написал вот такую гадость» — я могу сделать только один вывод: код-ревью в конторе хромает (нормально выстроенный процесс отучит джуна так писать за один раз). Я тоже могу показать код от синьёрного синьёра, от которого глаза вытекают; мало ли, все мы не боги.
Но из «у нас один джун написал вот такую гадость» — я могу сделать только один вывод: код-ревью в конторе хромает
Мимо. В тот момент был только один разработчик на проекте, остальные уволились, и его некому было ревьюить.
Я тоже могу показать код от синьёрного синьёра, от которого глаза вытекают;
Хотите ли вы сказать, что опытные разработчики пишут код не лучше, чем разработчики, которые только начали?
В общем, я предпочту джух джунов с горящими глазами
А подскажите еще, какой у вас опыт? Набирали ли себе людей в команду? Работали в команде с джунами?
> код-ревью в конторе хромает
Мимо. В тот момент был только один разработчик на проекте, остальные уволились, и его некому было ревьюить.
Э-э-э-э-э… Если «некому ревьюить» — это не хромает, то что тогда — хромает? Когда код ревью запрещён и за него бьют бейсбольной битой по голове?
Хотите ли вы сказать, что опытные разработчики пишут код не лучше, чем разработчики, которые только начали?
Нет. Я хочу сказать ровно то, что сказал: один (возможно выдуманный) пример — не показатель, и на его основе нельзя делать широчайшие обобщения. Я бы не доверил джуну писать движок распределенного хранилища, но с перекладыванием джейсона и даже реализацией частей подсистем под чутким руководством и менторством со стороны адекватного синьёра — джун справится минимум не хуже. А таких задач больше, чем рокет саенса на блидинг эдже.
А подскажите еще, какой у вас опыт? Набирали ли себе людей в команду? Работали в команде с джунами?
30 лет на зарплате, Principal Engineer, 12 языков за которые мне платили деньги, 6 из них в активном запасе. Больше пары сотен собеседований, наверное, сотен пять проверенных и тщательно отревьюенных тестовых заданий. Всегда старался работать с джунами, потому что уже давно их прогресс — греет меня гораздо больше собственных успехов в решении доныне нерешенных задач.
один (возможно выдуманный) пример — не показатель
Там много чего, но не буду же я приводить всё (NDA даже не позволит). Мне казалось, что на таком участке кода так много ошибок разных уровней сможет уместить только новичок. Помимо кода я еще рассуждения привел, а также условия, при которых джунов можно брать.
12 языков за которые мне платили деньги, 6 из них в активном запасе.
Это сильно, мое почтение. А что вы имели в виду тут:
переписать с нуля... желательно, на каком-нибудь приятном языке еще
Что не так с Котлином, какие языки для вас приятнее?
В целом, переписать на другой язык целый проект — для бизнеса так себе затея, никакой ценности в этом нет. Вы так не считаете? Или это просто троллинг Котлина был?
Мне кажется, пропущено важное уточнение условий - в моменте или на дистанции?
Автор немного обесценивает понимание состояния выгорания, как мне кажется. Я понимаю, что в потоке 90% статей на хабре рисуется картина, что "выгорание, мол, это когда немного потерял интерес и мотивацию", но нет! Это сложная комбинация особенностей событий в жизни, прошлого опыта, физиологических (и особенно биохимических) проблем, помноженная на особенности сознания и восприятия.
Выгорание детектить можно так. Прибавка к зарплате в 50% не даёт никакого повышения производительности. Возможность заниматься, со слов выгоревшего, самыми интересными проектами и технологиями не даёт никакого увеличения производительности и повышения внимания. Факторы риска человек практически полностью перестаёт транслировать.
Всё это, конечно, не является единственной верной точкой зрения, но свою позицию продолжу. Выгорание - это следствие крайнего истощения, многолетней неудовлетворенности и принятия того, что эту ситуацию человек уже не в силах для себя изменить.
Сеньор будет в таком состоянии писать код на уровне джуна, и остальное время фрустрировать. Все возможные проблемы и последствия этого, в отличие от джуна он уже знает, и тысячу раз их проходил (потому ему не интересно их решать), но прекрасно знает, что ничего хуже увольнения с ним не произойдёт. И ничего лучше, чем получение очередной не маленькой зарплаты, кстати, тоже.
Это не мешает ему прекрасно пройти собеседование по вопросам, которые он уже знает. И если нет другого сеньора в команде, про историю предыдущего абзаца вы догадаетесь не сразу (а вот он уже это все знает).
На первой стадии оконченного выгорания, люди нередко становятся очень токсичными, таков защитный механизм, потому что высока вероятность того, что токсичность примут за идеологичность и стремление следовать высшим ценностям относительно проекта/организации работы. Но по факту это ИБД, где в принятии решений мозг того сеньора не покидает комнату, где он знает все. И он будет вести, чтобы повторять те ошибки, решения которых он знает!
На последующей фазе, принятия и смирения, человек обрастает тем уровнем формализма (потому что сил на токсик уже нет) в поведении (и лишь только), что в силу многих факторов, окружающие думают (если не могут проверить), что он все ещё сеньор, а не джун-ждун в овечьей шкуре.
Мой вердикт: лучше один живой и активный джун, чем два выгоревших сеньора (даже за те же деньги).
Или просто не надо писать слово на букву в лишний раз.
Автор немного обесценивает понимание состояния выгорания
Может быть, вы правы. В описании, что вы дали, много конкретики и деталей. Подскажите, где вы это взяли? Это наблюдения за коллегами, личный опыт или и то, и другое?
Да, к сожалению, по большому счету с этого мой опыт в ИТ и начался. Если людей "хитрых жуков" я уже к тому моменту умел распознавать, а в ИТ их тоже немало, "ничего в четверг релизить не будем, а то в пятницу будет длинный день", "это я исправлю только когда менеджер скажет", "сейчас ничего не буду делать, на выходных выйду за 2х, если менеджменту так нужно" и так далее, то природу выгорания было понять куда сложнее. В общем-то слова такого тогда ещё в ходу особо не было. Но когда отвечающий за тебя сеньор открыто говорит, что мол метрики мы прикручивать не будем, потому что ну вот найдём проблемы с производительностью, кому их исправлять охота? Что printf подобный лог не будем заменять на нормальную библиотеку или хотя бы стримы, "не трогай оно и так работает" и долгие долгие обсуждения, почему оставить как есть будет лучше. Пишет то что-то приличное по меркам студента миддла, то просто ерунду как на курсах паскаля. Ну а потом немного все же подружились, ну там и со здоровьем не супер у него, и денег не хватает и уже не один год такая история. В общем ситуация на моем месте такая, что сейчас уже все скажут "просто беги", но я не особо понимал, проект интересный, компания хорошая, платят прилично, да и человек тот тоже неплохой. Пожаловался друзьям, быстро выяснилось, что таких персонажей в ИТ просто вагон, ну как-то прижилось их называть "сильно уставшими". Поглядывли потом за ними, как тезис, большинство сильно уставших уже назад не разустают, как бы дальше не менялась их жизнь. Миллион историй про таких людей есть, но, конечно, считаю, что вот прям некрасиво про это вне абстракций рассказывать. Они же хабр читают, могут вдруг и на истории про себя наткнуться.
А так, ну вот как бы то да сё, но лет через 6 я очень внезапно сам стал сильно уставшим, наверное главный драйвер - ухудшение здоровья. Ещё до 30, хотя большинству знакомых сильно уставших уже было ближе к пятому десятку. Неврологи, психиатры немного помогли, но если честно поведение моё собственное морфировало все ближе к вышеописанному. На последнем рабочем месте уже помню себя, фиксившего архитектуру дотнетного сетевого приложения с помощью goto. Именно за это приложение потом правда компании прилетело. Не по шапке правда, а от заказчика, собственно из-за багрепорта которого, и пришлось вот так вот изолентой чинить архитектуру, причём в десятках миллионов зелёными. Ну и мне, благодарность и копеечную премию. Я все как бы руководству то рассказывал, что я все это говном и палками чиню, и что надо бы за вопрос взяться серьёзнее, но ведь прибыль это прибыль, а расходы это убытки. На том мои последние психологические силы на "не уставать" и закончились.
Спасибо, что поделились. Я вроде пока до перегорания не доходил, но были периоды, когда увольнялся и не работал год. Но весь этот год что-то кодил для себя. Может быть, там на самом деле выгорание и было. Какой-то консерватизм тоже появился, но не настолько, как вы приводили пример:
метрики мы прикручивать не будем, потому что ну вот найдём проблемы с производительностью, кому их исправлять охота?
Я бы сказал, что мне. На последних двух проектах я с этого начинал и занимался несколько месяцев только оптимизациями. У всех свои интересы, мне приятно смотреть, когда бекенд перестает падать от нагрузки или когда ручки в два раза быстрее отрабатывают.
"— Кому бы вы разрешили себя оперировать — одному опытному уставшему хирургу или двум интернам с горящими глазами?" (с)
Из медицинского бородатого юмора:
"Врач пациенту перед операцией:
- Вы только не волнуйтесь, но вас оперировать будет студент-практикант под моим присмотром.
Больной (испуганно):
- Доктор, а если он меня зарежет?!
- А мы ему за это двоечку поставим ! (улыбаясь)"
Ну вы всё же драматизируете. Выгорание, оно не про физичемкую усталость, а про неудовлетворённость и творческую импотенцию.
Глядя на наших врачей - они выгорают ещё после 8 лет универа и понимания какая будет ЗП при какой нагрузке. Хирурга с горящими глазами вы найдёте либо в частной клинике, либо в кино.
Выгорание, оно не про физичемкую
Выгорание это комплексная проблема. Мне сложно поверить, что есть выгоревшие люди в хорошей физической форме (хороший иммунитет, нет плохо излечимых болячек, нет тяжёлых психологический травм). Но даже если от рождения у человека сильное здоровье, чтобы поддерживать его, нужны ресурсы. И время и деньги. Если денег на хорошую жизнь с избытком нет, то очень сложно свыкаться с тем, что и времени очень ограниченное количество. Пытаешься оптимизировать время, теряешь в деньгах. Пытаешься оптимизировать деньги, теряешь в качестве жизни. И, казалось бы, очень много физически проблем починить реально, но с возрастом их интенсивность и количество только растёт. Значит надо что-то "успеть" пока можешь. А это, оказывается, ведёт к повышенной нагрузке и на организм и на мозг. Первый симптом, как я считаю, настоящего выгорания, это когда ты приходишь на работу, и твой мозг вообще не понимает, что ты здесь делаешь. После этого очень быстро можно очень много понять, и вот уже через какое-то время начинает в голове играть песня Сплин "выхода нет".
Впрочем да, ощущением творческого потенциала, эти ощущения можно давить, но ценой потери консистентности восприятия. "я такой творческий", "я тут такую крутую штуку написал", "я лучше знаю", "я настоящий творец по образу и подобию бога", "азм есть" и хорошо если привет психотерапевт. Какое на конвейере, например, творчество? А творчески лечить пациентов это иногда и вовсе статья.
Мне давно очень хочется написать длинную статью и не о том, как "бороться с выгоранием", а "как выжить, если горишь", но, с учётом того, что один из важных пунктов, когда ты уже горишь, не думскроллить ерунду в принципе, то ничем, кроме обнуления кармы эта история не закончится. А основная аудитория, недоджуны, прокрастинирующие оверджуны, очень творческие миддлы и ЧСВшные недосеньоры, на рефлексах скажут "дед, опять таблетки забыл выпить?". Се ла ви.
Код в статье лучше бы в орм выполнить. Да и когда он упадет? Если нужга проверка, что код работает в транзакции - это проблема архитектуры, хорошо что джуны не добавили её, так как с таким подходом можно обмазаться проверками, вплоть до нехватки памяти для нового объекта.
А выгорел, потому твой опыт может джун за 3-5 лет, ибо не инженерные задачи, в которых можно расти десятки лет.
Код в статье лучше бы в орм выполнить.
Это холиварная тема, я бы предпочел SQL пользоваться, а не ORM. Или SQL-билдером вроде Jooq.
Да и когда он упадет?
В тестах, например. Можно же ассерты выставить только для тестов. Но вообще я бы эту функцию не писал, чтобы каждый раз на месте решать, какой тип лока нужен.
Если нужна проверка, что код работает в транзакции - это проблема архитектуры
Согласен.
Орм хорош когда нужно делать простой круд, коего в любом приложении 99%. Если нужны хитрые запросы, например, при построении отчетов, или нужен перворманс, то ничего не мешает и сырые запросы гнать - такие случаи в приложении ну прям очень ограничены и специфичны. Посмотрите на sqlalchemy в питоне или, прости господи, джанго орм, там всё гораздо универсальнее чем в джаве и есть возможность выбирать способ формирования запросов тремя способами.
простой круд, коего в любом приложении 99%
Чего? Сколько круда в таком приложении, как Kafka? Представляете, кафку тоже кто-то пишет. И у этих разработчиков не то, что круда никакого нет, у них и базы данных нет!
Ну мы тут больше про корпоративные приложения. А если делается какой-то специализированный софт, то там оптимизаций столько, что требуется сильный разработчик, и если это вчерашний студент, то было бы неплохо, чтобы он проходил практику, касаемо разработки этого продукта, чтобы в штате уже не заниматься очевидной ерундой.
откуда будут появляться мидлы/синьоры, если джуны никому не нужны и никто их бедных не хочет? ну да, "не наши проблемы", понимаю
Один выгоревший сеньор или два джуна с горящими глазами?