Pull to refresh
53
11.3

Разработчик

Send message

Саморегулирование бизнеса даже в развитых странах - очень неоднозначная тема. Самый яркий пример последних лет - это Боинг, главу которого недавно ушли в отставку из-за постоянных проблем с самолетами. Начались они, кстати, после того, как FAA передало массу функций регулирования авиакомпаниям, чтобы они сами себя проверяли, безопасность и т.д. Итог, что называется, налицо.

Вообще-то специально для такого рода вещей существует такое явление, как закрытые суды - конкретно в США это https://en.wikipedia.org/wiki/United_States_Foreign_Intelligence_Surveillance_Court - если бы спецслужбам США удалось нарыть какие-то данные по поводу тик-тока, можете не сомневаться, CEO давал бы показания в совершенно другой обстановке.

А что, презумпция невиновности уже не действует? Я как раз прочитал тоже полностью стенограмму слушаний, и допрашивавшие его тоже задавали вопросы, не приводя никаких доказательств, что ТикТок реально что-то сливает в Китай. Собственно, если бы это удалось доказать, то тут не было бы нужды в новых законах, там и по старым притянуть ByteDance можно было бы.

Знаем мы вас, австрийцев. Был тут во главе Германии уже один австриец!

Напиши текст для главной страницы сайта regionsoft.ru

И уже на первом примере становится ясно, что автор статьи не понимает, как работает ChatGPT. Это модель, обученная на данных до 2021 года включительно, не имеющая выход в интернет. Вы какой текст ожидаете там увидеть?

Хорошее правило, которое предлагает небезызвестный Andrew Ng в своем курсе Generative AI for everyone - стажер без опыта справится с этим? Да даже не стажер, представьте, матерый копирайтер с 20-летним опытом, которому Вы даете такое задание, но при этом запрещаете даже залезть в интернет. Что он наваяет? Чему посвящен ваш сайт? Может, региональной компании разработки софта? Или, может, производству мягких матрацев? Если софта, то какого? Написание драйверов для заводских микроконтроллеров, или сайты клепаем?

Как правильно? Есть три варианта:

  • Воспользоваться нейросетью, имеющей доступ в интернет. Скажем, copilot от MS так умеет.

  • Применить технику RAG - т.е. взять набор релевантных документов (в данном случае набор страниц сайта) и скормить их как контекст в запросе.

  • Применить технику Fine tuning - т.е. скормить пару тысяч фраз о вашем сайте сети, чтобы она сама адаптировалась.

  • Обучить нейросеть самому. Я сказал выше "три варианта", потому что этот четвертый очень сомнительный, если только у вас нет аппаратных мощностей Гугла или эквивалентных.

А вообще надо заметить, что нейросети обладают одним грешком - они пасуют сказать пользователю, что его запрос неадекватен, и давай-ка сам это сделай по такому запросу. Таки в нейросети стоит добавить немного токсичности, на мой взгляд.

ИТ (ИТ-шники) - это не только кодеры (программисты), но и аналитики/проектировщики, тестировщики, менеджеры проектов. Про них я что-то не увидел в статье.

Как программист, я не могу давать советы, как вкатиться в аналитику или менеджмент проектов).

Хороший вопрос. Мне видится скорее метрика другого рода. Скажем, синьор раздает задачи джунам, потом ревьювит их код и так далее. И синьор те же задачи кидает нейросети, потом напильником дорабатывает сгенерированное решение. Как только время на работу с нейросетью сравнится в среднем с временем, потраченным на джунов, можно ожидать резкого сокращения штата программистов.

В выступлении много спорных моментов. Меня особо порадовал этот:

Затем в 2000-х годах появились Scala, C#, Go, а в 2010-х — Swift, TypeScript, Dart и Rust. И опять же, каждый из них был своего рода упрощённой версией языков, которые возникли ранее.

Ага, ну да, особенно Scala, очень простой язык. Точно так же Typescript - я бы не сказал, что он проще каких-то языков, появившихся ранее, я бы скорее сказал, что он благодаря типизации позволяет избежать очень многих ошибок, которые сложно отловить в javascript.

Google и другие конкуренты постоянно переманивают самых умных и
талантливых сотрудников. Происходит отток талантливых кадров. Microsoft
вынуждена нанимать на их место студентов прямо из колледжа. В итоге
ребята уровня SDE и SDE II поддерживают огромные системы с кучей кода.
Они хотят сделать как лучше и достаточно умны, но не понимают, почему в
своё время раньше были приняты те или иные решения. Не разбираются в
тонкостях работы своих систем и самое главное, не хотят менять то, что
уже работает. Эти юные разработчики также склонны улучшать систему,
внедряя совершенно новые функции вместо того, чтобы улучшать старые.
Если посмотреть на последние релизы, то Microsoft не исправляет старые
функции, а добавляет новые (далее — цитата):

