Очень смущает ваша точка зрения о существовании какого-то сеньорити в рамках конкретной технологии/платформы. Быть сеньором не значит иметь глубокие знания в конкретной технологии. Сеньоры с глубокими знаниями в конкретных технологиях просто встречаются сильно чаще именно потому что они сеньоры (как антропный принцип). Вообще говоря, я уверен что можно быть сеньором не обладая глубокими знаниями ни в одной технологии/платформе, а обладая знаниями в математике CS и культуре работы в цикле ресерч -> продукт.
По самой статье, кажется мне что весь разговор ни о чем. Я имею в виду спор fullstack, singlestack, stack-agnostic и тп. Все эти названия и попытки прикрепить специализации нам (программистам) вроде вообще не нужны. Но они точно нужны работодателям/рекрутерам для экономии. Но поскольку есть спрос, то появляется и предложение — цикл с обратной связью, где программисты начинают развиваться вглубь технологий, поощряя все эти специализации.
Более интересный путь развития о котором я очень мало слышу, но в который верю — это прокачка понимания культуры программирования и решение бизнес-проблем через нее. С логически последовательной культурой программирования можно построить и поддерживать успешный (с точки зрения разработки) продукт в новой для себя области без каких-либо знаний технологий в этой области.
Очень близкий механизм использует typescript для поддержки tsx синтаксиса. Только там кроме билдеров нужно еще и информацию о типах нод объявлять для автокомплита внутри tsx контекста. Странно что этот proposal нигде не упоминает ее. Обычно в swift evaluation везде указывают существующие решения в других языках/платформах.
На мой вкус реализация в typescript чуть функциональнее для пользователя API. Если кому интересно, то я писал о ней на хабре.
Потому что Haskell требует работы на очень высоком абстрактном уровне.
Для повседневных задач этот самый уровень абстракции не такой уж и высокий — почти тот же уровень что дженерики. Так что аргумент именно с абстракцией кажется недостаточным.
А вообще, человечество очень неплохо развивается в плане оперирования абстрактными сущностями. К примеру, современный выпускник не видит никаких проблем с математическими операциями над отрицательными числами, хотя европейским математикам они были чужды до 17 века.
Раз в этом треде много курильщиков, может у кого есть релевантный опыт.
Курю с 19 и когда курил сигареты, то спокойно мог не курить неделями потому что сами сигареты противны на вкус и запах. Даже самое лучшее что тогда было доступно (ричмонд произведённый на донском табаке) было противным.
А потом поехал в Азию, а там все было ещё хуже (нормальных сигарет нет вообще) и тогда я сделал роковую ошибку — попробовал самокрутки из нормального чистого табака. Подсел быстро, жестко и надолго (уже пять лет). Все негативные эффекты обычных сигарет, которые стимулируют перестать курить отсутствуют или на минимуме. Я уже год не понимаю что делать с этим потому что курить приятно, по-настоящему приятно и вкусно.
Странно что в такой большой организации нет понятия корпоративной культуры и, соответственно, проверка ее соответствию на первых этапах собеседований. Корпоративная культура как раз с формой и качеством общения хорошо борется;
Непонятно как это может "в команде появиться новый сотрудник" без одобрения команды. У команды и ее тимлида последнее слово по найму пиров;
Какое отношение к этой истории имеет зарплата этого нового сотрудника? Если он смог договорится на лучшие условия — честь ему и хвала. Я долгое время работал в команде c лидом, который получал в 2.5 раза меньше меня (я договорился лучше чем он) и это никак не влияло на нашу работу;
Непонятно сколько сеньор-разработчиков в команде, из статьи следует что больше одного, но это просто невозможно. Если есть достаточно опыта чтобы считаться сеньором, то этот же опыт включает умение нейтрализации таких коллег как Джанни. Это чуть ли ни азы командной работы;
Тимлид тупо не сделал своей работы. Еще страннее что он не был отстранен от своей должности после расследования;
То же самое к менеджеру тимлида;
И к HR, пропустившей сообщение о проблеме;
Если возможно "На меня посыпались саркатические шутки о моих формулировках на английском, а медиатор над ними мило поржал" на митинге с медиатором, то тут два варианта — уходить из компании потому что она прогнившая насквозь или, если веришь в продукт и людей, идти по очереди по всей цепочке менеджеров по разработке и по HR;
Смена команды для внутри компании худшее что может быть в такой ситуации, если есть план поработать в этой компании какое-то продолжительное время — по факту это сдача своей команды. Это как если бы антитела уходили в незараженную часть тела чтоб не встречаться с вирусом. Если антитела эти умрут раньше чем вирус дойдет до их новой части тела, то для них все ок, а если нет, то вирус их и там догонит и бежать уже некуда. Телу (компания в этой метафоре) хуже всего, конечно;
Тут было много чего еще, но оно все в итоге сводится к тимлиду и его менеджеру, а они, как мы выяснили уже, не делали своей работы;
Перечитал. Я бы ушел из компании с такими серьезными проблемами.
Значение -540 означает, что часовой пояс на 540 минут опережает целевой. Обратите внимание на минус, хотя смещение Сеула содержит плюс (+09:00). Не знаю, почему, но отображается именно так.
Там минус потому что это значение разницы между локальным временем и UTC.
Ещё одна особенность в том, что этот метод не про информацию о часовом поясе в объекте на котором он вызывается, а про локальную для системы. И это метод не статичный потому что он возвращает разницу на основе информации про день, месяц и год на объекте даты на котором вызван (чувствуется нехватка разных объектов Date, Time и DateTime в JS).
По факту, с помощью этого метода можно узнавать историческую и текущую информацию о разнице между часовым поясом в хосте и UTC.
На TypeScript и nodejs. Я тогда создал удобный модульный фреймворк для написания этого бота (да и кучи других ботов для внутренних нужд компании). Его можно посмотреть у меня в гитхабе https://github.com/dempfi/xene. Для распознавания вопросов и поиска ответа использовал https://js.tensorflow.org.
В проекте есть мой заброшенный PR в котором можно подсмотреть простую распозновалку с нейронкой — хотел добавить в стандартную поставку фреймворка.
Только предупреждаю: я фреймворк давно не обновлял. Парни из моей команды его форкнули и продолжают поддерживать но уже внутри компании. Не в OSS из-за чисто юридической подоплёки — форк поддерживают в рабочее время, а все что пишется в рабочее время принадлежит компании.
В одной прошлой компании где я работал я решал эту же проблему. Компания была удалённая и большая — вся коммуникация в slack. Решение само напросилось: каждый раз когда кто-то задавал вопрос в чатах, бот находимо подходящий ответ в базе знаний и постил в чат. Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.
Штукой этой было реально удобно пользоваться — никуда из слэка выходить не нужно было и месяца через два люди вообще сами перестали спрашивать в группах а спрашивали бота напрямую.
Мне кажется, что самый честный и к тому же простой вариант с донатом — это разрешить авторам которым интересен донат вставлять ссылку на patreon и подобные в футер своих постов. Таким образов вы снимете кучу головной боли связанной с денежными потоками — они идут полностью мимо вас напрямую к заинтересованным авторам, с платежными сервисами и вообще с проблемой авторов, которые не хотят донат.
ТС, обратите внимание на notion — там из коробки есть почти все что вы описали + лучше права доступа и куча классных функций именно для командной работы. Ну и вообще инструмент создавался для решения этой самой проблемы обмена знаниями (включая типизированные) в коллективе и отлично ее решает.
Удобство макбуков для меня заключаются в операционной системе (удобство железки это второе). В удобстве операционки основной я бы виделил следующее:
ОС даёт мне доступ к хорошему коммерческому (OmniFocus, Sketch, Adobe Illustrator, Microsoft Office, Haskell Dev Platform, LittleSnitch, Alfred etc) и бесплатному (Idea, VSCode, iTerm, IINA, Transmission etc) софту, включая специфичный софт (FontLab, Glyphs, Lego DD, MotionPro, Xcode). Все что мне нужно для работы и хобби;
Нормальная консоль;
Очень хорошое коммьюнити, выпустившое такие чудесные штуковины как IINA, iTerm, brew;
Хорошая интерграция с телефоном. Я понятия не имею как я жил раньше без возможности скопировать на смартфоне и вставить на компе и наоборот;
TimeMachine;
Тут было ещё, что можно суммировать в «остальная ОС более-менее сносно работает»;
Я рассматривал переход на Ubuntu/Elementary (внутренний параноик требовал) и это оказалось невозможным — аналоги программ хуже по качеству/функционалу, какой-то софт вообще нечем заменить. То же самое с виндой.
Я бы посмотрел на компанию, которая первой построит завод на морской платформе в международных водах. Вообще тема производственных и научных центров свободных от предубеждений (ГМО, исследования со стволовыми клетками, клонирование и куча других) в международных водах звучит интересно.
Бесплатными путями (reddit, hacker news и прочие) можно сделать рекламу и это не требует особых скиллов маркетинга;
OSS — это отличный способ учиться с пользой. Я, например, не могу делать одни и те же hello world’ы на новой технологии и предпочитаю портировать полезную OSS библиотеку (включая ее релиз в репозиторий пакетов). Сразу получаю реальный, близкий к проду, опыт с новым языком и платформой и при этом помогаю чуть-чуть сделать технологию лучше;
OSS — это самый доступный способ для разработчика оказаться один на один со своими клиентами и заиметь опыт в полном цикле разработки продукта включая тот же маркетинг, ведение продукта, общение с клиентами и стратегическое планирование. Невероятно недооценённый и полезный аспект;
Некоторые компании используют поддержку OSS начинаний своих разработчиков в первую очередь для комфорта этих самых разработчиков. Счастливый разработчик — продуктивный разработчик. Из моего опыта, все компании где поддерживали OSS входили именно в эту категорию;
Больше двух более-менее популярных проектов одному потянуть сложно. Более-менее популярный — это сотни звёзд на гитхабе. Поэтому хорошо бы как можно раньше находить людей в коммьюнити (если они сами не проявились к этому моменту) кому можно делегировать хотя бы разгребание Issues.
Есть ещё огромное количество вещей связанных не с ведением своего проекта, а с помощью другим проектам, но статься не о том.
То что у вас на скриншоте — это проблема встроенной подсветки синтаксиса для C в vscode с одной стороны и отсутствия поддержки в темах с другой. Поскольку правила для синтаксиса С в vscode напрямую взяты из того самого atom'а, то можно легко их обновить.
ТС, если хочешь и денег и творчества — иди в ресёрч отдел какой-нибудь большой компании. Там тебе и денег много дадут и твори сколько влезет интересные вещи.
Вот тебе совет. Найди контакт (вот тебе твиттер @lorentzframe) Браяна Бэкмана (он очень дружелюбный и открытой человек) из бывшего Microsoft Research и текущего Amazon Robotics; спроси у него как попасть в этот самый Microsoft Research; набери скиллов которых ещё нет и стучись к ним. Дерзай, в общем!
Понял теперь вашу мысль и согласен — если все решается через синтаксис языка, то сложность и выразительность будут тесно связаны.
Определенно есть положительная корреляция. Любая новая фича требует как минимум места в голое для запоминания. А если у неё еще и свой синтасксис, то тем более.
Есть языки в которых нет операторов прибитых гвоздями в компиляторе. Вместо них используется уже известные функции + инфиксная нотация, что запомнить легче чем кучу операторов с разными правилами. И при этом с ними можно описать сильно больше явлений. Вот и получили простоту с большей выразительной мощью.
И, если нигде не сделал логических ошибок, самые выразительные языки имеют минимум синтаксиса и правил, по факту оперируя несколькими довольно простыми концепциями (Haskell какой-нибудь или Clean).
Чем сложнее язык, тем богаче фразы, составленные с его помощью, и тем лучше он может выразить требуемую предметную область.
Спорное утверждение про зависимость между сложностью и выразительностью. Кажется, что сложность языка и его выразительная мощь ортогональны. (G)ADT, к примеру, очень простая штука, дающая ощутимый буст к выразительной мощности.
Очень смущает ваша точка зрения о существовании какого-то сеньорити в рамках конкретной технологии/платформы. Быть сеньором не значит иметь глубокие знания в конкретной технологии. Сеньоры с глубокими знаниями в конкретных технологиях просто встречаются сильно чаще именно потому что они сеньоры (как антропный принцип). Вообще говоря, я уверен что можно быть сеньором не обладая глубокими знаниями ни в одной технологии/платформе, а обладая знаниями в математике CS и культуре работы в цикле ресерч -> продукт.
По самой статье, кажется мне что весь разговор ни о чем. Я имею в виду спор fullstack, singlestack, stack-agnostic и тп. Все эти названия и попытки прикрепить специализации нам (программистам) вроде вообще не нужны. Но они точно нужны работодателям/рекрутерам для экономии. Но поскольку есть спрос, то появляется и предложение — цикл с обратной связью, где программисты начинают развиваться вглубь технологий, поощряя все эти специализации.
Более интересный путь развития о котором я очень мало слышу, но в который верю — это прокачка понимания культуры программирования и решение бизнес-проблем через нее. С логически последовательной культурой программирования можно построить и поддерживать успешный (с точки зрения разработки) продукт в новой для себя области без каких-либо знаний технологий в этой области.
Очень близкий механизм использует typescript для поддержки tsx синтаксиса. Только там кроме билдеров нужно еще и информацию о типах нод объявлять для автокомплита внутри tsx контекста. Странно что этот proposal нигде не упоминает ее. Обычно в swift evaluation везде указывают существующие решения в других языках/платформах.
На мой вкус реализация в typescript чуть функциональнее для пользователя API. Если кому интересно, то я писал о ней на хабре.
Для повседневных задач этот самый уровень абстракции не такой уж и высокий — почти тот же уровень что дженерики. Так что аргумент именно с абстракцией кажется недостаточным.
А вообще, человечество очень неплохо развивается в плане оперирования абстрактными сущностями. К примеру, современный выпускник не видит никаких проблем с математическими операциями над отрицательными числами, хотя европейским математикам они были чужды до 17 века.
Раз в этом треде много курильщиков, может у кого есть релевантный опыт.
Курю с 19 и когда курил сигареты, то спокойно мог не курить неделями потому что сами сигареты противны на вкус и запах. Даже самое лучшее что тогда было доступно (ричмонд произведённый на донском табаке) было противным.
А потом поехал в Азию, а там все было ещё хуже (нормальных сигарет нет вообще) и тогда я сделал роковую ошибку — попробовал самокрутки из нормального чистого табака. Подсел быстро, жестко и надолго (уже пять лет). Все негативные эффекты обычных сигарет, которые стимулируют перестать курить отсутствуют или на минимуме. Я уже год не понимаю что делать с этим потому что курить приятно, по-настоящему приятно и вкусно.
Про чёрные дыри и о том, что же происходят при падении на неё мне больше всего нравится объяснение Сусскинда.
В этой истории очень многое странно.
Перечитал. Я бы ушел из компании с такими серьезными проблемами.
Там минус потому что это значение разницы между локальным временем и UTC.
Ещё одна особенность в том, что этот метод не про информацию о часовом поясе в объекте на котором он вызывается, а про локальную для системы. И это метод не статичный потому что он возвращает разницу на основе информации про день, месяц и год на объекте даты на котором вызван (чувствуется нехватка разных объектов Date, Time и DateTime в JS).
По факту, с помощью этого метода можно узнавать историческую и текущую информацию о разнице между часовым поясом в хосте и UTC.
На TypeScript и nodejs. Я тогда создал удобный модульный фреймворк для написания этого бота (да и кучи других ботов для внутренних нужд компании). Его можно посмотреть у меня в гитхабе https://github.com/dempfi/xene. Для распознавания вопросов и поиска ответа использовал https://js.tensorflow.org.
В проекте есть мой заброшенный PR в котором можно подсмотреть простую распозновалку с нейронкой — хотел добавить в стандартную поставку фреймворка.
Только предупреждаю: я фреймворк давно не обновлял. Парни из моей команды его форкнули и продолжают поддерживать но уже внутри компании. Не в OSS из-за чисто юридической подоплёки — форк поддерживают в рабочее время, а все что пишется в рабочее время принадлежит компании.
В одной прошлой компании где я работал я решал эту же проблему. Компания была удалённая и большая — вся коммуникация в slack. Решение само напросилось: каждый раз когда кто-то задавал вопрос в чатах, бот находимо подходящий ответ в базе знаний и постил в чат. Если информации не было, и кто-то давал ответ в чате, то одной командой можно было добавить пару вопрос/ответ в базу для следующих поисков.
Штукой этой было реально удобно пользоваться — никуда из слэка выходить не нужно было и месяца через два люди вообще сами перестали спрашивать в группах а спрашивали бота напрямую.
Мне кажется, что самый честный и к тому же простой вариант с донатом — это разрешить авторам которым интересен донат вставлять ссылку на patreon и подобные в футер своих постов. Таким образов вы снимете кучу головной боли связанной с денежными потоками — они идут полностью мимо вас напрямую к заинтересованным авторам, с платежными сервисами и вообще с проблемой авторов, которые не хотят донат.
ТС, обратите внимание на notion — там из коробки есть почти все что вы описали + лучше права доступа и куча классных функций именно для командной работы. Ну и вообще инструмент создавался для решения этой самой проблемы обмена знаниями (включая типизированные) в коллективе и отлично ее решает.
Единственное чего ещё нет — API для расширений.
Удобство макбуков для меня заключаются в операционной системе (удобство железки это второе). В удобстве операционки основной я бы виделил следующее:
Я рассматривал переход на Ubuntu/Elementary (внутренний параноик требовал) и это оказалось невозможным — аналоги программ хуже по качеству/функционалу, какой-то софт вообще нечем заменить. То же самое с виндой.
Я бы посмотрел на компанию, которая первой построит завод на морской платформе в международных водах. Вообще тема производственных и научных центров свободных от предубеждений (ГМО, исследования со стволовыми клетками, клонирование и куча других) в международных водах звучит интересно.
Понял вас. Вообще есть шанс что сами разработчики vscode обновят правила в ходе плановой синхронизации с атомом.
Отличная статья, спасибо что написали.
Дополню пару моментов.
Есть ещё огромное количество вещей связанных не с ведением своего проекта, а с помощью другим проектам, но статься не о том.
Рад что кто-то на хабре пользуется моим поделием. А расскажите где контраст страдал, можно в личку.
То что у вас на скриншоте — это проблема встроенной подсветки синтаксиса для C в vscode с одной стороны и отсутствия поддержки в темах с другой. Поскольку правила для синтаксиса С в vscode напрямую взяты из того самого atom'а, то можно легко их обновить.
Если сделаете первую часть — я с радостью добавлю поддержку в мою ayu.
ТС, если хочешь и денег и творчества — иди в ресёрч отдел какой-нибудь большой компании. Там тебе и денег много дадут и твори сколько влезет интересные вещи.
Вот тебе совет. Найди контакт (вот тебе твиттер @lorentzframe) Браяна Бэкмана (он очень дружелюбный и открытой человек) из бывшего Microsoft Research и текущего Amazon Robotics; спроси у него как попасть в этот самый Microsoft Research; набери скиллов которых ещё нет и стучись к ним. Дерзай, в общем!
Понял теперь вашу мысль и согласен — если все решается через синтаксис языка, то сложность и выразительность будут тесно связаны.
Есть языки в которых нет операторов прибитых гвоздями в компиляторе. Вместо них используется уже известные функции + инфиксная нотация, что запомнить легче чем кучу операторов с разными правилами. И при этом с ними можно описать сильно больше явлений. Вот и получили простоту с большей выразительной мощью.
И, если нигде не сделал логических ошибок, самые выразительные языки имеют минимум синтаксиса и правил, по факту оперируя несколькими довольно простыми концепциями (Haskell какой-нибудь или Clean).
Спорное утверждение про зависимость между сложностью и выразительностью. Кажется, что сложность языка и его выразительная мощь ортогональны. (G)ADT, к примеру, очень простая штука, дающая ощутимый буст к выразительной мощности.