Comments 155
Наслаждайтесь временем, в котором значение «хотел крови» и «расстрельные списки» не совпадает с прочтением.
А какая была статья увольнения интересно или все это не в РФ происходило?
Обычно в таких случаях увольняют по собственному желанию.
Сейчас стараются «по соглашению сторон», потому что «по собственному» на раз откатывается обратно работником.
«По соглашению сторон» используют в двух случаях:
а) «по собственному» предполагает увольнение через две недели после написания заявления, а «по собственному» — в любое время.
б) и если расстаются с работником по-хорошему, то «по соглашению сторон» предполагает больше социальных льгот.
Насчёт «откатываться обратно работником», никакой разницы нет, судебный спор в обоих случаях одинаковый будет. Ну и опять же таки, крайне мало кто захочет возвращаться в компанию, в которой напрочь разругался с руководством. Это только от безысходности, когда денег нет, новой работы тоже на горизонте нет, и надо хоть чуть чуть протянуть, даже если там будут каждый день нервы выносить, либо получить более устойчивую позицию в споре «я и сам уйду, но давайте мне компенсацию».
а) «по собственному» предполагает увольнение через две недели после написания заявления, а «по собственному» — в любое время.
б) и если расстаются с работником по-хорошему, то «по соглашению сторон» предполагает больше социальных льгот.
Насчёт «откатываться обратно работником», никакой разницы нет, судебный спор в обоих случаях одинаковый будет. Ну и опять же таки, крайне мало кто захочет возвращаться в компанию, в которой напрочь разругался с руководством. Это только от безысходности, когда денег нет, новой работы тоже на горизонте нет, и надо хоть чуть чуть протянуть, даже если там будут каждый день нервы выносить, либо получить более устойчивую позицию в споре «я и сам уйду, но давайте мне компенсацию».
В случае «по соглашению сторон» никакого суда по ТК быть не может, вот в чём вся соль.
Может, прежде всего если оспаривать формулировку "по соглашению сторон" и требовать изменить её на "сокращение штата", например.
Соглашение оно на то и соглашение, что вы добровольно согласились. Ни один суд не будет подобным заниматься.
Или примеры из судебной практики в студию.
Или примеры из судебной практики в студию.
А если не добровольно, а под угрозой составления ложного акта о злостном нарушении трудовой дисциплины? Или вообще применения силы? Или злонамеренно был введён в заблуждение об альтернативах или просто не знал о своих правах?
А по собственному желанию на то и по собственному, что вы добровольно уволились (но это не точно).
Хотя перед этим вам угрожалиохрана избиением, эйчар внесением в черные списки, а инфбезопасность уголовным делом(шутка. а может нет?) за отосланный емейл.
Так что я и здесь не вижу, почему вдруг суд должен вступаться за сотрудника, который вспомнил, что это было не совсем его собственное желание.
Или что соглашение было достигнуто без учета мнения второй стороны.
В обоих случаях это привязано к расторжению трудового договора
Хотя перед этим вам угрожали
Так что я и здесь не вижу, почему вдруг суд должен вступаться за сотрудника, который вспомнил, что это было не совсем его собственное желание.
Или что соглашение было достигнуто без учета мнения второй стороны.
В обоих случаях это привязано к расторжению трудового договора
В случае «по соглашению сторон» никакого суда по ТК быть не может, вот в чём вся соль.
Мы же говорим не про отзыв заявления об увольнении, а про «вынужденное увольнение под давлением работодателя». В таком случае суд может быть независимо от формулировки.
По собсвенному могут уволить в день подачи заявления, есть работодатель согласен.
Зарплата за этот срок и за тот, который накапает в последующих разборках. Наиболее прошаренные выжидают месяц и идут в суд, если работодатель не подготовился к такому варианту, то с очень большой долей вероятности суд встанет на сторону работника, а это восстановление в должности и зарплата за период «простоя».
Вернее немного не так. На 13ый день с почтой отправляется письмо об отзыве заявления, происходит расчёт, а через несколько дней работодатель узнаёт, что этот человек у них по-прежнему работает.
Вернее немного не так. На 13ый день с почтой отправляется письмо об отзыве заявления, происходит расчёт, а через несколько дней работодатель узнаёт, что этот человек у них по-прежнему работает.
Да от компании зависит. Я могу «гордиться» в какой-то мере, самая дорогая ошибка в моей жизни, которую совершили мы с коллегами, стоила восьмизначную цифру. В долларах США. Да, мы остались без премий и месяц исправляли последствия. Но нас не уволили, хотя пожурили убедительно :)
Когда я работал в другой компании, уже начальником, один из моих хлопцев тоже сделал дорогой факап, хотя и несравнимый (за сумму предыдущего можно было несколько таких компаний целиком купить). Руководство хотело крови и увольнения, но в итоге даже премию не тронули, я просто донёс до них мысль, что причина ошибки — не халатность, а банальное стечение обстоятельств, которые живой человек не в состоянии на 100% предугадать. И увольнять профессионального ответственного сотрудника, который один раз ошибся, это глупо.
Когда я работал в другой компании, уже начальником, один из моих хлопцев тоже сделал дорогой факап, хотя и несравнимый (за сумму предыдущего можно было несколько таких компаний целиком купить). Руководство хотело крови и увольнения, но в итоге даже премию не тронули, я просто донёс до них мысль, что причина ошибки — не халатность, а банальное стечение обстоятельств, которые живой человек не в состоянии на 100% предугадать. И увольнять профессионального ответственного сотрудника, который один раз ошибся, это глупо.
Зато есть и другие крайности. Я был свидетелем когда уволили классного программиста (стаж примерно 20 лет в компании), которого посадили на самый сложный и древний участок кода. И почти сразу уволили когда там обнаружили ошибку, которую сделал тот программист в силу сложности.
И это ведь была куча глаз, которые сделали review и пропустили. Потом был QA, который тоже пропустил. Потом был pre-prod, который тоже пропустил. Но нужна была «кровь» на отчёте начальства.
И это ведь была куча глаз, которые сделали review и пропустили. Потом был QA, который тоже пропустил. Потом был pre-prod, который тоже пропустил. Но нужна была «кровь» на отчёте начальства.
Я подозреваю, что просто его хотели «уйти» и нашли причину.
Нет, точно не это. Там была чисто политика и начальство должно отчитаться о том, что меры были приняты. Слишком уж публичным был результат косяка, даже в новостях писали об этой проблеме.
A почему тогда не QA, ведь они, в таком случае, подписались тоже? Снаружи разницы никакой, особенно для новостей.
Ребята оказались банально «ценнее», чем «классный» программист.
В этом вся и фишка. «QA» это не конкретный человек, там сложнее найти виноватого. А тут вроде как очевидный и конкретный человек.
На вопрос «кто сделал баг?» ответ очевиден даже домохозяйке. А вот вопрос «почему баг не заметили?» задаёт уже человек, который разбирается в процессе.
На вопрос «кто сделал баг?» ответ очевиден даже домохозяйке. А вот вопрос «почему баг не заметили?» задаёт уже человек, который разбирается в процессе.
Определенная комбинация данных / конкретные условия и т.д. Проверить все и на 100% невозможно. Это аксиома.
Найти электрика сложнее чем программиста, так что ничего удивительного.
Суровые нравы програмистов.
Когда я был совсем начинающим электриком, я протирал пыль и отключил электроснабжение половины огромного нефтехимического комбината. Это стоило мне 600 рублей премии в ценах 2004 года.
Я вам больше скажу:
В пору моего джунства, переходящего в мид — я раззорил под ноль целую фирму.
Не такой командой, правда, как «DELETE from users;» но все так же — манипуляциями с данными повредил и основную БД и бэкап.
И всё — фирма в десятки раз сдулась в оборотах, считай умерла, ибо без учета жить не смогла.
Любые действия без выяснения причин — признак дурости.
И увольнение выглядит как очень эмоциональный поступок.
Просто за счёт этого кто-то из управленцев уровнем повыше сохранил свое место и бонусы.
100%. Я сейчас наблюдаю подобное на бывшем месте работы. Человек с очень ограниченными техническими и лидерскими способностями, в силу чистой случайности назначенный менеджером — вместо налаживания работы просто увольнял инженеров одного за другим. К его вящему удивлению, в полу-миллионном городе все IT-шники так или иначе друг друга знают — и желающие на замену иссякли очень быстро. Но наш герой «решил» проблему, уволив HR-ку.
Ну вот к сожалению для нашего менеджмента характерно волевое решение вопросов.
Единичные крупные ошибки не всегда показательны.
Периодически повторяющиеся «средние» косяки должны заставить задуматься и о разрабе, и о процессе.
Периодически повторяющиеся «средние» косяки должны заставить задуматься и о разрабе, и о процессе.
Я не понял, это очередная реклама курсов что ли?
Ну надо отметить, что неплохая реклама.
Все утро потратил на поиски рекламы в статье. Пришлось обратиться за помощью. Бывший коллега (Макс, спасибо) указал на «рекламу» андроид школы. Поясню немного про нее. Так как не раскрыл в статье.
Тут имеется ввиду андроид школа, которая проводилась компанией в 2015 году совместно с Google. Проводилась она один единственный раз. На тот момент я искал работу андроид разработчиком и знакомый с универа сказал обратить внимание на эту компанию. Посмотрев на рейтинги и узнав, что офис находится в 30 минутах пешком от дома я решил попробовать туда устроиться.
На сайте компании увидел новость про андроид школу. Не помню сколько она длилась месяц или два, но факт в том, что оставалась неделя до ее конца. И мне пришлось за пару дней посмотреть все видео, пройти все тесты и сдать финальный тест, чтобы получить сертификат.
Зачем проходил школу? Хотел бумажку. Прям вот хотел. И не исключал возможные плюсы при устройстве на работу. «Я прошел вашу школу, берите меня».
В статье также упоминаются курсы. Это бесплатные курсы по андроид разработке на курсере из 5 частей. До сих пор храню с них все материалы. Хотя за 5 лет никогда ими не пользовался. Но пару раз проекты оттуда открывал за первые пол года работы.
Сертификат с курсеры за курсы я не получил, так как он выдавался за деньги. Но бесплатный сертификат с андроид школы меня сманил. Поэтому решил ее пройти.
Более того недавно заходил на курсеру и там даже записей нет в моем аккаунте о прохождении этих курсов. Хотя там все на максимум было сдано. Очень обидно. Курсера — не молодцы в этом плане. Может и у них кто базу грохнул.
Тут имеется ввиду андроид школа, которая проводилась компанией в 2015 году совместно с Google. Проводилась она один единственный раз. На тот момент я искал работу андроид разработчиком и знакомый с универа сказал обратить внимание на эту компанию. Посмотрев на рейтинги и узнав, что офис находится в 30 минутах пешком от дома я решил попробовать туда устроиться.
На сайте компании увидел новость про андроид школу. Не помню сколько она длилась месяц или два, но факт в том, что оставалась неделя до ее конца. И мне пришлось за пару дней посмотреть все видео, пройти все тесты и сдать финальный тест, чтобы получить сертификат.
Зачем проходил школу? Хотел бумажку. Прям вот хотел. И не исключал возможные плюсы при устройстве на работу. «Я прошел вашу школу, берите меня».
В статье также упоминаются курсы. Это бесплатные курсы по андроид разработке на курсере из 5 частей. До сих пор храню с них все материалы. Хотя за 5 лет никогда ими не пользовался. Но пару раз проекты оттуда открывал за первые пол года работы.
Сертификат с курсеры за курсы я не получил, так как он выдавался за деньги. Но бесплатный сертификат с андроид школы меня сманил. Поэтому решил ее пройти.
Более того недавно заходил на курсеру и там даже записей нет в моем аккаунте о прохождении этих курсов. Хотя там все на максимум было сдано. Очень обидно. Курсера — не молодцы в этом плане. Может и у них кто базу грохнул.
Читать и в конце увидеть рекламу, весь текст только ради одной строчки рекламы, разочарование(
Там была реклама? У меня уже видимо мозг натренирован, что пропускает её и даже не запоминает.
Ага, к сожалению, но это так prnt.sc/v3ek7f и после этой откровенной правды сразу становится не ясно на сколько материал истинен :(
Чем больше сила — тем больше ответственность!
Студент-программист, мнящий себя мега-бекендером с распознаванием речи на плюсах вдруг осознал, что ему просто нравится делать анимации на простых аппах для андроида. Ну, что тут скажешь.
+1
Куда уж мне до звания мега-бекендера в тот момент. Зеленый студент, не больше.
До этого момента я устал от бекенда и по этой причине пошел снова в универ для поиска другой области. Там и нашел андроид с его анимациями.
До этого момента я устал от бекенда и по этой причине пошел снова в универ для поиска другой области. Там и нашел андроид с его анимациями.
"Что дэлать, Что дэлать. Завыдоват будэм"
Человек нашёл себе себя. Надолго ли — время покажет, всё равно хорошо.
Оказалось, целую группу пользователей просто выпилили. Ее не было в продбазе
За харддел нужно крышкой пианино по пальцам, а за отсутсвие контроля целостности — самим пианино.
В 8 часов компания уволила человека, который все это заварил.
Копания буквально только что вложила огромные деньги в обучение человека а затем его уволила? браво
Только через пару лет я узнал, что это было недостижимо
Изучать матчасть после и случайно… сильно.
Вы уж простите: не зашло, тут КПДВ с известными бурундуками нужно как минимум.
Харддел все еще применяется много где. Базовый принцип: если у вас дефрагментация стоит дороже, чем хранение — храним. Иначе — выпиливаем.
Контроль целостности вполне мог быть. В таком случае выпиливаются не только пользователи, но и все принадлежащие им объекты. CASCADE DELETE и никаких вопросов к товарищу, что проектировал эту БД.
Контроль целостности вполне мог быть. В таком случае выпиливаются не только пользователи, но и все принадлежащие им объекты. CASCADE DELETE и никаких вопросов к товарищу, что проектировал эту БД.
Вот потому-то и не стоит использовать CASCADE DELETE по любому поводу...
Харддел все еще применяется много где. Базовый принцип: если у вас дефрагментация стоит дороже, чем хранение — храним. Иначе — выпиливаем.
Хранение в большинстве случаев во много раз дешевле восстановления данных. Я таких вещей навидался, происходящих исключительно изза харддела, что до утра могу излагать.
А каскадное удаление это уже не роялем… это каточком надо. Да к тому же _пользователей_? Сущность которая обычно слинкована вообще со всей базой? Хм, никаких вопросов говорите…
Нюню:
Предстояло мёржить базу за 7 часов, накатывать на ту, что в ноль, возвращать всех пользователей
PS. Но с другой стороны, чем больше людей делают такие глупости, тем выгодней смотрюсь я, когда это все исправляю. Так что в общем и целом — я не против)
Soft delete не нравится вским GDPR и ФЗ
Любую крупную систему, особенно финансовую разорвет в клочья если у нее постоянно удалять пользователей. Может обезличивать лучше? В любом случае решение нужно искать не в удалении. Примером собственно ютуб, например, может служить: заходишь в плейлист а там удаленные ролики сверху донизу, раздражает до одури, а это всего лишь развлекательный контент.
Кстати я бы еще понял если бы удалили записи помеченные на удаление не менее суток назад, с натяжкой, скрипя зубами, но ладно, но удаление каскадом сходу… ну такое.
Кстати я бы еще понял если бы удалили записи помеченные на удаление не менее суток назад, с натяжкой, скрипя зубами, но ладно, но удаление каскадом сходу… ну такое.
Мой код должны были заапрувить как минимум 4 человека.
Забавно, конечно, когда при таком суровом подходе к апруву в прод пролетает скрипт, который просто дропает часть данных. Я бы выгнал тимлида(или кто там рулит) за профнепригодность. Умные люди данные даже не дропают, а помечают, как неактивные, чтобы если что-то пошло не так, то восстановить можно за 5 минут. А дропаются уже сильно позже, если данные мешают.
Как по мне, тут недостаточно данных, чтобы судить, кто там дятел. Вполне вероятно, что скрипт, который дропает часть данных, как раз и являлся скриптом-сборщиком мусора, который должен был подчищать неактивные записи после некоторого периода времени… но что-то пошло не так в условии WHERE. Ну а почему проглядели аппруверы, тоже обычная ситуация. Когда через тебя проходит куча чужого кода, ты только на первых порах после повышения там всё внимательно выверяешь. Через какое-то время просто бегло просматриваешь, и на этом всё. Особенно если код от опытного программиста.
Любой код, что дропает данные, неважно в базе, в файловой системе или где-то удаленно, должен отсматриваться крайне внимательно именно, чтобы избежать невозвратных потерь данных и простоя системы. Если выстроенные процессы прохождения кода в прод такое все же пропускают, то они выстроены неверно и виноват тут тот, кто их внедрял и отвечает за них.
Если такое происходит — то это значит, что процесс превратился в культ Карго, движение есть, а результата нет. Лучше тогда апрувы вообще убрать по дефолту и оставить только для неопытных товарищей и важных изменений.
Через какое-то время просто бегло просматриваешь, и на этом всё
Если такое происходит — то это значит, что процесс превратился в культ Карго, движение есть, а результата нет. Лучше тогда апрувы вообще убрать по дефолту и оставить только для неопытных товарищей и важных изменений.
Даже беглый просмотр может выявить какие-то косяки. Вот сегодня разглядел на полотнах диффов многоязычной вёрстки украинский язык в шаблоне для русского.
Я своим подчиненным часто говорю: «Ну не могу же я сделать виноватым сам себя, поэтому виноват будет один из вас». К сожалению, в окружающей действительности это часто практикуется и в цепочке виновных отыгрались на том кто ниже по иерархии.
Да потому что апрув от 4 человек — это тупо формальность, которая чаще всего никакого практического смысла не имеет. Ну, может быть чешет ЧСВ тимлида, который думает как круто он построил процессы и какой у него крутой отдел разработки.
Это из серии, когда на собесе тебя два часа гоняют по алгоритмам, тонкостям языка и прочим хардкорам, а потом в работе сажают писать круды и лепить формочки. Тимлид просто заигрался в крутую айти-компанию, карго-культ, в общем.
Это из серии, когда на собесе тебя два часа гоняют по алгоритмам, тонкостям языка и прочим хардкорам, а потом в работе сажают писать круды и лепить формочки. Тимлид просто заигрался в крутую айти-компанию, карго-культ, в общем.
Если у каждого из четырёх 20% вероятности заметить имеющийся в коде косяк, то общая вероятность его перехватить около 60%.
А если бы ревьюер был один, и знал бы про это, то нашёл бы косяк с вероятностью 85%
Вероятность всегда 1/2.
Или заметят или нет.
Если у каждого из четырёх 20% вероятности заметить имеющийся в коде косяк, то общая вероятность его перехватить около 60%.
Наоборот. Стремится к нулю. Психология — а чего смотреть, если до меня уже крутой смотрел, но в «пол глаза» гляну для очистки совести, следующий — «А до меня уже два крутих смотрело, чего я там найду»…
4 человека апрувить? Это же как надо ваять решение и его дизайн?
Это же безумноно дорого и по «цене» будет сопоставимо сделать автотесты с «cases & QA...»
1) Нанимал бы хороших дорогих спецов на потенциально опасные участки разработки
2) Не давал бы джунам (особенно джунам с самомнением) работать на хоть сколько-то чувствительных участках
3) Не отвлекал бы хороших дорогих спецов на чужие код-ревью. Код ревьюит непосредственный руководитель того, чей код. Он может быть из этих дорогих спецов, но это лично его зона ответственности.
2) Не давал бы джунам (особенно джунам с самомнением) работать на хоть сколько-то чувствительных участках
3) Не отвлекал бы хороших дорогих спецов на чужие код-ревью. Код ревьюит непосредственный руководитель того, чей код. Он может быть из этих дорогих спецов, но это лично его зона ответственности.
Ах, эти минусы без пояснения! Описанный мною алгоритм действий уже показал себя в моем отделе с хорошей стороны, в отличие от.
Да у нас тут в интернетах каждый имеет свой отдел, а каждый второй руководит управлением. Правда, потом начинаешь разбирать детали, вроде «как можно набрать хороших дорогих спецов на потенциально опасные участки разработки», если в общем случае отдел разработки — это не коробочка с людьми «взял, положил, взял, выкинул», у него есть штатное расписание, бюджеты, и возможность взять и нанять с улицы просто так под «появился потенциально опасный участок», во-первых, обычно отсутствует, во-вторых будет воспринята в штыки своими сотрудниками, которые там уже работают, в-третьих совершенно экономически неоправданна, в-четвёртых, совершенно не гарантирует качества и надёжности. И оказывается, что начальником отдела очередной эксперт стал пять минут назад, в момент написания комментария.
Да у нас тут каждый в комментариях мнит себя экспертом по вопросам, в которых не разбирается, приводя в пример какие-то абстрактные компании.
У кого обычно отсутствует? Есть какая-то выборка по компаниям, у кого отсутствует, у кого присутствует?
А вы точно хоть день руководителем работали?
Конечно, лучше набрать программистов подешевле, а потом ломать ночами голову как и на какие деньги за ними все переделывать.
и возможность взять и нанять с улицы просто так под «появился потенциально опасный участок», во-первых, обычно отсутствует
У кого обычно отсутствует? Есть какая-то выборка по компаниям, у кого отсутствует, у кого присутствует?
в штыки своими сотрудниками, которые там уже работают
А вы точно хоть день руководителем работали?
в-третьих совершенно экономически неоправданна
Конечно, лучше набрать программистов подешевле, а потом ломать ночами голову как и на какие деньги за ними все переделывать.
У кого обычно отсутствует? Есть какая-то выборка по компаниям, у кого отсутствует, у кого присутствует?
Хороший аргумент. Вы же знаете, что выборки нет. Но я не зря там написал про бюджеты, штатное расписание. Кто в курсе, тот поймёт.
А вы точно хоть день руководителем работали?
Уж поверьте. И руководителем, и рядовым программистом. И прекрасно помню разговоры в команде, когда на какую-то задачу, которую могли и решали командой, по указке какого-то там манагера брали дорогих перцев с улицы. Демотивирует дай боже. Будете начальником, постарайтесь помнить про это.
Конечно, лучше набрать программистов подешевле, а потом ломать ночами голову как и на какие деньги за ними все переделывать.
Речь не про «дешевле», а про то, что собственные разработчики, имеющие опыт работы с вашей системой и достаточно времени на эту работу, будут эффективнее нового разраба «с улицы». И людей в команду берут тогда, когда собственных ресурсов не хватает, а не когда «у нас появился ответственный участок, не доверяю я своим разработчикам, давайте искать нового».
Вы снова о чем-то своем. Какие программисты с улицы? Если я вписываюсь в разработку потенциально дорогого проекта — я изначально наберу на него сильных и дорогих разрабов. Или вы хотите сказать, что средненький проект вдруг в какой-то день превращается в проект на миллиард? Я такого еще ни разу не встречал, я думаю вы тоже.
Я в курсе. И я так же прекрасно в курсе, что если проект важный и в нем крутятся большие деньги — в него тоже вкладывают большие деньги.
Но я не зря там написал про бюджеты, штатное расписание. Кто в курсе, тот поймёт.
Я в курсе. И я так же прекрасно в курсе, что если проект важный и в нем крутятся большие деньги — в него тоже вкладывают большие деньги.
Вы снова о чем-то своем. Какие программисты с улицы? Если я вписываюсь в разработку потенциально дорогого проекта — я изначально наберу на него сильных и дорогих разрабов
У вас мухи с котлетами перемешаны. Мы разве только про дорогие стартапы говорим? Бизнес, который с самого начала создавался как бизнес на миллиард — это редчайшее исключение, про которое в газетах пишут. Все крупные компании начинали маленькими, у которых обороты были в десятки и сотни тысяч, а не миллиарды. И даже стартапы-единороги становятся такими не в одночасье (а выживают, несмотря на доступность дорогих кадров, не очень часто).
Да, если вам дали гору денег и проект, и сказали: «Делай», то вы там можете кого угодно нанимать на пустую стройплощадку, естественно. И то, минуточку, десять дорогих разрабов — это миллион долларов в год. Притом, что кому-то из них надо будет модели данных делать, кому-то стили CSS рисовать. Надо ли вам десять дорогих, половина из которых будет ныть, что они делают не интересную и не соответствующую их квалификации, работу?
А если мы говорим об обычной растущей компании, у которой появляются новые онлайновые сервисы, растёт клиентская база и т.д., то там уже всегда есть своя команда, и у неё есть свои интересы, свой опыт и так далее. И перечёркивать это — плохая идея.
Я в курсе. И я так же прекрасно в курсе, что если проект важный и в нем крутятся большие деньги — в него тоже вкладывают большие деньги
Ну тогда вы должны быть ещё и в курсе, что большие деньги никак не гарантируют качество, даже если вы их платите дорогому программисту.
Если я вписываюсь в разработку потенциально дорогого проекта — я изначально наберу на него сильных и дорогих разрабов. Или вы хотите сказать, что средненький проект вдруг в какой-то день превращается в проект на миллиард? Я такого еще ни разу не встречал, я думаю вы тоже.
Встречали. Только в другой интерпретации.
Типичная ситуация выглядит так: никто заранее не знает — а взлетит ли проект.
И потому брать сразу на него супер-перцев и давать этим супер-перцам кучу времени на разработку — верный способ разориться.
Поэтому типичная разработка выглядит так: сделать MVP подешевле побыстрее, запуститься, проверить как оно. И, скажу вам, потом MVP редко с нуля перепиливают, ведь проект уже запущен, просто наскоро сляпанный MVP допиливают и развивают.
Как это бывает в реальности расскажу:
Ну вот например на сегодня я пытаюсь скоординироваться с коллегой из другой компании. У нас и у них платежные системы.
Стоит задачи чтобы та компания отправляла нам данные о денежных транзакциях.
Казалось бы: деньги же, по сути, пересылаются — куда как серьезная задача? И программист, разработавший даже MVP платежной системы обязательно опытный перец?
Ага, конечно…
Там есть подзадача — электронная подпись транзакции. Она выглядит как «взять исходный запрос и сформировать подпись: хешировать содержмое запроса методом SHA1, результат хеширования зашифровать RSA».
Думаете у него какая то нетривиальная проблема с ключами или т.п.?
Нет.
Результат хэширования SHA1 — это бинарные данные.
То есть шифрованию RSA подвергаются уже бинарные данные.
И вот про эти бинарные данные мы это с ним 2 недели жуём. Я всё ему уже удаленно отладил. Нашел конкретное проблемное место в его коде:
он просто упорно результат хэширования из бинарного вида то в строку переводит, то вообще сериализирует внутренние объекты своего языка программирования — и в таком виде пытается применить RSA над результатом хэширования.
К слову, эта пара SHA1+RSA во многих программных библиотеках вообще одной функцией реализована, настолько это частая операция. Нужно только в библиотеку правильные параметры передать…
Я уж ему и рабочий пример с curl дал, где видно что и откуда и куда. И прямым текстом говорил, что данные должны быть бинарные.
Но для того человека «тип данных» — пустое слово. Ну не понимает он чем бинарные данные отличаются от текстовых или от внутреннего объектного представления.
Судя по этому факту и по прежним факапам их платежной системы — чел явно студент или джун. Но платежная система у них уже несколько месяцев как в проде. И через неё реальные миллионы ходят. И да — это ему разработку той платежной системы и поручили.
Вы можете сказать: ну это они сами виноваты, они еще с этим разработчиком хлебнут горя, но дело в том, что подобные вещи встречаются куда как чаще, чем вам кажется — никто не желает вкладываться в разработку слишком много. И как раз «совершенно правильный» но дико дорогой процесс встречается исчезающе редко, так как иначе фирма просто не сможет предложить достаточно низкие цены на свои товары. Бизнесмены осознанно предпочитают экономить и рисковать.
Хочется надеяться, что хотя бы ПО для самолётов,…, а-а-а-а, нет, уже была статья на Хабре кто в конечном итоге разрабатывал некоторые части ПО для самолётов…
P.S.:
Пусть вас не смущают старые способы хэширования/шифрования SHA1/RSA — сам протокол обмена данными разработан уже очень давно совсем другими разработчиками, чье ПО несколько лет назад доминировало на рынке. Доминация того ПО канула в прошлое, но их протокол и до сих пор является одним из нескольких стандартов обмена платежными данными де-факто. Его используют, наверное, сотни платежных систем, просто так этот протокол не поменять.
Забавно, конечно, когда при таком суровом подходе к апруву в прод пролетает скрипт, который просто дропает часть данных.
Дык, у 7 нянек дитя без глазу, впервой что ли такое наблюдать… А про умных людей и soft delete всякие GDPR с Вами сильно не согласны
Запустил на тестовом окружении — тестовые пользователи выпилились. Хм, посмотрел, как эта штука проверялась. Почему-то на этот раз, пусть у нас и три девстенда, первый и второй пропустили, а третий даже не свалился. Тест на это никто не писал (поставил себе галочку написать, чтобы больше такого не происходило).
Параллельно со мной так же сидели и искали проблему куча народу, постоянно созваниваясь. Наконец, в 6 утра мы поняли, что кто-то написал скрипт, проверил на тесте, но не учел один важный кейс. В итоге юзеры подпали под тех, что подлежали удалению
Самое главное "Тест на это никто не писал ". Это ошибка проектирования процессов разработки и тестирования. Какие претензии к разработчику? Это отвественость ПМ — его и «расстрелять».
Работал я как-то сисадмином в аспирантское время… Забэкапил я данные по инструкции (буховская БД), снес старую базу, поставил новую версию бухпрограммы, восстанавливаю бэкап… а он не восстанавливается, и мало того — при попытке восстановления отправляет комп в BSD! Две недели вся бухгалтерия восстанавливала базу за три месяца.
Если ты сделал бекап но не проверил восстанавливается ли он — считай что ты не сделал бекап.
> в следующие пару недель вылетели еще несколько причастных к этому случаю
Любопытно было бы вкратце узнать, как эти несколько были причастны к этому случаю (должности/роли)?
Потому что без этого рассказ звучит как то, что руководство среднего звена поняло, что ему несдобровать и решило по быстрому, воспользовавшись эмоциями непосредственно вовлеченных людей, избавиться от этих непосредственных свидетелей некомпетентности или халатности оного начальства.
Любопытно было бы вкратце узнать, как эти несколько были причастны к этому случаю (должности/роли)?
Потому что без этого рассказ звучит как то, что руководство среднего звена поняло, что ему несдобровать и решило по быстрому, воспользовавшись эмоциями непосредственно вовлеченных людей, избавиться от этих непосредственных свидетелей некомпетентности или халатности оного начальства.
В такой ситуации увольнять нужно не программиста, а начальника, который не выстроил процессы/систему таким образом, чтобы подобное не могло произойти (а реально, никого не нужно увольнять, а сделать выводы и работать дальше). Из того, что лично накосячил — еще будучи студентом тестил какой-то кусок интерфейса и не посмотрел, с каким он знаком платежи проводит. Короче, при зачислении со счета клиента списывали бабло. Несколько десятков проводок откатили, дали мне по шапке.
А не подскажете, как должны быть выстроены процессы, чтобы «подобное не могло произойти»?
ИМХО, вы ничем не отличаетесь от этих начальников, «есть косяк — должна пролиться кровь», вся разница только в том, чья.
ИМХО, вы ничем не отличаетесь от этих начальников, «есть косяк — должна пролиться кровь», вся разница только в том, чья.
В такой ситуации увольнять нужно не программиста, а начальника, который не выстроил процессы/систему таким образом, чтобы подобное не могло произойти
Есть подозрение, что реальность могла бы быть сложнее. Например, чувак накосячил, но это была не разовая акция, а планомерное длительное раздолбайство, которое вскрылось благодаря эпичному фейлу.
— Ты знаешь, что твоя ошибка стоила мне миллион?
— Да. Полагаю я уволен?
— Ты идиот? Зачем мне уволнять человека, на обучение которого я только что потратил миллион?
(с)
— Да. Полагаю я уволен?
— Ты идиот? Зачем мне уволнять человека, на обучение которого я только что потратил миллион?
(с)
Вот интересно, как народ ведется на рекламу…
Чего то еще обсуждают (100% выдуманную историю).
Ну наглая рекламная статья якобы от имени "физического человека".
Мы назвыаем себя инженерами, но почему-то считаем, что можно уронить прод и не быть за это уволенным. Нельзя.
Есть странные люди, называющие себя врачами, но почему-то считают, что можно потерять пациента, и не быть за это посаженным. Внезапно, можно.
Вообще, врачи могут нести в т.ч. и уголовную ответственность за смерть пациента.
Только если докажут, что он что-то сделал либо вопреки требованиям, либо не сделал то, что 100% требуется в данном случае.
Профессия врача намного более формализована, чем программиста.
Требований, что ты должен прописать в WHERE, а чего не можешь — не существует, как на уровне «министерства ИТ-технологий», так и в должностной инструкции.
Хотя если в должностной инструкции прописано, что любое изменение должно успешно пройти через 3 уровня/стенда тестирования, а чел прошёл только 2 — то вполне себе достаточная причина для увольнения. Уголовку, по идее, тоже можно привесить, если доказать большую сумму ущерба и явный умысел (халатности будет недостаточно, скорее всего, ибо не МОЛ).
Профессия врача намного более формализована, чем программиста.
Требований, что ты должен прописать в WHERE, а чего не можешь — не существует, как на уровне «министерства ИТ-технологий», так и в должностной инструкции.
Хотя если в должностной инструкции прописано, что любое изменение должно успешно пройти через 3 уровня/стенда тестирования, а чел прошёл только 2 — то вполне себе достаточная причина для увольнения. Уголовку, по идее, тоже можно привесить, если доказать большую сумму ущерба и явный умысел (халатности будет недостаточно, скорее всего, ибо не МОЛ).
Ну да, лечение по протоколу. Но только и тут программист не следовал протоколу, как пишет автор.
За врачебные ошибки очень даже увольняют, а за халатность можно даже сеть.
Защита от такого(Oops queries) должна быть в стандартном плане Disaster recovery. Если такого не было(или декларировалось что у нас все есть, а по факту ничего не было), то пожалуй да, увольнение это правильное решение. Но увольнять надо того кто за это отвечал, разработчик то не причем.
www.brentozar.com/archive/2016/07/updated-high-availability-disaster-recovery-planning-worksheet
www.brentozar.com/archive/2016/07/updated-high-availability-disaster-recovery-planning-worksheet
Простите, а как этот скрипт в прод улетел, если вы же сами говорите, что минимум четыре человека ревью делают?
Или это таки рекламный пост, содержание которого выдумано чуть более, чем полностью?
Или это таки рекламный пост, содержание которого выдумано чуть более, чем полностью?
Говорили, что человек пошел не по процессу. Четыре ревью проведено не было и один стенд с тестами был пропущен. Увы, на тот момент такое было возможно.
Вполне возможно, что каждый из этих четырёх человек понадеялся на остальных трёх в цепочке, и в итоге никто подробно код так и не посмотрел. Сам такое видел. Это как в анекдоте про евреев и котёл с водкой)
Так это как раз говорит о том, что виноват не конкретный уволенный человек (хотя он конечно виноват), а те, кто организовал подобную архитектуру, где программист может любую ерунду отправить в продакшен.
Так это как раз говорит о том, что виноват не конкретный уволенный человек (хотя он конечно виноват), а те, кто организовал подобную архитектуру, где программист может любую ерунду отправить в продакшен.
Всеохватывающая система на 100% гарантирующая от факапов — лишена смысла по чисто экономическим причинам. Проверки и перепроверки, перепроверки проверок — а кому работать-то?
На практике — если у вас есть такое желание и злой умысел, то с большой вероятностью вы всё равно сможете хакнуть систему «проверок и перепроверок».
Так что нормальные системы, которые финансово рациональны, предполагают, что конечные исполнители хотя бы худо-бедно старается факапов не допускать.
И если исполнители допускают косяки — доля вины в факапе есть и у организатора процесса и у конечных исполнителей. Накажут ли их — это другой вопрос.
Так всё гораздо проще — программисты вообще! не имеют доступа к продакшену, всеми изменениями в прод заведует специально обученный человек.
И всё, подобная ситуация просто в принципе исключена.
Да, конечно он в свою очередь может накосячить, но это уже как бы другой вопрос.
И всё, подобная ситуация просто в принципе исключена.
Да, конечно он в свою очередь может накосячить, но это уже как бы другой вопрос.
Так всё гораздо проще — программисты вообще! не имеют доступа к продакшену, всеми изменениями в прод заведует специально обученный человек.
И всё, подобная ситуация просто в принципе исключена.
Да ладно.
Даже не имея доступа к системе я вполне могу написать в недрах своего кода «DELETE FROM users;» и когда мой код выполнится в проде (а когда нибудь он выполнится, ибо цель написания кода — чтобы он когда-нибудь выполнился в проде) наступит жопа.
Если один программист имеет возможность завалить прод — то значит в организации процесса что-то совсем не так. О чём я и говорю.
Коммит>тесты и тестовое окружение>релиз/билд менеджер>прод.
Причём после коммита программист уже доступа непосредственно к закомиченному коду не имеет.
Странно, что на хабре подобные вещи приходится объяснять.
Коммит>тесты и тестовое окружение>релиз/билд менеджер>прод.
Причём после коммита программист уже доступа непосредственно к закомиченному коду не имеет.
Странно, что на хабре подобные вещи приходится объяснять.
Если один программист имеет возможность завалить прод — то значит в организации процесса что-то совсем не так.
Есть только одна возможность не дать программисту завалить прод: вообще не публиковать на проде его код, ни прямо, ни через код-ревью, не через деплой-менеджера, ни через деплой-менеджера после трёх код-ревью. Потому что чем сложнее система, тем больше есть способов протащить баг или злонамеренный код на прод при любой организации работ.
Система, на которой вы гоняете тесты, пусть незначительно, но всегда будет отличаться от прода — по URL'ам, по строкам подключений, по правам пользователей и т.д. Значит, уже есть возможность написать код, нормально работающий на тесте, и ненормально на проде.
Увидеть что-то кривое/плохое на код-ревью, это тоже рулетка, как повезёт. Могут увидеть, а могут и нет, особенно в свете того, что у ревьювера своей работы обычно хватает, и тщательно разбирать весь прилетевший от вас ворох изменений он тоже не рвётся, так, просто посмотрит на очевидные косяки. А деплой-менеджер… деплой-менеджер вообще не в курсе, что у вас там написано, его дело отдеплоить по инструкции, а не анализировать код на предмет багов.
Вы сначала говорите про банальный delete from users, который на тесте вылезет моментально, а потом про вырожденные ситуации с протаскиванием в прод хитрого злонамеренного кода. Ошибка и злой умысел как бы две совсем разных вещи. Это как админ, случайно положивший боевой сервер и админ, умышленно запустивший на него зловред.
Вон ниже хорошо написано, есть «ошибка, халатность и тупость» — вот как раз от них правильная архитектура и должна защищать в первую очередь.
Вон ниже хорошо написано, есть «ошибка, халатность и тупость» — вот как раз от них правильная архитектура и должна защищать в первую очередь.
Вы сначала говорите про банальный delete from users, который на тесте вылезет моментально
Ну так это же не одна строка… Реальное ПО намного неоднозначнее.
В реальности эффект «delete from users;» дает какое-то косвенное изменение кода.
Вон ниже хорошо написано, есть «ошибка, халатность и тупость» — вот как раз от них правильная архитектура и должна защищать в первую очередь.
Это невозможно на 100%.
Но это «невозможно» не значит, что не нужно стараться сделать систему лучше.
Вы сначала говорите про банальный delete from users,
Банальный delete from users — это вырожденный пример, очевидно же, что в реальной жизни должно быть что-то более сложное.
Ошибка и злой умысел как бы две совсем разных вещи.
Да не особо они и разные, кроме того, что второе пишется сознательно, первое само как-то получается. Путь попадания на прод у них одинаков. Один сделал, второй не заметил, третий отдеплоил.
Вон ниже хорошо написано, есть «ошибка, халатность и тупость» — вот как раз от них правильная архитектура и должна защищать в первую очередь.
Правильная архитектура, это примерно как маска от коронавируса. Снизить вероятность может, защитить — нет.
Вы сначала говорите про банальный delete from users, который на тесте вылезет моментально
А это может оказаться ожидаемым поведением для теста. Типа очишать базу перед началом тестирования. Но вот условие проверки дев-прод некорректным может быть или просто слишком сильно привязано к конфигурации прода, которая может внезапно измениться.
Коммит>тесты и тестовое окружение>релиз/билд менеджер>прод.
Причём после коммита программист уже доступа непосредственно к закомиченному коду не имеет.
Странно, что на хабре подобные вещи приходится объяснять.
Странно, что на Хабре приходится объяснять — это не работает на 100%.
То о чем вы пишете — идеальный, но не реальный мир.
На 100% тесты не проверяют всех ситуаций полностью.
Иначе бы ПО давным-давно было бы идеально отлажено и багов не было бы вообще нигде. Уж такие фирмы как MS или Гугль могут себе позволить проводить полный цикл проверок, как бы.
Но баги есть и у них.
Отсутствие доступа к продакшену еще ничего не гарантирует.
Любой программист на проекте сможет в одну-две функции узнать тип стенда (дев-тест-НТ-прод) и далее вызвать какой-нибудь код, когда тип стенда будет равен проду.
Легко проскочит все стенды, единственный момент — могут увидеть на код-ревью.
И да, такой код я лично видел своими глазами, и даже не раз.
И нет, это не было диверсией (хотя один раз были спецэффекты).
Любой программист на проекте сможет в одну-две функции узнать тип стенда (дев-тест-НТ-прод) и далее вызвать какой-нибудь код, когда тип стенда будет равен проду.
Легко проскочит все стенды, единственный момент — могут увидеть на код-ревью.
И да, такой код я лично видел своими глазами, и даже не раз.
И нет, это не было диверсией (хотя один раз были спецэффекты).
Любой программист на проекте сможет в одну-две функции узнать тип стенда (дев-тест-НТ-прод) и далее вызвать какой-нибудь код, когда тип стенда будет равен проду.
Легко проскочит все стенды, единственный момент — могут увидеть на код-ревью.
И да, такой код я лично видел своими глазами, и даже не раз.
И нет, это не было диверсией (хотя один раз были спецэффекты).
Пример, когда не по злому умыслу:
Например, сталкивался, с тем, что тестовый стенд имел не полную БД (а полная БД это сотни гигабайтов, никто на тестовом полную копию продовой БД не держал), поэтому в коде приходилось специально реализовывать обходной манёвр. И однажды этот обходной манёвр забыли убрать…
уж очень хочется услышать этот анекдот
Автор лучший! Очень стимулирующая история, связанная не только с видом деятельности, но и общим стремлением к самореализации! Как же я Вам парни завидую (белой) завистью, что вы имеете такой навык, как создавать! (программировать). Очень жаль что родители в своё время не поспособствовали, а будучи уже личностью социальные и личные нужды не оставили мне шанса познать этот безгранный мир. Уважение Автору и тем кто вкладывает тетанические усилия в образование, которое обеспечит вас шансом стать частью и создателем этого мира (программирования). Цените сотрудников, уважайте руководство:) Не забывайте руководители, что были в рядах сотрудников. А сотрудники, уважайте руководителей (Даже через зубы!), так как хотели бы получить это взамен, при удачно сложившихся для Вас обстоятельств возложивших на Вас груз ответственности руководства. Забрел сюда случайно, уверен без багажа от сюда не уйду. Если что извиняюсь заранее. Всем добра и терпения!!!
В нашей компании все рабочие процессы были выстроены безупречно. Проверки, тесты, ревью. Снова проверки, тесты и ревью. Но даже такая система может дать сбой, и ты должен быть готов, что тебя словно солдата-срочника, поднимут утром по тревоге.
В компании практически полностью отсутствовали процессы обеспечения качества.
Понятное дело, что qa специалиста в компании не было. Но говорить о том, что если есть код ревью! То процесс выстроен безупречно! Смешно!
К 7 утра мы все починили. В 8 часов компания уволила человека, который все это заварил.
Вот это просто насмешило. А этот человек то тут при чем. Если архитектор так криво базу спроектировли.
В целом реклама хороша. Но если смотреть сухо, то подпускать автора к руководству нельзя, он ничего не понимает в разработке. В кодинге да, разработки нет.
Спасибо за комментарий.
qa специалисты на тот момент в компании были.
Человека уволили за то, что он пошел не по процессу, а не за то, что натворил с базой. Мне это тогда так объяснили. На ошибках надо учиться. Лучше на чужих.
Лично я за такое увольнять не стану. Но на тот момент автор (я) был зеленым студентом, который стремился стать разработчиком. К менеджменту меня тогда и не думали подпускать.
qa специалисты на тот момент в компании были.
Человека уволили за то, что он пошел не по процессу, а не за то, что натворил с базой. Мне это тогда так объяснили. На ошибках надо учиться. Лучше на чужих.
Лично я за такое увольнять не стану. Но на тот момент автор (я) был зеленым студентом, который стремился стать разработчиком. К менеджменту меня тогда и не думали подпускать.
qa специалисты на тот момент в компании были.
Сомневаюсь, я не тестировщиков имел ввиду.
Человека уволили за то, что он пошел не по процессу, а не за то, что натворил с базой. Мне это тогда так объяснили. На ошибках надо учиться. Лучше на чужих.
Вот этого в статье нет совсем, где он пошел про процессу, почему он это сделал, кто ему приказал. Это основные вопросы. Акценты расставлены совершенно не там.
Такое впечатление, что текст про фикс базы на продакшене и рекламу курсов на андройде писали два разных человека.
imho увольнять в этой ситуации человека это всё равно что случайно схватившись рукой за раскалённый паяльник, потом отхлестать эту руку за то что доставила боль. работал человек, долго, устраивал, судя по сроку работы — сверхлояльный… единичный фейл, пусть даже большой — уволили, получили дыру в штатном расписании, мороку с поиском ему замены, слили на этот процесс его трёх-четырёхмесячную зарплату… не факт что нашли на те же деньги что платили прежнему… не исключено что уволенный работник пару дней поснимав стресс и подепрессовав воспринял эту ситуацию как долгожданный пинок сменить работу и расти… может так, что парень ещё и в выигрыше в перспективе… хз. как-то истерично и неправильно всё это.
Я сильно извиняюсь. Мой комментарий не совсем относится к посту. Своё чрезвычайно положительное впечатление, к нему я выразил в прошлом сообщении. Но осмелюсь постыдиться и попросить помощи, в поиске правильного направления в обучающей информации любого рода, (статьи, вебинары, видео, теории, пошаговые инструкции и тд.) Которые реально смогут мне помочь в поверхностном представлении (интернет маркетинга, аналитика, создание простейших приложений на android, может кто имеет этот пыльный архив полезного софта и мануалов, первой ступени. Увы уверен, что даже начальный уровень познания о кодинге и программировании без визуальных конструкторов создаст дикий ддос в моей голове. Считаю глупым, сейчас тратить деньги на вебинары и т.п. Потому что по моему мнению, навыки такого рода это как фигурное катание или хоккей. Я свой шанс в понимании о том что тут публикуют, променял в 2000г. на старкрафт и сигареты в подъезде) После 2000г еще 20 лет наблюдал на всё то чем вы занимаетесь как на звёзды, с открытым ртом и восхищением но увы на расстоянии того же удаления. Короче предисловие к тому бреду ранее, еще чуток. Я продажник в строительной сфере. Сейчас в профессиональном кризисе, отсутствия ремиссий на разнообразие. Проработал кучу лет тут, Имею наработанную лично и всеми сотрудниками не малую базу ЦА, выше среднего класса. С стопроцентной платежеспособностью, все относятся к очень обширному для размаха в реализации товаров а тем более услуг. Есть пара тщательно отфильтрованных замыслов к начинанию с большим шансом успеха. Но хотел бы для начала получить хотя бы базовое понимание того с чем придется связаться самому а тем более оставлять без контроля на кого то. Подобных ошибок видел не мало и все они были прискорбно окончены. В ходе детальной трепанации, личностей клиентов, в процессе заключения бумажки. Детально разбирал на винтики каждого. В среднем на каждого уходило пару часов еще и в загородной обстановке. Я веду к тому, что личностное общение не даёт уже не чего. Хотел бы получить более глубокое понимание маркетинга и аналитики. детально, пошагово, принцип интернет аналитики. Может у кого то появится желание, поделиться чем то полезным Что сразу не выдаст яндекс топ. Аналитика — с тем же корнем. Очень бы помогло в структурировании потенциальной задумке. Понимаю, вероятность чтения этого бреда, ровна шансам реализации мною задуманного. Но не теряю надежды на существование альтруистов по отношению к каменоголовым.
Кто еще не понял, мой уровень развития как минимум в контенте этого прекрасного проекта — Питекантроп. Рад что оказался вокруг умных людей, первое впечатление об увиденном схоже с погружением в прорубь. Отрезвляет к собственному самолюбию и не много огорчает, задумываясь… в какую жопу и когда я засунул свою голову и решил что мне больше учиться не надо. Я так расписываю всю глупость, в надежде понимания моего положения и буду благодарен любому полезному отклику а больше отрицательной критики)) Она мне охвата даст побольше)
Кто еще не понял, мой уровень развития как минимум в контенте этого прекрасного проекта — Питекантроп. Рад что оказался вокруг умных людей, первое впечатление об увиденном схоже с погружением в прорубь. Отрезвляет к собственному самолюбию и не много огорчает, задумываясь… в какую жопу и когда я засунул свою голову и решил что мне больше учиться не надо. Я так расписываю всю глупость, в надежде понимания моего положения и буду благодарен любому полезному отклику а больше отрицательной критики)) Она мне охвата даст побольше)
Высушите ваш комментарий от воды. В таком виде дальше 2 строчки вряд ли кто прочтет.
Начните с какой нибудь книжки по программированию. Даже так, сначала погуглите какие языки программирования бывают и выберите тот который вам нравится. А потом книжку по нему посоветую.
придумайте простую задачу — типа приложения калькулятора или списка покупок или дневника, выберите язык( например python, но в целом язык не важен) и сделайте. Прочитайте бесплатный курс по языку в интернете, напишите hello world, разберите примеры. Очень советую для начала освоить или вспомнить школьную программу по информатике хотя бы без программирования, она много вещей разъяснит. В целом learning by doing для начала весьма неплохой путь. Потом все сами поймете)
Бросай — не твое
правильно ли я понял что его уволили не за ошибку, а за пренебрежение принятым порядком тестирования?
и если нет, то если бы Вы были руководителем и должны разработать мероприятия по недопущению аналогичных ситуаций, чтобы вы предложили для снижения человеческого фактора?
и если нет, то если бы Вы были руководителем и должны разработать мероприятия по недопущению аналогичных ситуаций, чтобы вы предложили для снижения человеческого фактора?
ИМХО, есть очень важный момент: люди часто путают три фундаментально отличающиеся вещи (прошу прощения, но мои мой словарный запас не позволил подобрать более удачные понятия, поэтому назову их так): ошибку, халатность и тупость.
Ошибка — это проблема, которую разумными способами предотвратить было невероятно тяжело. Компанию взломали с использованием специально написанного для неё вируса с использованием новейшей уязвимости в операционной системе? Это плохо, но это именно ошибка безопасников и архитекторов. Вы — первая в мире компания, которая использовала эту базу для хранения 100 ТБ данных, а она сломалась именно в проде, хотя ее тестировали на тестовом сервере много раз, но маленькая незаметная строчка все испортила? Да, это ошибка.
Халатность — это осознанное нарушение сотрудником правил, которое привело к проблеме. Сисадмин что-то раскатал без бекапа, так как его лень делать? Это она. Джуниор залил код в репозиторий, а потом сам раскатил его на 150 миллионов пользователей, и система упала? Это именно халатность.
А тупость — это самый спорный термин здесь, это ситуация, когда сотрудник делает то, что на подобной должности не сделает 95% адекватных сотрудников, и это приводит к проблемам. Программист решил поработать с ноутбуком в баре, напился и забыл открытый ноутбук? Ведущий архитектор сделал такую схему бекапов, из которой данные не восстановить, хотя это понятно даже среднему аналитику? Вот это именно тупость.
И ключевой момент в том, что на ошибки, халатность и тупость имеет смысл реагировать разными способами:
- За ошибку действительно почти нет смысла карать, только пытался извлечь из неё как можно больше знаний о том, что можно улучшить.
- За халатность можно и даже нужно карать, так как это осознанное действие сотрудника.
- Тупость — это повод задуматься о том, подходит ли этот сотрудник для этой должности. Нужен ли тупой программист или архитектор? Возможно, что да, но обычно — нет.
Но главный парадокс в том, что именно ошибок бывает довольно мало. Например, я вообще не уверен, что в статье описана именно ошибка. Но людей из-за них почему-то увольняют крайне много, а вот за халатность и тупость почти никого. Ну, это люди сами так говорят, что их за ошибку уволили. Верим, конечно же.
Тут вопрос в другом. Как такой код ушел в продакшн? Ниче не тестировалось? Где QA? Где автотесты какие-нибудь?
Ну в общем как построили работу, так и вышло.
Ну в общем как построили работу, так и вышло.
Где-то читал историю про подобный факап. Виновник пришёл с заявлением «по собственному», на что руководитель ему отказал со словами «твоё обучение обошлось слишком дорого для компании». Но бывают и просто менеджеры.
Эта история лишний раз подтверждает что в айти-индустрии самое худшее звено это ни какие-нибудь тестеры или джуны-разработчики, а менеджмент, менеджмент любого уровня, звевна.
Когда я был совсем начинающим электриком, я протирал пыль и отключил электроснабжение половины огромного нефтехимического комбината. Это стоило мне 600 рублей премии в ценах 2004 года.
Вы пыль на пару с Gengenid протирали?
https://habr.com/ru/company/e-Legion/blog/524330/#comment_22204580
https://habr.com/ru/company/e-Legion/blog/524330/#comment_22204580
Стал бы я увольнять человека за ошибку? “Программа делает то, что ты ей написал”. Но мы же разрабы, мы постоянно ошибаемся.
Проблемой является как выявить первопричину:
Случайность
Злоумышлено
Недоквалификация
В первом случае не увольняют.
Во втором — увольняют плюс иск в суд.
В третьем — переводят на другие работы, попроще (но тут вопрос, захочет ли он на другие деньги).
Ой братан да меня с е-легиона за гораздо меньшее уволили, так что ты там эта, не загадывай)
Эта история лишний раз подтверждает что в айти-индустрии самое худшее звено это ни какие-нибудь тестеры или джуны-разработчики, а менеджмент, менеджмент любого уровня, звевна.
Эта история лишний раз подтверждает что в айти-индустрии самое худшее звено это ни какие-нибудь тестеры или джуны-разработчики, а менеджмент, менеджмент любого уровня, звевна.
Никаких самых худших звёнен никак нельзя определить, не вникая в суть конкретной ситуации.
Вы слишком грандиозные выводы делаете из одного факта. Разработчики тоже не святые.
В данном конкретном случае? Возможно, да, так как вы и написали.
В других случаях страшно косячат разрабы. Я тут уже упоминал, что разорил фирму, просто забыв сделать копию файлов.
Конечно, всегда удобно свою вину списать на менеджмент и пр. Но организовать систему так, чтобы она изолировала разработчика от возможности сделать факап, вообще невозможно. Никак невозможно.
Есть конечно клинические случаи, например, когда сисадмин полгода заваливает руководство заявками на запасные диски, а потом случается выход RAID массива из строя. Да, тут очевидно, руководство не вняло советам спеца, а спец выполнил свою профессиональные обязанности.
Но если в тех же условиях сисадмин ровно сидел на жопе полгода пока RAID ему мигал красной лампочкой, то виноват уже именно сисадмин, а не руководство, которое и слова такого не знает «RAID».
Sign up to leave a comment.
Стоит ли увольнять разраба за большую и дорогую ошибку? Думаю, нет, но менеджмент хотел крови