Позабавило, что в качестве альтернативы предлагается Гугл, где те же самые порядки - цитата из статьи на хабре же "Почему новый дизайн Gmail такой медленный?"

С его слов, все это происходит в силу того, что в Google не предусмотрено никаких наказаний за подобные «промахи».

В стенах компании активно поощряют запуски (launch) — публичные релизы
чего-либо. И то, что продукты могут содержать лишь половину необходимых
фич, не работать, работать только из-под Chrome и прочее — это никого не
волнует, ведь их создателям за это ничего не грозит. Это — норма.

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

Впрочем, почему только гугл и майкрософт? А как насчет Эппла?

Похожую историю рассказал разработчик Стив,
работавший в Apple над MacOS X Snow Leopard. Стив по большей части
занимался тем, что исправлял баги во всех основных фреймворках ОС — и по
итогам выпуска ему было отказано в повышении из-за того, что его
присутствие «не было критически важным ни на одном из проектов».

Ирония здесь заключается в том, что данная версия ОС по идее руководства
компании должна была стать релизом, в котором все было направлено на
улучшение стабильности и производительности системы. Однако, в то время
как одни ожидаемо работали над стабильностью, другие активно
«пропихивали» в релиз новые фичи вроде сборщика мусора для Objective-C,
чем задержали работу остальных и сделали XCode неюзабельным на несколько
месяцев.

Так что проблема общая для всех корпораций.

Моя ошибка состояла в том, что я не проверял домашки. Прочитаю лекцию, покажу что-то на практике — всё понятно? Отлично, идём дальше! 

Так продолжалось 4 месяца, пока я не спросил, чем константы отличаются от переменных.

То есть Вы не только не проверяли домашние задания, но даже и не пытались устроить тестирование знаний хотя бы после первых пары недель? Уже сам факт, что человек на все говорит "все понятно" - является первым тревожным симптомом. По сути Вы потратили и свое время, и время ученика зазря (хотя, если он Вам платил, то Вы тратили не зря).

По-моему, эта статья может быть выражена очень коротко:

Почему я больше не буду учить программированию? Потому что преподавать это не мое.

Смысл денег именно в их универсальности.

Не совсем. Напоминаем, что в СССР безналичные рубли и наличные находились в двух разных контурах, которые не пересекались. Схожая идея долгое время существовала в КНР (внешний офшорный юань и внутренний). Смысл, как пример - в том, чтобы деньги, крутяющиеся в индустрии, нельзя было автоматом вывести на потребительский рынок обычных товаров, чтобы это привело к инфляции.

Мне кажется, Domain Driven Design здесь описан вообще не к месту. Давайте разберемся:

Спустя полчаса после запуска «работающее ПО» внезапно рухнуло из-за непредусмотренного (а значит, и неуправляемого) наплыва большого количества одновременных пользователей. Клиент считал, что менеджер по продукту и команда разработки должны немедленно устранить критическую проблему. Запуск был отменён.

Вопрос "Сколько одновременно ожидается клиентов на пике и сколько в среднем в минуту/час/день" никакого отношения к DDD не имеет и относится скорее к теме Scalability/Highload. Менеджер обязан был озаботиться им в любом случае, когда задача только ставилась. Надо было проводить нагрузочное тестирование и профилирование приложения. Если этого не делать, то даже написанное идеально с точки зрения DDD решение рухнет сразу после релиза.

«Я верю вам, но вы не ответили на мой вопрос: проектировали ли вы продукт на основании сценариев работы пользователей?», — ответил менеджер.

«Но вы не дали нам никаких сценариев. Мы проектировали продукт для поддержки любого пользовательского сценария. Пользователи могут делать всё, что хотят», — гордо заявил руководитель команды разработки.

Это опять же не связано напрямую с DDD, а скорее напоминает модную среди менеджеров идею под соусом перехода к DevOps разогнать к чертям команды бизнес-аналитиков и тестировщиков. Такие подразделения имелись в компаниях разработки задолго до появления DDD в природе. Также, как и стремление менеджеров срезать косты, сократив эти части проекта. Даже если бы разработчики написали все на DDD, это никак бы не спасло.

