У меня есть вообще уникальный опыт общения с поддержкой о проблемах поддержки, которую не захотела решать поддержка.
Я как-то заказал товар из интернет-магазина в постомат Яндекса, написал в поддержку, чтобы уточнить, можно ли продлить срок хранения, либо надо спешить и забирать. Мне сообщили, что все продлили, но в итоге товар уехал из постомата, в поддержке заявили, что их сотрудник ошибся, на вопросы о компенсации стали извиняться, что подвели, реальных специалистов там нет, только копипастеры извинений.
По моему опыту, в поддержке все настолько плохо, что они могут буквально заставить человека потерять деньги, а потом сидеть и извиняться.
Жаль что мы редко что-то решаем, по факту есть менеджеры и заказчики, которые обычно там сами решают как, что должно выглядеть работать, и за сколько мы должны по их мнению это сделать. Ещё могу и технологии сами выбрать и сказать так вот надо. А я за это должен нести ответственность, нафиг.
Лично я вообще никогда не сталкивался с тем, чтобы кто-то из менеджеров явно говорил, что надо делать плохо, сроки важнее. Возможно, у других людей все иначе, но я такого не видел. Да, были ситуации, когда менеджмент хочет быстрее, но это ситуации больше похожие на "Вы готовы сделать это быстрее? Что для этого нужно? Готовы ли работать больше? К чему это приведет?" А многие разработчики, к сожалению, воспринимают это как давление и необходимость делать плохо, так как бизнес требует. И самое интересное, что потом, на других встречах, бизнес совершенно искренне говорит, что они не понимают, почему в проекте все так плохо, они готовы были дать разработчикам все нужное, им подтвердили сроки, а в итоге получился плохой продукт.
Но, надо признать, что чаще проще сделать плохо, чем объяснять, почему это плохо, к каким последствиям это приведет.
В целом, о российском BB у меня очень теплые воспоминания и отзывы. Самый кринж выдавали как раз крайне знаменитые и богатые иностранные компании, два ярких случая:
А первом компания подождала несколько месяцев, чтобы закрыть уязвимый сайт акции, а потом сказать, что они не могут воспроизвести проблему, так как сайт не открывается.
А во втором на довольно копеечную уязвимость была реакция вида: "На проде тестировать по правилам программы нельзя, вознаграждение за отчет с прода не дадим. Для тестирования есть специальный открытый тест. А на тесте нет угрозы от использования уязвимости, так как это тест, и он не используется в бизнес-процессе"
Проблема выглядит интересно, но вот второй аргумент от компании очень странный:
Кажется, что достаточно легко найти/купить старый аккаунт, слышал даже про специальные сервисы/людей, которые регистрируют аккаунты пачками на новых сервисах, чтобы потом перепродать их с хорошими именами или бонусами для старых клиентов.
Про уменьшение скоупа странный аргумент, создал аккаунт, подождал месяца 2 с небольшим, куча официантов вышла к новогодним праздникам подработать, перед праздниками присвоил их ссылке заранее созданным аккаунтам, вывел деньги, смотришь на то, как негодует толпа официантов, в маркетинг и безопасники пытаются после праздников объяснить, где все чаевые.
Плюс, вообще не понимаю тягу сотрудников ИБ снижать критичность багов. И так довольно много людей считает, что в BugBounty надо нести мелочь, которую сложно реализовать выгоднее, так ещё тем, кто приносит реально серьёзную проблему, говорят, что она не серьезная.
Хотел бы ещё спросить, сталкивался ли кто-то с проверкой безопасности проектов с использованием GraphQL? Есть ли какие-то полноценные инструкции, рекомендации или неочевидные моменты, на которые стоит обратить внимание?
Имхо, причина во многом в том, что с привлечения «кормится» слишком много разных людей.
Сначала продали идею, что рост - это самое важное, без него невозможно жить. Практически во всех статьях - «Мы растём», «Как мы растём», «Как вырастить компанию», «Без роста умрешь» и так далее.
Уже на продвинутый рост прибежали различные аналитики и консультанты, которые начали советовать способы привлечь новых клиентов, ведь очевидно, что без привлечения клиентов нет роста.
Дальше прибежали маркетологи и различные агенства, которые за очень небольшую сумму и разрешение приукрашивать качество товара готовы продвигать его и находить новых клиентов.
Потом прибежали условные блогеры, которые начали продвигать все. Очень сложно продвинуть товар существующему клиенту, поэтому цель - новые клиенты.
Эта огромная толпа людей не особо заинтересована в том, чтобы отпускать те бюджеты, которые они контролируют. А удержание - это часто задачи небольшого количества людей, которых можно легко обвинить, что они не могут сделать нормальный продукт, когда вся толпа привела много новых клиентов, а они ушли.
Зачастую, повышение качества работы приводит к повышению нагрузки на сотрудников, а им это не надо (и не всегда выгодно в целом). Для меня идеальный пример - поддержка Яндекса. Я считаю их самой плохой службой поддержки, которую встречал в последнее время, крайне давно не видел настолько большого нежелания разбираться с проблемами и делать что-то кроме написания шаблонных извинений,
Однако, понимание того, что взаимодействие с поддержкой будет крайне неприятным, мотивирует меня меньше к ним обращаться и терпеть то, что я бы не стал терпеть в случае нормальной службы поддержки. Плохой сервис помогает меньше работать.
Маршруты были возможны, конечно. Но разница в том, что для этого требовалось либо перебирать все возможные точки посадки и высадки, либо очень хорошо знать особенности дорог. А сейчас можно было получить оптимизированный маршрут быстро, количество таких поездок может сильно возрасти.
Интересное мнение таксистов о таких нововведениях, насколько более или менее выгодно и приятно возить людей на небольшие расстояния от метро и до метро, если сравнивать с более длинными маршрутами?
Имхо, это не уровень Хабра. Посмотрите продукт, сравните с аналогом - Nginx, поговорите с разработчиками и спросите, какие у продукта есть преимущества, опишите это человеческим языком. Сейчас это выглядит не очень хорошо, так можно дойти до репоста Release Notes крупных репозиториев с Гитхаба.
Надо понимать очень важный момент: Flash Call, Voice Code и CallPassword ID имеют очень серьёзные идейные, архитектурные и технические уязвимости. Разные компании разного размера пытались внедрить такие подходы, это приводило к стабильным проблемам.
Любой разработчик или архитектор, который внедряет такую технологию без полного понимания, что и зачем он делает, должен понимать, что он расписывается либо в том, что ему и сервису наплевать на данные пользователей в нем (или на то, кто будет отвечать за действия злоумышленника от имени пользователя), либо в том, что разработчик - опасное некомпетентное существо, которое не способно подумать и почитать материалы, но лезет интегрировать неизвестную ему нестандартную технологию.
Работодатели в ходе опроса hh.ru отмечали, что главная причина, почему они отказывают в трудоустройстве потенциальным соискателям — это завышенные зарплатные ожидания. Об этом заявили сразу 82% опрошенных компаний.
Я всегда кричу чайкой от этого термина, "Завышенные зарплатные ожидания". Я вчера не купил домик в центре Москвы, у продавца были завышенные оплатные ожидания, я был готов дать 70 тысяч, а он почему-то захотел 500 миллионов, пришлось отказать ему в продаже.
Абсолютно нормально хотеть большую зарплату, и абсолютно нормально, что многие компании не готовы/не могут позволить себе столько платить. Одни спокойно платят среднему по уровню разработчику 800 тысяч, а другие говорят, что он охреневший кодер, который хочет зарплату больше, чем у их директора.
Не надо сводить все к завышенным ожиданиям кандидатов, часто бывают сниженные возможности работодателей.
SMS-идентификация проводится на основании двух факторов:
фактор знания (наличие кода)
вещественный фактор (телефон с нужным номером)
А при получении доступа к телефону СМС-код остается в тайне? И нужен ли доступ к телефону, если человек знает код? Это не выглядит как несколько факторов...
Но основное преимущество беспарольной SMS-авторизации — это продвинутая киберзащита, которая намного лучше обходит хакерские ловушки.
Не существует никаких "хакерских ловушек" и мифических "продвинутых киберзащит". Существуют конкретные технические проблемы, которые эксплуатируются злоумышленниками, и конкретные методы защиты. Тут нет магии и волшебных ловушек.
Использование многоразовых кодов требует вложений: на содержание техотдела, контроль безопасности системы аутентификации, приобретение спецоборудования, софта и так далее.
А СМС этого не требуют?
Если хотите построить безопасный сервис, то не читайте рекламные статьи на Хабре. А то следующая статья от другой компании будет рассказывать, как вы неправильно все сделали, что воспользовались не их инструментом.
Периодически появляются мнения, что на некоторых платформах менеджмент специально продвигает такие доработки, которые делают процессы максимально непрозрачными и неопределёнными. Как зарабатывать себе «премию», если все понятно и просто? А так - условные 400 долларов за бан конкурента, 300 - за защиту от бана, 200 - за информацию о нарушении, ещё сколько-то - за выбор правильного участника в программу продвижения. А если все правильно описать, то люди будут нести деньги и благодарить про этом за то, что человек помогает работать на платформе, где такие ужасные условия и тупые программисты.
То, что описано в статье - великолепнейший пример фейкового повышения эффективности методом правильного подбора метрик. Либо LinearB просто гении скама, либо при переводе потерялось что-то важное.
улучшение (т.е. снижение) в размерах pull request-ов на 33,2%; улучшение в продолжительности цикла на 47,27%; улучшение в сроках проведения инспекции кода на 46,82%; улучшение в скорости отклика на 48,75%.
Просто механически режем PR примерно пополам, оставляя стандартные изменения версий, комментарии и так далее, получаем реальное снижение разрабатываемого кода в задаче где-то в два раза, отчетного объема - на треть. Все остальное уменьшилось (логично, проверять задачи в два раза меньшего размера проще). По метрикам - бомбический успех.
Половина pull request-ов простаивает (иными словами, никто не ведет над ними активной работы) не менее 50% своего жизненного цикла.
Обычно это происходит, когда разработчик разрабатывает другие задачи... Если PR просматривают мгновенно, то разработчики явно очень свободны.
размер pull request-ов дополнительно снизился на 28,18%; продолжительность цикла дополнительно сократилась на 61,07%; сроки инспекции кода дополнительно улучшились на 38,14%; скорость отклика дополнительно увеличилась на 56,04%.
Еще раз режем пополам задачи, убираем часть проверок "представить возможность автоматического одобрения низкорисковых pull request-ов.", задачи стали пролетать вообще как ракеты.
Из изменения показателей разработки надо очень осторожно выводить изменения показателей эффективности.
Неужели компьютерные мальчики и девочки и их тимлиды на своих хакатонах не понимают
Они прекрасно это понимают. Просто у абстрактных разработчиков есть выбор, делать бессмысленных вредных ботов за свои 800-900 тысяч с перспективой дорасти до миллионов в месяц за руководство направлением условной автоматизированной поддержки покупателей, либо пойти за гораздо меньшие деньги и без перспектив верстать удобные меню.
Боты в большинстве случаев - это весёлая ситуация, когда клиент оплачивает низкоквалифицированному дорогостоящему разработчику создание услуги, которая будет бесить его и доставлять неудобства.
За все время своего взаимодействия с ботами я помню только два случая, когда они реально были удобными.
Второй кейс - это идеальный пример вредного ИИ. Если сравнить исходные требования и результат, то бот переврал требования (кто-то требовал глубокие знания?) и добавил три пункта, которых не было. Фактически, 4 из 7 пунктов (учитывая название) были перевраны.
Задача грамотного рекрутера - четко донести до заказчика, что если он не потратит час на грамотное описание для своих вакансий, то потратит 100 часов на собеседования и жалобы в интернете «Памагите, я выгарел, вокруг одни тупые кодеры, работаю по 200 часов в неделю, не могут никого найти».
При плохой работе смежных подразделений рекрутеры с ИИ будут закидывать эти подразделения огромным потоком неподходящих кандидатов, что сделает ситуацию ещё хуже.
Насколько я вижу, предыдущая статья этого автора была опубликована именно в корпоративном блоге Пактикума. Если ее нельзя перенести в корпоративный блог, то почему бы не перенести в «Я пиарюсь»? Статья, очень похожая на рекламную, содержавшая ссылки для отслеживания (как выше писали), имхо, не должна висеть, как обычная статья. Даже если компания купила себе корпоративный блог. Это не очень хороший прецедент.
Возможно, тогда стоит перенести статью в корпоративный блог? Иначе получается немного странная ситуация, когда из-за наличия корпоративного блога статья, весьма вероятно, являющаяся рекламной, не находится в «Я пиарюсь», но при этом и не находится в корпоративном блоге.
Решением этих трех проблем были онлайн курсы. Я занялся поиском провайдера, чтением отзывов и выбором курса. Помню, тогда выбирал из двух вариантов, это был Hexlet и Яндекс Практикум. Эти две онлайн школы по отзывам внушали доверие, но цены, конечно, отпугивали.
В итоге решающим фактором в пользу Практикума для меня стали два пункта: опытные наставники из компаний с именем и возможность платить только за ту часть обучения, которую уже прошел. Можно было в любой момент отказаться, если что-то не нравилось. В итоге я выбрал Яндекс Практикум, курс «Python разработчик».
И
Другие платформы я не рассматривал. Во-первых, знал, что у ребят за плечами — бренд Яндекса, и ударить в грязь лицом нельзя, а значит, качество курса будет хорошее. Во-вторых, сама программа устроена так, что ты постоянно практикуешься, а твой наставник делает код-ревью. Такого взгляда со стороны часто не хватает, особенно опытным специалистам.
Все же, вы выбирали между Яндексом и Хекслетом? Или все же не рассматривали другие платформы, кроме Яндекса?
Примерно к десятому спринту, несмотря на то, что для меня само понимание материала не вызывало трудностей — я выгорел. Совмещал работу (разработчиком) с учебой (на разработчика) — и поэтому у меня не оставалось свободного времени. Силы меня покинули, и было два выхода – либо уходить в академ (взять официальный перерыв от учебы и вернуться позже), либо отчисляться из Практикума. Я выбрал второе. Посчитал, что достиг своей цели в понимании нового для себя языка программирования, узнал много нового — и на этом можно остановиться.
И
Что было дальше? Через несколько месяцев после выпуска я увидел, что у Практикума начали появляться курсы для разработчиков с опытом.
Вы в итоге выпустились? Или отчислились? Есть небольшая разница между этими результатами.
У меня есть вообще уникальный опыт общения с поддержкой о проблемах поддержки, которую не захотела решать поддержка.
Я как-то заказал товар из интернет-магазина в постомат Яндекса, написал в поддержку, чтобы уточнить, можно ли продлить срок хранения, либо надо спешить и забирать. Мне сообщили, что все продлили, но в итоге товар уехал из постомата, в поддержке заявили, что их сотрудник ошибся, на вопросы о компенсации стали извиняться, что подвели, реальных специалистов там нет, только копипастеры извинений.
По моему опыту, в поддержке все настолько плохо, что они могут буквально заставить человека потерять деньги, а потом сидеть и извиняться.
Лично я вообще никогда не сталкивался с тем, чтобы кто-то из менеджеров явно говорил, что надо делать плохо, сроки важнее. Возможно, у других людей все иначе, но я такого не видел.
Да, были ситуации, когда менеджмент хочет быстрее, но это ситуации больше похожие на "Вы готовы сделать это быстрее? Что для этого нужно? Готовы ли работать больше? К чему это приведет?" А многие разработчики, к сожалению, воспринимают это как давление и необходимость делать плохо, так как бизнес требует.
И самое интересное, что потом, на других встречах, бизнес совершенно искренне говорит, что они не понимают, почему в проекте все так плохо, они готовы были дать разработчикам все нужное, им подтвердили сроки, а в итоге получился плохой продукт.
Но, надо признать, что чаще проще сделать плохо, чем объяснять, почему это плохо, к каким последствиям это приведет.
В целом, о российском BB у меня очень теплые воспоминания и отзывы. Самый кринж выдавали как раз крайне знаменитые и богатые иностранные компании, два ярких случая:
А первом компания подождала несколько месяцев, чтобы закрыть уязвимый сайт акции, а потом сказать, что они не могут воспроизвести проблему, так как сайт не открывается.
А во втором на довольно копеечную уязвимость была реакция вида: "На проде тестировать по правилам программы нельзя, вознаграждение за отчет с прода не дадим. Для тестирования есть специальный открытый тест. А на тесте нет угрозы от использования уязвимости, так как это тест, и он не используется в бизнес-процессе"
Проблема выглядит интересно, но вот второй аргумент от компании очень странный:
Кажется, что достаточно легко найти/купить старый аккаунт, слышал даже про специальные сервисы/людей, которые регистрируют аккаунты пачками на новых сервисах, чтобы потом перепродать их с хорошими именами или бонусами для старых клиентов.
Про уменьшение скоупа странный аргумент, создал аккаунт, подождал месяца 2 с небольшим, куча официантов вышла к новогодним праздникам подработать, перед праздниками присвоил их ссылке заранее созданным аккаунтам, вывел деньги, смотришь на то, как негодует толпа официантов, в маркетинг и безопасники пытаются после праздников объяснить, где все чаевые.
Плюс, вообще не понимаю тягу сотрудников ИБ снижать критичность багов. И так довольно много людей считает, что в BugBounty надо нести мелочь, которую сложно реализовать выгоднее, так ещё тем, кто приносит реально серьёзную проблему, говорят, что она не серьезная.
Хотел бы ещё спросить, сталкивался ли кто-то с проверкой безопасности проектов с использованием GraphQL? Есть ли какие-то полноценные инструкции, рекомендации или неочевидные моменты, на которые стоит обратить внимание?
Имхо, причина во многом в том, что с привлечения «кормится» слишком много разных людей.
Сначала продали идею, что рост - это самое важное, без него невозможно жить. Практически во всех статьях - «Мы растём», «Как мы растём», «Как вырастить компанию», «Без роста умрешь» и так далее.
Уже на продвинутый рост прибежали различные аналитики и консультанты, которые начали советовать способы привлечь новых клиентов, ведь очевидно, что без привлечения клиентов нет роста.
Дальше прибежали маркетологи и различные агенства, которые за очень небольшую сумму и разрешение приукрашивать качество товара готовы продвигать его и находить новых клиентов.
Потом прибежали условные блогеры, которые начали продвигать все. Очень сложно продвинуть товар существующему клиенту, поэтому цель - новые клиенты.
Эта огромная толпа людей не особо заинтересована в том, чтобы отпускать те бюджеты, которые они контролируют. А удержание - это часто задачи небольшого количества людей, которых можно легко обвинить, что они не могут сделать нормальный продукт, когда вся толпа привела много новых клиентов, а они ушли.
Зачастую, повышение качества работы приводит к повышению нагрузки на сотрудников, а им это не надо (и не всегда выгодно в целом). Для меня идеальный пример - поддержка Яндекса. Я считаю их самой плохой службой поддержки, которую встречал в последнее время, крайне давно не видел настолько большого нежелания разбираться с проблемами и делать что-то кроме написания шаблонных извинений,
Однако, понимание того, что взаимодействие с поддержкой будет крайне неприятным, мотивирует меня меньше к ним обращаться и терпеть то, что я бы не стал терпеть в случае нормальной службы поддержки. Плохой сервис помогает меньше работать.
Маршруты были возможны, конечно. Но разница в том, что для этого требовалось либо перебирать все возможные точки посадки и высадки, либо очень хорошо знать особенности дорог. А сейчас можно было получить оптимизированный маршрут быстро, количество таких поездок может сильно возрасти.
Интересное мнение таксистов о таких нововведениях, насколько более или менее выгодно и приятно возить людей на небольшие расстояния от метро и до метро, если сравнивать с более длинными маршрутами?
Это просто голый Release Note на Хабре?
Имхо, это не уровень Хабра. Посмотрите продукт, сравните с аналогом - Nginx, поговорите с разработчиками и спросите, какие у продукта есть преимущества, опишите это человеческим языком. Сейчас это выглядит не очень хорошо, так можно дойти до репоста Release Notes крупных репозиториев с Гитхаба.
Надо понимать очень важный момент: Flash Call, Voice Code и CallPassword ID имеют очень серьёзные идейные, архитектурные и технические уязвимости. Разные компании разного размера пытались внедрить такие подходы, это приводило к стабильным проблемам.
Любой разработчик или архитектор, который внедряет такую технологию без полного понимания, что и зачем он делает, должен понимать, что он расписывается либо в том, что ему и сервису наплевать на данные пользователей в нем (или на то, кто будет отвечать за действия злоумышленника от имени пользователя), либо в том, что разработчик - опасное некомпетентное существо, которое не способно подумать и почитать материалы, но лезет интегрировать неизвестную ему нестандартную технологию.
Я всегда кричу чайкой от этого термина, "Завышенные зарплатные ожидания". Я вчера не купил домик в центре Москвы, у продавца были завышенные оплатные ожидания, я был готов дать 70 тысяч, а он почему-то захотел 500 миллионов, пришлось отказать ему в продаже.
Абсолютно нормально хотеть большую зарплату, и абсолютно нормально, что многие компании не готовы/не могут позволить себе столько платить. Одни спокойно платят среднему по уровню разработчику 800 тысяч, а другие говорят, что он охреневший кодер, который хочет зарплату больше, чем у их директора.
Не надо сводить все к завышенным ожиданиям кандидатов, часто бывают сниженные возможности работодателей.
А при получении доступа к телефону СМС-код остается в тайне? И нужен ли доступ к телефону, если человек знает код? Это не выглядит как несколько факторов...
Не существует никаких "хакерских ловушек" и мифических "продвинутых киберзащит". Существуют конкретные технические проблемы, которые эксплуатируются злоумышленниками, и конкретные методы защиты. Тут нет магии и волшебных ловушек.
А СМС этого не требуют?
Если хотите построить безопасный сервис, то не читайте рекламные статьи на Хабре. А то следующая статья от другой компании будет рассказывать, как вы неправильно все сделали, что воспользовались не их инструментом.
Периодически появляются мнения, что на некоторых платформах менеджмент специально продвигает такие доработки, которые делают процессы максимально непрозрачными и неопределёнными. Как зарабатывать себе «премию», если все понятно и просто? А так - условные 400 долларов за бан конкурента, 300 - за защиту от бана, 200 - за информацию о нарушении, ещё сколько-то - за выбор правильного участника в программу продвижения. А если все правильно описать, то люди будут нести деньги и благодарить про этом за то, что человек помогает работать на платформе, где такие ужасные условия и тупые программисты.
То, что описано в статье - великолепнейший пример фейкового повышения эффективности методом правильного подбора метрик. Либо LinearB просто гении скама, либо при переводе потерялось что-то важное.
Просто механически режем PR примерно пополам, оставляя стандартные изменения версий, комментарии и так далее, получаем реальное снижение разрабатываемого кода в задаче где-то в два раза, отчетного объема - на треть. Все остальное уменьшилось (логично, проверять задачи в два раза меньшего размера проще). По метрикам - бомбический успех.
Обычно это происходит, когда разработчик разрабатывает другие задачи... Если PR просматривают мгновенно, то разработчики явно очень свободны.
Еще раз режем пополам задачи, убираем часть проверок "представить возможность автоматического одобрения низкорисковых pull request-ов.", задачи стали пролетать вообще как ракеты.
Из изменения показателей разработки надо очень осторожно выводить изменения показателей эффективности.
Они прекрасно это понимают. Просто у абстрактных разработчиков есть выбор, делать бессмысленных вредных ботов за свои 800-900 тысяч с перспективой дорасти до миллионов в месяц за руководство направлением условной автоматизированной поддержки покупателей, либо пойти за гораздо меньшие деньги и без перспектив верстать удобные меню.
Боты в большинстве случаев - это весёлая ситуация, когда клиент оплачивает низкоквалифицированному дорогостоящему разработчику создание услуги, которая будет бесить его и доставлять неудобства.
За все время своего взаимодействия с ботами я помню только два случая, когда они реально были удобными.
Второй кейс - это идеальный пример вредного ИИ. Если сравнить исходные требования и результат, то бот переврал требования (кто-то требовал глубокие знания?) и добавил три пункта, которых не было. Фактически, 4 из 7 пунктов (учитывая название) были перевраны.
Задача грамотного рекрутера - четко донести до заказчика, что если он не потратит час на грамотное описание для своих вакансий, то потратит 100 часов на собеседования и жалобы в интернете «Памагите, я выгарел, вокруг одни тупые кодеры, работаю по 200 часов в неделю, не могут никого найти».
При плохой работе смежных подразделений рекрутеры с ИИ будут закидывать эти подразделения огромным потоком неподходящих кандидатов, что сделает ситуацию ещё хуже.
Насколько я вижу, предыдущая статья этого автора была опубликована именно в корпоративном блоге Пактикума. Если ее нельзя перенести в корпоративный блог, то почему бы не перенести в «Я пиарюсь»? Статья, очень похожая на рекламную, содержавшая ссылки для отслеживания (как выше писали), имхо, не должна висеть, как обычная статья. Даже если компания купила себе корпоративный блог. Это не очень хороший прецедент.
Возможно, тогда стоит перенести статью в корпоративный блог? Иначе получается немного странная ситуация, когда из-за наличия корпоративного блога статья, весьма вероятно, являющаяся рекламной, не находится в «Я пиарюсь», но при этом и не находится в корпоративном блоге.
Спасибо, я ценю это. Достойно уважения, на самом деле.
Давайте посмотрим две ваши статьи: https://habr.com/ru/articles/752858/ и https://habr.com/ru/companies/yandex_praktikum/articles/729618/
Решением этих трех проблем были онлайн курсы. Я занялся поиском провайдера, чтением отзывов и выбором курса. Помню, тогда выбирал из двух вариантов, это был Hexlet и Яндекс Практикум. Эти две онлайн школы по отзывам внушали доверие, но цены, конечно, отпугивали.
В итоге решающим фактором в пользу Практикума для меня стали два пункта: опытные наставники из компаний с именем и возможность платить только за ту часть обучения, которую уже прошел. Можно было в любой момент отказаться, если что-то не нравилось. В итоге я выбрал Яндекс Практикум, курс «Python разработчик».
И
Другие платформы я не рассматривал. Во-первых, знал, что у ребят за плечами — бренд Яндекса, и ударить в грязь лицом нельзя, а значит, качество курса будет хорошее. Во-вторых, сама программа устроена так, что ты постоянно практикуешься, а твой наставник делает код-ревью. Такого взгляда со стороны часто не хватает, особенно опытным специалистам.
Все же, вы выбирали между Яндексом и Хекслетом? Или все же не рассматривали другие платформы, кроме Яндекса?
Примерно к десятому спринту, несмотря на то, что для меня само понимание материала не вызывало трудностей — я выгорел. Совмещал работу (разработчиком) с учебой (на разработчика) — и поэтому у меня не оставалось свободного времени. Силы меня покинули, и было два выхода – либо уходить в академ (взять официальный перерыв от учебы и вернуться позже), либо отчисляться из Практикума. Я выбрал второе. Посчитал, что достиг своей цели в понимании нового для себя языка программирования, узнал много нового — и на этом можно остановиться.
И
Что было дальше? Через несколько месяцев после выпуска я увидел, что у Практикума начали появляться курсы для разработчиков с опытом.
Вы в итоге выпустились? Или отчислились? Есть небольшая разница между этими результатами.