Вот-вот. Обычно под недоверием к джунам максируется древний и страшный код, в котором даже авторы рискуют что-то сломать при следующей правке. Если в проекте всё прозрачно, то и джуна пускать не страшно.
можно сразу нанять синьора под те задачи, которые есть сейчас
Вы сейчас наглядно демонстрируете образ мышления, из-за которого и происходит перекос в найме во всей индустрии.
Каждая контора считает, что их json'ы достойны перекладывать самые сеньористые сеньоры и ни рангом ниже, а обучает их пусть кто-то другой (Так кто этот другой? Кто, га?)
А затем, как следствие, с боем нанятого джуна, который смог поработать у них пару лет и разобрался во всей их внутренней лапше, называют сеньором. Он через некоторое время увольняется, выходит на рынок и выясняет, что сеньором он был исключительно на своём запущенном легаси, а в современной разработке он по-прежнему понимает мало и собеседование пройти не может.
Вы описываете косяк вашего менеджмента, что довёл вас до такого состояния и не потрудился заблаговременно найти помощника. Но часть вины, скорее всего, есть и на вас. Если вы всё настолько любите делать всё самостоятельно - это ваша проблема, притом психологического характера: нужно учиться делегировать. Без этого навыка вы не сможете далеко продвинуться в карьере и так и будете в любой компании выполнять роль человека-отдела, работу которого ни отмасштабировать, ни распараллелить.
Тут возможна корреляция с тем, где автор работает и сколько там предлагают. Как говорил в универе один из моих преподавателей, по совместительству работавший в бюджете: "умные ко мне не идут".
О, вот и продвижение канала подъехало. Признаюсь, я ожидал ссылку на телеграм, но перед нами блогер более высокого ранга. А статья в провокационном тоне "для энгейджмента", да?
Нет, скорее закон Парето. В ежедневной работе среднестатистического программиста большую часть времени (и строк кода) занимает перекладывание json'ов в том или ином виде. Эти невероятные знания и умения, которых автор не может отыскать у джунов, пригождаются далеко не в каждой задаче.
наша фирма (небольшая) вошла в ассоциацию "РУССОФТ", и теперь участвует в решении с государством
@rezedent12 так и написал, в общем-то. В вашей ассоциации всё равно есть крупный бенефициар, который будет дуть в свою дуду.
Ну плюс это ещё выглядит как картельный сговор с государством с целью "поужать запросы этих зажравшихся айтишников" (тон вашей статьи выдаёт в вас отношение к разработчикам разных уровней, не только джуниорам).
спросил, поднимается ли давление 2 раза в неделю до 140, я ответил да и он мне назначил пожизненные таблетки от давления
И особо не разбирался и не делал никаких анализов.
Звучит так себе, если честно. И даже на холестерин не смотрел или вы всё-таки преувеличиваете? Просто учитывая поставленный вам ВСД, вы это давление можете провоцировать фактом измерения, если у вас уже сформировалась фобия за своё здоровье и условный рефлекс на тонометр: а вдруг страшное покажет.
Ну и также надо понимать, что разработчик задействован обычно где-то на половине от всего жизненного пути коммерческого проекта и видит только маленькую часть его.
Разработчик видит продукт в том виде, в котором он дойдёт до пользователя (либо свою часть продукта), но глубина этого погружения несравнимо выше, чем у менеджеров, которые, в свою очередь "сознательно или нет дистанцируются от ИТ вопросов", так что не вижу проблем.
Так долгие прогулки и плавание - это супер-советы, на самом деле. Можно ещё советовать щадящую гимнастику типа пилатеса (в простонародье ЛФК). Чтобы быть в форме супер-нагрузки и не нужны, нужна регулярность.
Прошу прощения, тон ваших комментариев сильно перекликался с @nuclight, а уж из него так и прёт.
И далеко не все хотят тут работать. Просто потому что привыкли к другому. Не всем по душе все эти требования, этот консерватизм. Видимо, отсюда и упреки - мы тут молодые-креативные, на острие технологий, а вы там заскорузлые старперы, сидящие по уши в древнем легаси.
Не надо, пожалуйста, всех под одну гребёнку грести. Если человек в любой ситуации считает себя Д'Артаньяном, у него на всех вокруг упрёки найдутся. Адекватные специалисты уважают работу друг друга.
Ваша правда. Мне уже постепенно становится стыдно за написанное. С другой стороны, дедушка жаждет общения и тон этого общения задаёт он сам. Может, дедушка об нас развлекается и проводит время, как ему нравится)
RPM - это такой формат пакетов. В крайнем случае число оборотов в минуту.
Ага, а RPS - это Rounds per second, Revolutions per second или, может, Reactor Protective System? Представляете, мы живём в мире, где одинаковые аббревиатуры могут означать разные понятия, в зависимости от предметной области.
Запросы же считают как RPS.
Вы мне сейчас буквально пытаетесь доказать, что если мы в своих метриках всей компанией используем RPM, то мы не правы? Все 5 тысяч человек? Вы серьёзно?
Нет, это не так, и вменяемый технарь должен иметь логику, чтобы это понимать.
Вменяемый технарь должен понимать, что различные технологии предназначены для решения различных задач. В вашей же картине мира есть единственно верный подход - ваш. Странно, что у вас проблемы с оплатой вашего труда. Сможет ли вменяемый технарь найти тут корреляцию, а то может и причинно-следственную связь?
Выборка достаточная, чтоб видеть - у этих людей общий уровень ниже.
Ух, я прям заинтригован. Поделитесь, что ли, величиной своей выборки, что у вас она стремится к нормальному распределению? Тысячи? Миллионы?
например, вспомнить, сколько лет был убыточен Твиттер
Всё тот же вменяемый технарь, если он немного расширит свой кругозор, узнает, что в мире (в том числе РФ) множество компаний, которые на протяжении длительного времени работают себе в убыток. Тем не менее их капитализация, а следовательно и конечная стоимость, каким-то образом растёт. И даже сотрудники не сидят без ЗП. Загадочное явление для нашего технаря, если он не соблаговолит немного погрузиться в экономику.
Оная "данность" не есть нормальное положение вещей.
Ну если у вас нет плана как мы с вами прямо сейчас можем это изменить, то вы занимаетесь банальным брюзжанием. Смысла в таком упражнении для уважающего себя технаря ноль.
Синтаксическим сахаром удобства обертки и ничем более. Потому опирается она на те же самые средства ОС под капотом.
Простите, но другой мой собеседник хотя бы отдаёт себе отчёт, почему он не интересуется той или иной технологией и, соответственно, не стесняется задавать вопросы. Вы же просто Д'Артаньян и всезнайка, смысла с вами дискутировать вообще нет.
Иметь резервный сервер для быстрого переключения в случае проблем с основным и иметь "запасной" сервер который можно подключить если производительности не хватает - это две разные вещи.
Я рад, что всё-таки ошибся и банковская инфраструктура имеет запас прочности в виде дублирования узлов. Хотя мне непонятна концепция держать железо "про запас" - но, возможно это специфика, с которой я не сталкивался.
Go не тот язык, который что-то может дать для решения наших задач.
Ну а зачем тогда вы задаёте вопросы, типа "Сможете гарантировать что сломавшаяся корутина не потащит за собой весь процесс?". Вы уже сформировали свою картину мира и я не собираюсь вас переубеждать. Если вы хотите переубедить меня - у вас тоже не выйдет, увы) Есть умные книжечки, написанные куда более квалифицированными людьми, чем мы с вами. Мы сейчас в комментах не решим ультимативную правду на тему того, чей подход лучше. Вы мне всего лишь доказываете, что намеренно ограничиваете свой кругозор и почему-то считаете, что все должны поступить также. Нет, все так делать не будут) Вы со своим зоопарком разбирайтесь, как вы привыкли, а мы со своим будем работать, как считаем нужным. Просто не надо нас убеждать в том, что раз вы вручную городите инфраструктуру, которую из коробки может предложить современный язык - вы лучше нас. Задротнее, хардкорнее - это да. Эффективнее? Ну в рамках своей роли, с доступными вам инструментами, вы, наверное, эффективны. Значит ли это, что ваш подход применим для всех и вообще является единственно верным? Вряд ли)
Ну начнем с того, я лично не представляю себе "монолит" таких размеров
Вы тут путаете ожидания от реальности с реальностью. В мире, где хардкорные специалисты "просто хорошо пишут код" и не забивают голову такими модными терминами, как сohesion и сoupling (прошу прощения за англицизмы, но перевод этих терминов на русский - отдельная проблема) и прочими архитектурами, очень часто можно встретить настолько связный монолит, что ни одна его часть не сможет работать самостоятельно. Рад, что у вас не так, но это не значит, что везде - как у вас.
Запускать еще один инстанс на том же сервере?
Вы в одном предложении пишете про критический отказ модуля и следом задаёте такой вопрос. Уж где-где, а в банке я бы ожидал дублирования ключевых систем для быстрой замены и перераспределения нагрузки. У вас категорически не может вся инфраструктура работать на ОДНОМ сервере.
Это же и есть одна из версий происхождения слова "сноб"? Каждый день узнаёшь что-то новое)
Все аналогии лживы (автомобиль со временем подвержен износу, а опыт разработчика только растёт).
Давайте рассматривать объективную реальность.
Вот-вот. Обычно под недоверием к джунам максируется древний и страшный код, в котором даже авторы рискуют что-то сломать при следующей правке. Если в проекте всё прозрачно, то и джуна пускать не страшно.
Вы сейчас наглядно демонстрируете образ мышления, из-за которого и происходит перекос в найме во всей индустрии.
Каждая контора считает, что их json'ы достойны перекладывать самые сеньористые сеньоры и ни рангом ниже, а обучает их пусть кто-то другой
(Так кто этот другой? Кто, га?)
А затем, как следствие, с боем нанятого джуна, который смог поработать у них пару лет и разобрался во всей их внутренней лапше, называют сеньором. Он через некоторое время увольняется, выходит на рынок и выясняет, что сеньором он был исключительно на своём запущенном легаси, а в современной разработке он по-прежнему понимает мало и собеседование пройти не может.
Так и живём.
Вы описываете косяк вашего менеджмента, что довёл вас до такого состояния и не потрудился заблаговременно найти помощника.
Но часть вины, скорее всего, есть и на вас. Если вы всё настолько любите делать всё самостоятельно - это ваша проблема, притом психологического характера: нужно учиться делегировать. Без этого навыка вы не сможете далеко продвинуться в карьере и так и будете в любой компании выполнять роль человека-отдела, работу которого ни отмасштабировать, ни распараллелить.
Тут возможна корреляция с тем, где автор работает и сколько там предлагают. Как говорил в универе один из моих преподавателей, по совместительству работавший в бюджете: "умные ко мне не идут".
О, вот и продвижение канала подъехало. Признаюсь, я ожидал ссылку на телеграм, но перед нами блогер более высокого ранга.
А статья в провокационном тоне "для энгейджмента", да?
Нет, скорее закон Парето.
В ежедневной работе среднестатистического программиста большую часть времени (и строк кода) занимает перекладывание json'ов в том или ином виде. Эти невероятные знания и умения, которых автор не может отыскать у джунов, пригождаются далеко не в каждой задаче.
@rezedent12 так и написал, в общем-то. В вашей ассоциации всё равно есть крупный бенефициар, который будет дуть в свою дуду.
Ну плюс это ещё выглядит как картельный сговор с государством с целью "поужать запросы этих зажравшихся айтишников" (тон вашей статьи выдаёт в вас отношение к разработчикам разных уровней, не только джуниорам).
Удивлён, что этот комментарий не первый.
Звучит так себе, если честно. И даже на холестерин не смотрел или вы всё-таки преувеличиваете? Просто учитывая поставленный вам ВСД, вы это давление можете провоцировать фактом измерения, если у вас уже сформировалась фобия за своё здоровье и условный рефлекс на тонометр: а вдруг страшное покажет.
Но означает он по-прежнему: "Мы не знаем, что это такое. Если бы мы знали, что это такое, но мы не знаем, что это такое".
Разработчик видит продукт в том виде, в котором он дойдёт до пользователя (либо свою часть продукта), но глубина этого погружения несравнимо выше, чем у менеджеров, которые, в свою очередь "сознательно или нет дистанцируются от ИТ вопросов", так что не вижу проблем.
Так долгие прогулки и плавание - это супер-советы, на самом деле. Можно ещё советовать щадящую гимнастику типа пилатеса (в простонародье ЛФК).
Чтобы быть в форме супер-нагрузки и не нужны, нужна регулярность.
Прошу прощения, тон ваших комментариев сильно перекликался с @nuclight, а уж из него так и прёт.
Не надо, пожалуйста, всех под одну гребёнку грести. Если человек в любой ситуации считает себя Д'Артаньяном, у него на всех вокруг упрёки найдутся. Адекватные специалисты уважают работу друг друга.
Ваша правда. Мне уже постепенно становится стыдно за написанное. С другой стороны, дедушка жаждет общения и тон этого общения задаёт он сам.
Может, дедушка об нас развлекается и проводит время, как ему нравится)
Ага, а RPS - это Rounds per second, Revolutions per second или, может, Reactor Protective System?
Представляете, мы живём в мире, где одинаковые аббревиатуры могут означать разные понятия, в зависимости от предметной области.
Вы мне сейчас буквально пытаетесь доказать, что если мы в своих метриках всей компанией используем RPM, то мы не правы? Все 5 тысяч человек? Вы серьёзно?
Вменяемый технарь должен понимать, что различные технологии предназначены для решения различных задач. В вашей же картине мира есть единственно верный подход - ваш. Странно, что у вас проблемы с оплатой вашего труда. Сможет ли вменяемый технарь найти тут корреляцию, а то может и причинно-следственную связь?
Ух, я прям заинтригован. Поделитесь, что ли, величиной своей выборки, что у вас она стремится к нормальному распределению? Тысячи? Миллионы?
Всё тот же вменяемый технарь, если он немного расширит свой кругозор, узнает, что в мире (в том числе РФ) множество компаний, которые на протяжении длительного времени работают себе в убыток. Тем не менее их капитализация, а следовательно и конечная стоимость, каким-то образом растёт. И даже сотрудники не сидят без ЗП. Загадочное явление для нашего технаря, если он не соблаговолит немного погрузиться в экономику.
Ну если у вас нет плана как мы с вами прямо сейчас можем это изменить, то вы занимаетесь банальным брюзжанием. Смысла в таком упражнении для уважающего себя технаря ноль.
Закончились аргументы - назови оппонента безграмотным.
Простите, но другой мой собеседник хотя бы отдаёт себе отчёт, почему он не интересуется той или иной технологией и, соответственно, не стесняется задавать вопросы.
Вы же просто Д'Артаньян и всезнайка, смысла с вами дискутировать вообще нет.
Я рад, что всё-таки ошибся и банковская инфраструктура имеет запас прочности в виде дублирования узлов. Хотя мне непонятна концепция держать железо "про запас" - но, возможно это специфика, с которой я не сталкивался.
Ну а зачем тогда вы задаёте вопросы, типа "Сможете гарантировать что сломавшаяся корутина не потащит за собой весь процесс?". Вы уже сформировали свою картину мира и я не собираюсь вас переубеждать. Если вы хотите переубедить меня - у вас тоже не выйдет, увы) Есть умные книжечки, написанные куда более квалифицированными людьми, чем мы с вами. Мы сейчас в комментах не решим ультимативную правду на тему того, чей подход лучше.
Вы мне всего лишь доказываете, что намеренно ограничиваете свой кругозор и почему-то считаете, что все должны поступить также. Нет, все так делать не будут) Вы со своим зоопарком разбирайтесь, как вы привыкли, а мы со своим будем работать, как считаем нужным. Просто не надо нас убеждать в том, что раз вы вручную городите инфраструктуру, которую из коробки может предложить современный язык - вы лучше нас.
Задротнее, хардкорнее - это да. Эффективнее? Ну в рамках своей роли, с доступными вам инструментами, вы, наверное, эффективны. Значит ли это, что ваш подход применим для всех и вообще является единственно верным? Вряд ли)
Вы тут путаете ожидания от реальности с реальностью. В мире, где хардкорные специалисты "просто хорошо пишут код" и не забивают голову такими модными терминами, как сohesion и сoupling (прошу прощения за англицизмы, но перевод этих терминов на русский - отдельная проблема) и прочими архитектурами, очень часто можно встретить настолько связный монолит, что ни одна его часть не сможет работать самостоятельно. Рад, что у вас не так, но это не значит, что везде - как у вас.
Вы в одном предложении пишете про критический отказ модуля и следом задаёте такой вопрос. Уж где-где, а в банке я бы ожидал дублирования ключевых систем для быстрой замены и перераспределения нагрузки. У вас категорически не может вся инфраструктура работать на ОДНОМ сервере.
Почитайте, расширьте кругозор)