Подводя итог - DDD - это офигенная вещь, но она не имеет никакого отношения к истории, которая приводится как аргумент в ее пользу.

@Scinquisitorмне кажется, Вы не раз писали, почему все эти статьи о лабораторном происхождении ковида - чушь собачья. Не разъясните тут в комментариях, а то опять граждане тут пишут обжигающую ПРАВДУ.

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

Статья содержит два тезиса.

Тезис №1. Преподаватели тебе не друзья! И это верно. Помните из уроков истории про времена, когда дворяне массово знали по несколько иностранных языков? Как же этого добивались и какими удивительными методиками? Ответ прост - нанимающий тогда репетитора граф или барон имел несколько иные возможности воздействия на преподавателя, нежели нынешние клиенты. Если в течение пары лет сынок барона не навострялся говорить складно на иностранном языке, то преподаватель отправлялся в пытошную и оттуда уже не возвращался. Поэтому преподаватели были крайне заинтересованы в результате своего обучения и не стеснялись даже пороть учеников, если вдруг какие-то заминки. В нынешние времена такой способ невозможен (к счастью), и это значит, что по сути никакого контроля над репетитором у вас нет. Максимум вы можете перестать пользоваться его услугами. Каких либо контрактов с обязательствами, что если вы в течение года не заговорите на уровне таком-то, то он вернет все деньги плюс штраф, такие школы никогда не подписывают. Поэтому преподаватель вам нужен скорее как консультант, которого надо пристрастно допрашивать и ставить ему задачу по решению каких-то конкретных затыков. Не ждите, что он сделает это за Вас.

Тезис №2. No pain, no gain. А вот это не совсем верно. Точнее, зависит сильно от психологических особенностей людей. Вдобавок здесь постулируется присущий советской школе принцип, что обучение в принципе очень тяжелый процесс, и если какой-то навык заработан без усилий, то это ненастоящий навык. Давайте разберем бредовость рекомендаций:

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

И где предлагается и с кем так говорить? Мы ведь сейчас про взрослых, которые на работе и едут домой из офиса. Где именно в день вы выкроите полтора часа на разговор и с кем именно?

Внимание должно уставать. Сильно. Первый месяц после занятий вы должны быть как выжатый лимон.

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

Вообще, природный способ, работающий на подходах Стивена Крэшера, неплох, именно потому, что человек может выкроить время для тренировок таким способом. Собственно, так подростком я английский и выучил, поскольку были доступны телеканалы на английском, вещающие на детей до десяти лет - т.е. там не такой сложный английский, чтобы он был непонятен. А вообще способов основных изучения языка около десяти. И причина в том, что люди разные, и подход, дающий результат первые два месяца, потом перестает работать, поскольку мозг начинает разъедать скукой, и нужно делать вариацию (как, собственно, и в тренировках мышц).

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

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

Спасибо за замечание, исправил. Нет, это не перевод.

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

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

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

Всего около 98% высказались за то, чтобы работать удаленно. У 91% опрошенных — лишь положительные впечатления от удаленки. И только у 1% он отрицательный.

Я бы уточнил насчет этого на основе сего детального анализа:

  • Если сотрудники разбежались на удаленку, то внезапно здания, которые компании принадлежат, переходят из asset в liability. Эппл затратил на свой головной офис 5 миллиардов. Если сотрудники в него не ходят, то по факту этот набор зданий приносит лишь затраты. Продать его можно попытаться, под давлением совета акционеров, но в условиях текущего рынка за него предложат гораздо меньше затрат. И даже если компания арендует офис, как правило (если мы говорим про американские реалии), контракт аренды на несколько лет. Поэтому его простой недопустим.

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

  • И опять же, при удаленном режиме летит к черту вся старая школа менеджмента в плане soft skills - поговорить с сотрудниками по душам в курилке, устроить после рабочего дня бильярд с ребятами в подсопке и т.д. Переучиваться тяжело - поэтому проще сотрудников в офис вернуть.

Почему только один вариант - обычно все вместе из упомянутого.

Мне, кстати, очень понравилась мысль создателя Scala Мартина Одерски. В одном из выступлений он сказал, что никогда не пишет реально хороший код с первого раза - проще написать плохой и затем его постепенно улучшать. Тут стоит отметить, что такой прием прокатывает, если плохой код не пишется более 2-3 недель, в противном случае затем рефакторить и улучшать его становится крайне нетривиальной задачей.

Information

Rating
467-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity