Мне бы тоже хотелось видеть конкретные примеры, чем они занимаются. Хотя фокус статьи на другом, поэтому не вижу смысла критиковать автора, она рассказала про свой кусочек работы.
полезные изменения многим были интересны, некоторым безразлично, но чтобы противиться — то только на задачи типа "дичь".
"Дичь" это субъективная оценка. Во многом она зависит от прошлого опыта и текущих скиллов. Люди совершенно разные. Кто-то понимает и готов с радостью подхватывать изменения, другие наоборот - не понимают, или не видят для себя лично пользы, или видят угрозу и тормозят. Со всем этим приходится работать.
Через сопутствующее мобильное приложение, с кучей разных полезных функций. Например функция помощи при аварии с поиском ближайшего автосервиса предлагает заранее ввести свои данные, такие как ФИО, SSN, Driver license и т.п.
Если у команды есть реальных 25% времени чтобы внедрить хорошую технологию «с понятной ценностью» то никто не будет бодаться, а с радостью за это возьмутся.
Здесь как с уборкой - в теории всем нравится когда удобно и красиво как в пятизвёздочном отеле, но в реальности менять своих привычки бросать носки куда попало и разгребать авгиевы конюшни за другими ни кто не стремится.
У меня по опыту внедрение новых технологий и полезных инженерных практик, по большому счету это всегда боль. Причем менеджмент с их сроками и бюджетами здесь полбеды. Много отрицания идёт от самих же инженеров - людям удобнее и кажется безопаснее работать так, как они привыкли.
Для того, чтобы изменить что-то технически, сперва приходится менять самих людей: либо учить и воспитывать пока новые подходы не войдут в привычку, либо в прямом смысле. Банальный пример - кодстайл. На одном из проектов внедрение заняло больше года, т.к. взрослые дядьки на серьезных щщах ни как не могли договориться относительно отступов: табы или пробелы.
"Жандарм – это порядок, а порядок никто не любит". В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар. Кроме того, как у любых руководителей, многое определяется сугубо личными качествами и опытом.
А эта работа связана с реальными стрессовыми ситуациями? Как скорая и или пожарная? Или вы просто просираете сроки из-за плохого менеджмента
Современное айти это командная работа. Командная работа это работа с людьми, а людям свойственно проявлять эмоции. Позитивные, негативые - разные. Умение их контролировать это тоже навык.
Источником раздражения не обязательно будет начальство. Много стресса доставляют новички у которых просто нет ещё таких навыков. Эпизодически коллеги вашего же уровня. Дальше - люди со стороны, заказчики, подрядчики или допустим пользователи вашего продукта.
Стрессовой ситуация может стать и по личным причинам - плохое настроение, кто-то наступил на ногу в метро, проблемы с близкими, политика, погода, усталость. Некоторые болезненно относятся к критике, пусть даже самой конструктивной. Некоторые видят негатив даже в самых нейтральных вещах, как вопрос о стрессоустойчивости.
Если у человек не умеет выключаться из своих эмоций это может протекать в работу и сказываться на результатах. Поэтому вопрос в принципе уместный. Просто не факт, что для получения ответа его нужно задавать вот так в лоб.
Рискую высказать непопулярную точку зрения. Шум вокруг ФП стоит последние лет 40. Какие-то отдельные элементы вошли в массовую культуру, но в целом парадигма так и не стала мейнстримом. Императивный код в итоге проще писать, поддерживать, отлаживать по шагам и расширять.
Все зависит от требований. Если компания готова вкладываться, почему нет. Но в целом документации у тех же w3c уже давно понаписано на второе высшее образование (вы когда последний раз пересматривали?). Пройти какую-то базовую сертификацию в популярных клаудах (AWS, GCP, Azure) займет пару месяцев на каждый. Научиться эффективно использовать, обходя разные специфичные грабли - ещё больше. ITIL - у этих вообще планы расписаны на годы с обязательной наработкой профильного опыта в промежутке между экзаменами. ISO/IEC, если до этого не сталкивались с отраслевыми стандартами (безопасной разработки, например), можно читать хоть всю жизнь.
с опым работы в 20 лет. Ну смешно даже
У меня айтишный стаж немного больше, но это не мешает относиться к этим цифрам, так скажем, с юмором. Причем чем больше, тем веселее. То что перед глазами - разработка двадцать лет тому назад и сейчас это довольно разные вещи. Если вы этого не заметили, значит вероятно работаете в какой-то специфичной нише.
Зазубрить арифметику и понимать ее это немного разные вещи. Теорию чисел, абелевы группы и все вот это.
Зачем нужны классы это вопрос теоретический, и в некотором роде даже философский. Их реализация в разных языках программирования является по сути компромиссом для целой пачки научных и практических проблем. Поэтому она везде довольно разная. Нужно-ли такое понимание рядовому сотруднику на зарплате, задачи которого ограничены условным перекладыванием джейсонов вопрос дискуссионный. Но для хабра мне кажется вполне уместным.
На самом деле дефицит подходящих айтишников. Здесь это вопрос денег и больших чисел. Обучать людей на месте методом их проб и ошибок это очень дорого. Условная задача, которая решается специалистом в теме за считанные часы, у падавана может растянуться на месяцы (на практике был не один такой кейс). Конкуренция среди инженеров на международном рынке конкретно сейчас очень высока - после всех этих релокаций рабсилы из стран некогда развитого социализма, готовых теперь работать тут чуть ли не за еду, а так же массовых увольнений из айти гигантов. Конечно, каждый считает себя самым-самым, но лучше взять того у которого X, Y и Z на самом деле сходятся, или продолжать поиски, чем взять не того и мучаться с ним все следующие годы.
Я бы рекомендовал не относится к отказам как личному поражению или результату недооценки прошлых заслуг. У интервьюера вообще нет такой задачи как оценка ваших прошлых достижений. Ему нужно найти подходящего работника. Понятно, что требования у всех разные. Но он имеет точно такое же право считать вас неподходящим как и вы их предложение.
Хороший вы специалист или нет это оценочное суждение, справедливость которого зависит от контекста. Мы довольно сильно привязываемся к среде, где достаточно долго живём - как команда Летучего Голландца вростая в борта компаний, стран, коллег и т.п. Будучи незаменимым и почитаемым персонажем в одном месте, нужно быть готовым к тому, что на вас будут смотреть как на чудовище в другом. Это вовсе не потому, что процессы найма плохие или кто-то не прав - просто вы разные.
Backend-разработчик должен был отстоять свое мнение, привести аргументы. А еще лучше — совместно с командой сформировать плюсы и минусы двух решений, возможные риски
Это похоже на finger pointing, что не конструктивно.
Во-первых, авария это штука вероятностная, и поэтому она неизбежна. Ключевых вопросов три: как снизить риски ее возникновения, как минимизировать последствия если когда они сработают и где взять на это деньги как не продолбать впустую полученный опыт. Команда, у которой ещё не было нормальных аварий, это ньюбы.
Во-вторых, в любой нетривиальной системе у аварии не бывает какой-то одной причины, это всегда стечение разных обстоятельств. Конечно, есть соблазн тыкнуть пальцем в крайнего кто был ближе к рубильнику и на этом остановиться. Но такой подход не вскроет корней и в следующий раз опять все повторится. Сотрудники же вместо решения проблем начинают от них дистанцироваться - если крайний найден, то остальные могут расслабиться или творить ещё какие-нибудь дичь. То факт, что менеджмент продолжал дрючить разработку во время праздников, когда ситуация с обновлением была уже определена, тому хороший пример.
Вы вот сейчас сказали, что это действия РКН со своим антифродом привели к существенному увеличению количества таких звонков, а на самом деле ситуация выглядит совсем не так?)
Меня удивляет масштаб. Я бы понял, будь это десятки, ну сотни звонков в день. Но почти два мульта. Причем изо дня в день продолжают звонить когда их уже банят. Мошенники сидят на тарифах по цене воздуха что-ли (а можно и мне такой)?
В гипотетический истории с ботами сложно сделать балансировку, когда живых операторов заведомо меньше. В колцентрах это "оставайтесь на линии, вы 100500-й в очереди". А тут получается рвётся весь скрип, если не кому вовремя подключиться. Ну и добиться от бота естественности диалога это та ещё задача.
Вообще цифры интересные. Например, 263,3 млн это почти в два раза больше, чем жителей во всей РФ. В среднем получается блокируют 1.7 млн звонков в день.
Интересно, сколько тогда людей задействовано в мошенническом бизнесе, если они способны генерировать такой трафик и каковы у них расходы на инфраструктуру?
Или с подменных номеров звонит кто-то ещё кроме них (любопытно кто это такие и каково их процентное соотношение по сравнению с мошенниками)?
Навняка у РКН должна быть статистика и по уникальным номерам, звонки на которые были заблокированы. Вполне может быть фактором, чтобы как-то защитить людей (например не выдавать кредиты при первом обращении). Любопытно, есть ли движение в этом направлении?
Увы или к счастью, pypi теперь рекомендуют hatch. А poetry по-моему с самого начала выглядит как PoC Франкенштейна - ребята замахнулись сделать многое, но не вывезли ни чего сделать нормально и до конца.
Poetry был попыткой косплеить npm, предоставив разработчикам новый комбайн, вместо кучи лопат. Но мне кажется, что питон пошел пополз каким-то другим путём и у нас теперь, вместо одного понятного решения, есть конструктор для комбайнов https://packaging.python.org/en/latest/key_projects/ .
Проблема в том, что на практике найти такого первого ещё тот квест и приходится делать работу вторыми. Т.е. в практической плоскости вопрос ставится не что лучше эксперт или не эксперт, а как получить результат имея (как минимум на старте) людей с существенным недостатком экспертизы.
Мне кажется вы оба правы. Люди слишком нелинейны, чтобы их можно было абстрагировать исключительно до объекта воздействия (пресловутый человеческий фактор), и ненавистный многим здесь people management является тоже важной частью в любой организации.
Память у людей в среднем работает примерно одинаково. Руководителю приходится знать шире, а специалистам - глубже. Кто из них знает больше вопрос я думаю дискуссионный.
Мне бы тоже хотелось видеть конкретные примеры, чем они занимаются. Хотя фокус статьи на другом, поэтому не вижу смысла критиковать автора, она рассказала про свой кусочек работы.
"Дичь" это субъективная оценка. Во многом она зависит от прошлого опыта и текущих скиллов. Люди совершенно разные. Кто-то понимает и готов с радостью подхватывать изменения, другие наоборот - не понимают, или не видят для себя лично пользы, или видят угрозу и тормозят. Со всем этим приходится работать.
Через сопутствующее мобильное приложение, с кучей разных полезных функций. Например функция помощи при аварии с поиском ближайшего автосервиса предлагает заранее ввести свои данные, такие как ФИО, SSN, Driver license и т.п.
Здесь как с уборкой - в теории всем нравится когда удобно и красиво как в пятизвёздочном отеле, но в реальности менять своих привычки бросать носки куда попало и разгребать авгиевы конюшни за другими ни кто не стремится.
У меня по опыту внедрение новых технологий и полезных инженерных практик, по большому счету это всегда боль. Причем менеджмент с их сроками и бюджетами здесь полбеды. Много отрицания идёт от самих же инженеров - людям удобнее и кажется безопаснее работать так, как они привыкли.
Для того, чтобы изменить что-то технически, сперва приходится менять самих людей: либо учить и воспитывать пока новые подходы не войдут в привычку, либо в прямом смысле. Банальный пример - кодстайл. На одном из проектов внедрение заняло больше года, т.к. взрослые дядьки на серьезных щщах ни как не могли договориться относительно отступов: табы или пробелы.
"Жандарм – это порядок, а порядок никто не любит". В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар. Кроме того, как у любых руководителей, многое определяется сугубо личными качествами и опытом.
Современное айти это командная работа. Командная работа это работа с людьми, а людям свойственно проявлять эмоции. Позитивные, негативые - разные. Умение их контролировать это тоже навык.
Источником раздражения не обязательно будет начальство. Много стресса доставляют новички у которых просто нет ещё таких навыков. Эпизодически коллеги вашего же уровня. Дальше - люди со стороны, заказчики, подрядчики или допустим пользователи вашего продукта.
Стрессовой ситуация может стать и по личным причинам - плохое настроение, кто-то наступил на ногу в метро, проблемы с близкими, политика, погода, усталость. Некоторые болезненно относятся к критике, пусть даже самой конструктивной. Некоторые видят негатив даже в самых нейтральных вещах, как вопрос о стрессоустойчивости.
Если у человек не умеет выключаться из своих эмоций это может протекать в работу и сказываться на результатах. Поэтому вопрос в принципе уместный. Просто не факт, что для получения ответа его нужно задавать вот так в лоб.
Рискую высказать непопулярную точку зрения. Шум вокруг ФП стоит последние лет 40. Какие-то отдельные элементы вошли в массовую культуру, но в целом парадигма так и не стала мейнстримом. Императивный код в итоге проще писать, поддерживать, отлаживать по шагам и расширять.
Но если фиктивный синьер не сможет по каким-либо причинам с вами сработаться, то стоит-ли его винить в том, что он вас не взял?
Все зависит от требований. Если компания готова вкладываться, почему нет. Но в целом документации у тех же w3c уже давно понаписано на второе высшее образование (вы когда последний раз пересматривали?). Пройти какую-то базовую сертификацию в популярных клаудах (AWS, GCP, Azure) займет пару месяцев на каждый. Научиться эффективно использовать, обходя разные специфичные грабли - ещё больше. ITIL - у этих вообще планы расписаны на годы с обязательной наработкой профильного опыта в промежутке между экзаменами. ISO/IEC, если до этого не сталкивались с отраслевыми стандартами (безопасной разработки, например), можно читать хоть всю жизнь.
У меня айтишный стаж немного больше, но это не мешает относиться к этим цифрам, так скажем, с юмором. Причем чем больше, тем веселее. То что перед глазами - разработка двадцать лет тому назад и сейчас это довольно разные вещи. Если вы этого не заметили, значит вероятно работаете в какой-то специфичной нише.
Зазубрить арифметику и понимать ее это немного разные вещи. Теорию чисел, абелевы группы и все вот это.
Зачем нужны классы это вопрос теоретический, и в некотором роде даже философский. Их реализация в разных языках программирования является по сути компромиссом для целой пачки научных и практических проблем. Поэтому она везде довольно разная. Нужно-ли такое понимание рядовому сотруднику на зарплате, задачи которого ограничены условным перекладыванием джейсонов вопрос дискуссионный. Но для хабра мне кажется вполне уместным.
На самом деле дефицит подходящих айтишников. Здесь это вопрос денег и больших чисел. Обучать людей на месте методом их проб и ошибок это очень дорого. Условная задача, которая решается специалистом в теме за считанные часы, у падавана может растянуться на месяцы (на практике был не один такой кейс). Конкуренция среди инженеров на международном рынке конкретно сейчас очень высока - после всех этих релокаций рабсилы из стран некогда развитого социализма, готовых теперь работать тут чуть ли не за еду, а так же массовых увольнений из айти гигантов. Конечно, каждый считает себя самым-самым, но лучше взять того у которого X, Y и Z на самом деле сходятся, или продолжать поиски, чем взять не того и мучаться с ним все следующие годы.
Я бы рекомендовал не относится к отказам как личному поражению или результату недооценки прошлых заслуг. У интервьюера вообще нет такой задачи как оценка ваших прошлых достижений. Ему нужно найти подходящего работника. Понятно, что требования у всех разные. Но он имеет точно такое же право считать вас неподходящим как и вы их предложение.
Хороший вы специалист или нет это оценочное суждение, справедливость которого зависит от контекста. Мы довольно сильно привязываемся к среде, где достаточно долго живём - как команда Летучего Голландца вростая в борта компаний, стран, коллег и т.п. Будучи незаменимым и почитаемым персонажем в одном месте, нужно быть готовым к тому, что на вас будут смотреть как на чудовище в другом. Это вовсе не потому, что процессы найма плохие или кто-то не прав - просто вы разные.
Это похоже на finger pointing, что не конструктивно.
Во-первых, авария это штука вероятностная, и поэтому она неизбежна. Ключевых вопросов три: как снизить риски ее возникновения, как минимизировать последствия
есликогда они сработают игде взять на это деньгикак не продолбать впустую полученный опыт. Команда, у которой ещё не было нормальных аварий, это ньюбы.Во-вторых, в любой нетривиальной системе у аварии не бывает какой-то одной причины, это всегда стечение разных обстоятельств. Конечно, есть соблазн тыкнуть пальцем в крайнего кто был ближе к рубильнику и на этом остановиться. Но такой подход не вскроет корней и в следующий раз опять все повторится. Сотрудники же вместо решения проблем начинают от них дистанцироваться - если крайний найден, то остальные могут расслабиться или творить ещё какие-нибудь дичь. То факт, что менеджмент продолжал дрючить разработку во время праздников, когда ситуация с обновлением была уже определена, тому хороший пример.
Вы вот сейчас сказали, что это действия РКН со своим антифродом привели к существенному увеличению количества таких звонков, а на самом деле ситуация выглядит совсем не так?)
Меня удивляет масштаб. Я бы понял, будь это десятки, ну сотни звонков в день. Но почти два мульта. Причем изо дня в день продолжают звонить когда их уже банят. Мошенники сидят на тарифах по цене воздуха что-ли (а можно и мне такой)?
В гипотетический истории с ботами сложно сделать балансировку, когда живых операторов заведомо меньше. В колцентрах это "оставайтесь на линии, вы 100500-й в очереди". А тут получается рвётся весь скрип, если не кому вовремя подключиться. Ну и добиться от бота естественности диалога это та ещё задача.
Вообще цифры интересные. Например, 263,3 млн это почти в два раза больше, чем жителей во всей РФ. В среднем получается блокируют 1.7 млн звонков в день.
Интересно, сколько тогда людей задействовано в мошенническом бизнесе, если они способны генерировать такой трафик и каковы у них расходы на инфраструктуру?
Или с подменных номеров звонит кто-то ещё кроме них (любопытно кто это такие и каково их процентное соотношение по сравнению с мошенниками)?
Навняка у РКН должна быть статистика и по уникальным номерам, звонки на которые были заблокированы. Вполне может быть фактором, чтобы как-то защитить людей (например не выдавать кредиты при первом обращении). Любопытно, есть ли движение в этом направлении?
Увы или к счастью, pypi теперь рекомендуют hatch. А poetry по-моему с самого начала выглядит как PoC Франкенштейна - ребята замахнулись сделать многое, но не вывезли ни чего сделать нормально и до конца.
Poetry был попыткой косплеить npm, предоставив разработчикам новый комбайн, вместо кучи лопат. Но мне кажется, что питон
пошелпополз каким-то другим путём и у нас теперь, вместо одного понятного решения, есть конструктор для комбайнов https://packaging.python.org/en/latest/key_projects/ .Проблема в том, что на практике найти такого первого ещё тот квест и приходится делать работу вторыми. Т.е. в практической плоскости вопрос ставится не что лучше эксперт или не эксперт, а как получить результат имея (как минимум на старте) людей с существенным недостатком экспертизы.
Мне кажется вы оба правы. Люди слишком нелинейны, чтобы их можно было абстрагировать исключительно до объекта воздействия (пресловутый человеческий фактор), и ненавистный многим здесь people management является тоже важной частью в любой организации.
Память у людей в среднем работает примерно одинаково. Руководителю приходится знать шире, а специалистам - глубже. Кто из них знает больше вопрос я думаю дискуссионный.
Может это был способ вытащить граждан из своих информационных пузырей?)