Ну прекрасно, инженерия, все дела. Где деньги то инженерам? Почему условия хуже? Это первое. Второе, с такими же этапами ищут и нанимают круд писак, в тот же Тбанк, к примеру. На вопрос, будут ли там алгоритмы так сильно нужны, ответ был отрицательный. Третье, какие бы навыки не были, это всё равно обезьяны, пишущие код. Это линейная должность, там нечем гордиться.
В четверных, задачи уровня литкод изи мидиум - это разве повод для гордости? Я для себя никакого профита от решения литкода не увидел. Дополнительных навыков это никаких не дало.
Оцениваем в человеко-часах, потому как сторипоинты не отвечают прямо на вопрос,когда будет готово. Проблемы всегда возникают изза того, что обьем работ не всегда виден полностью. Зачастую понятно становится только тогда, когда исполнитель полностью пооружается в задачу и часть уже делает. Также часты случаи, когда происходит затык на какой то детали, что то может упорно не хотеть работать и поиск решения занимает дополнительное время. Бывает, аналитика описала в задачах все не так, как есть на самом деле. Много факторов, потому зачастую время хоть и проставлено, но верить ему нельзя. И это при том, что в отрасли достаточно долго, больше десяти лет, точные оценки все равно не даю. Просто оценивать только тогда, когда функционал новый, и уже разрабатывался в подобном виде N раз.
Да пора бы уже начать отказываться от этого цирка. И ладно бы условия были стоящими, так нет, вся отрасль сейчас скатилась на дно в плане заработка, при этом подбор продолжают закручивать и уже не знают как извернуться и какую секцию запехать. Какие то софт скилы, архитектура, которую спрашивать у рядового разраба бессмысленно. Жалко времени на это все, не понимаю, зачем люди туда идут.
Нанимать стажеров - идея не очень. Мало того, сами работать не могут и отнимают время старших, так еще и переделывать за ними надо. Это не помощь, скорее допнагрузка.
В большинстве случаев нужен уровень senior+ вдобавок к управленческому опыту. Я бы не сказал, что хорошо получается, потому как управления процентов 30, остальное - написание кода. Прям чего то серьезного в управленческом плане не было, да и разрабатываю я на уровне mid+, не больше.
Сам сейчас в такой ситуации, управленческая деятельность важна как никогда, но доплачивать за нее не хотят, потому совмещаю с тем же доходом. Работать больше не стал, даже может и меньше, мотивации особой нет. В целом, это негативное явление. Опыт опытом, но продать это по хорошей цене другим скорее всего не получится. Да и вообще, должность лида в разработке - довольно паршивое явление.
Можно, конечно, обновлять, но вас это не спасёт, Spring Boot как был сплошной дырой, так и остался таковым после обновления. К тому же, если человек уже работает в закрытом контуре - через какой то несчастный сервис он не полезет, а будет использовать другие методы, к примеру, напрямую работая с СУБД или чем-нибудь другим. Когда такие вопросы(безопасности) прорабатываются, сервисы в них вообще не фигурируют, по причинам, указанным выше. Они считаются дырой при любых условиях.
По Java - мне при разработке указывали сертифицированную версию OpenJDK, которую я мог использовать. В этом вопросе я вам предельно точно ничего сказать не смогу, не знаю как это работает, и что там можно, что нельзя. Основная мысль только в том, что там ограниченный набор версий и он важен больше с точки зрения соблюдения формальных требований.
Обмены вне СМЭВ не запретили, есть конструкции, которые работают по сей день. Там главный принцип обеспечения безопасности - выдернутые сетевые кабеля, закрытые контура, глушилки, и прочие криптографические фокусы. В остальном - всё современное ПО - сплошное решето, CVE тут не более, чем самообман.
Насчет апгрейдов, не всегда всё одинаково, тот же ангуляр апгрейдят примерно +2 версии за один раз, так наиболее комфортно, иначе бардачный веб через года три превратит ПО в тыкву. Но вот тот же спринг бут обновляется очень редко. Его версию в рамках 2.X поменять легко, перейти с 2го на 3й - уже ощутимо. Вдобавок к этому есть еще сертификация, к примеру сертифицирована только java 11 и postgre определенной версии и всё, никуда вы с них не рыпнетесь, иначе ваша сертификация слетит.
Есть еще момент, когда вы работаете на субподряде и код сервисов вообще не ваш, один раз отработали и передали генподрядчику.
Госсектор, документооборот. Вам грубо говоря разок насыпают на разработку, дальше бюджеты поддержки. Естественно, революций там не будет, будут точечные работы. А особенно, если какая то криптография или межведомственное взаимодействие, там всё очень туго, контракты между подсистемами обновляются очень редко с кучей согласований, бюрократией, испытаниями, сертификацией, где то даже с тематическими исследованиями и контрольными суммами на бинарниках.
Да и по теме доработок, ведь это же не полная переработка. К примеру, если у вас штук 20 сервисов и надо сделать 21й, то первые двадцать получат точечные доработки, и никто там революцию с тотальной миграцией устраивать не будет. Или всё таки будет? Просто если заказчик заплатил только за 21й сервис, то прожирать бюджеты на остальные 20 - сомнительная идея.
По моему опыту, ПО пишется раз, а потом лет десять пятнадцать проводит в эксплуатации без резких движений по миграциям и серьезных переписываний. И только потом, если требуется, проводится тотальная модернизация. В любом случае за такое время подходы и инструменты себя изживают, и их надо полностью менять. Если же писать фреймворки самим, то будущее у них то же самое, при этом будет потрачена куча времени на разработку и выгребание ошибок. А если другим языком, это раздувание бюджета с потерей качества.
Упала бы давно, если бы граждане не выполняли с остервенением абсолютно любой приказ. Но они выполняют и будут выполнять, потому просвета нет и не будет.
Не помню в каком разборе видел, как косвенный признак использовали анализ последовательности розыгрыша дебютов. Если вдруг игрок начинает делать нетипичные для себя ходы в определенных началах, то это хоть небольшой, но повод задуматься. Еще часто анализируют время на ход. Если оно всегда одинаковое, то тут всё очевидно.
Чтобы меньше зевать, нужно тренироваться, а не читить. Это убого, смысла в этом ноль. Весь смысл этой игры в том, чтобы видеть и свои возможности и угрозы со стороны соперника.
В переговорах на текущем месте работы по настоящему работает только заявление на увольнение, в другом случае либо прибавка в три копейки, либо плюс много работы за прибавку в пять копеек. Цель любого бизнеса больше прибыли меньшими затратами, потому не стоит играть в благородство.
Лояльность тут как раз при том, что ее быть не должно. Когда у бизнеса нужда, они поют про семью и общее важное дело. А когда нужды нет, или потребуешь отработанное бабло - то уже не семья, у нас бизнес.
Меня это тоже поражает. Если для прохождения отбора необходимо отдельно готовиться и задания не коррелируют с рабочими процессами, то это шляпа какая то, а не отбор.
У нас много таких спецов. Могут многое, но всё по верхам. Работодатель этим пользуется, не доплачивает, остальным они просто не нужны. Точнее нужны, но на грейд не выше мидла. Вот тебе и T-shape.
Я прошел по такому же сценарию, только вместо Питера была Москва. Иногда езжу в Москву в офис, чисто бумажные дела решить да поболтать вживую, в одну сторону из Твери три с половиной часа получается. Когда жил в Москве, ощущалась именно как вахта. Если туда ехать снова жить, то надо зарабатывать раза в два с половиной больше, но в нашей отрасли такие расценки только среднее звено имеет.
Ну прекрасно, инженерия, все дела. Где деньги то инженерам? Почему условия хуже? Это первое. Второе, с такими же этапами ищут и нанимают круд писак, в тот же Тбанк, к примеру. На вопрос, будут ли там алгоритмы так сильно нужны, ответ был отрицательный. Третье, какие бы навыки не были, это всё равно обезьяны, пишущие код. Это линейная должность, там нечем гордиться.
В четверных, задачи уровня литкод изи мидиум - это разве повод для гордости? Я для себя никакого профита от решения литкода не увидел. Дополнительных навыков это никаких не дало.
Оцениваем в человеко-часах, потому как сторипоинты не отвечают прямо на вопрос,когда будет готово. Проблемы всегда возникают изза того, что обьем работ не всегда виден полностью. Зачастую понятно становится только тогда, когда исполнитель полностью пооружается в задачу и часть уже делает. Также часты случаи, когда происходит затык на какой то детали, что то может упорно не хотеть работать и поиск решения занимает дополнительное время. Бывает, аналитика описала в задачах все не так, как есть на самом деле. Много факторов, потому зачастую время хоть и проставлено, но верить ему нельзя. И это при том, что в отрасли достаточно долго, больше десяти лет, точные оценки все равно не даю. Просто оценивать только тогда, когда функционал новый, и уже разрабатывался в подобном виде N раз.
Да пора бы уже начать отказываться от этого цирка. И ладно бы условия были стоящими, так нет, вся отрасль сейчас скатилась на дно в плане заработка, при этом подбор продолжают закручивать и уже не знают как извернуться и какую секцию запехать. Какие то софт скилы, архитектура, которую спрашивать у рядового разраба бессмысленно. Жалко времени на это все, не понимаю, зачем люди туда идут.
Нанимать стажеров - идея не очень. Мало того, сами работать не могут и отнимают время старших, так еще и переделывать за ними надо. Это не помощь, скорее допнагрузка.
В большинстве случаев нужен уровень senior+ вдобавок к управленческому опыту. Я бы не сказал, что хорошо получается, потому как управления процентов 30, остальное - написание кода. Прям чего то серьезного в управленческом плане не было, да и разрабатываю я на уровне mid+, не больше.
Сам сейчас в такой ситуации, управленческая деятельность важна как никогда, но доплачивать за нее не хотят, потому совмещаю с тем же доходом. Работать больше не стал, даже может и меньше, мотивации особой нет. В целом, это негативное явление. Опыт опытом, но продать это по хорошей цене другим скорее всего не получится. Да и вообще, должность лида в разработке - довольно паршивое явление.
Можно, конечно, обновлять, но вас это не спасёт, Spring Boot как был сплошной дырой, так и остался таковым после обновления. К тому же, если человек уже работает в закрытом контуре - через какой то несчастный сервис он не полезет, а будет использовать другие методы, к примеру, напрямую работая с СУБД или чем-нибудь другим. Когда такие вопросы(безопасности) прорабатываются, сервисы в них вообще не фигурируют, по причинам, указанным выше. Они считаются дырой при любых условиях.
По Java - мне при разработке указывали сертифицированную версию OpenJDK, которую я мог использовать. В этом вопросе я вам предельно точно ничего сказать не смогу, не знаю как это работает, и что там можно, что нельзя. Основная мысль только в том, что там ограниченный набор версий и он важен больше с точки зрения соблюдения формальных требований.
Обмены вне СМЭВ не запретили, есть конструкции, которые работают по сей день. Там главный принцип обеспечения безопасности - выдернутые сетевые кабеля, закрытые контура, глушилки, и прочие криптографические фокусы. В остальном - всё современное ПО - сплошное решето, CVE тут не более, чем самообман.
Насчет апгрейдов, не всегда всё одинаково, тот же ангуляр апгрейдят примерно +2 версии за один раз, так наиболее комфортно, иначе бардачный веб через года три превратит ПО в тыкву. Но вот тот же спринг бут обновляется очень редко. Его версию в рамках 2.X поменять легко, перейти с 2го на 3й - уже ощутимо. Вдобавок к этому есть еще сертификация, к примеру сертифицирована только java 11 и postgre определенной версии и всё, никуда вы с них не рыпнетесь, иначе ваша сертификация слетит.
Есть еще момент, когда вы работаете на субподряде и код сервисов вообще не ваш, один раз отработали и передали генподрядчику.
Госсектор, документооборот. Вам грубо говоря разок насыпают на разработку, дальше бюджеты поддержки. Естественно, революций там не будет, будут точечные работы. А особенно, если какая то криптография или межведомственное взаимодействие, там всё очень туго, контракты между подсистемами обновляются очень редко с кучей согласований, бюрократией, испытаниями, сертификацией, где то даже с тематическими исследованиями и контрольными суммами на бинарниках.
Да и по теме доработок, ведь это же не полная переработка. К примеру, если у вас штук 20 сервисов и надо сделать 21й, то первые двадцать получат точечные доработки, и никто там революцию с тотальной миграцией устраивать не будет. Или всё таки будет? Просто если заказчик заплатил только за 21й сервис, то прожирать бюджеты на остальные 20 - сомнительная идея.
По моему опыту, ПО пишется раз, а потом лет десять пятнадцать проводит в эксплуатации без резких движений по миграциям и серьезных переписываний. И только потом, если требуется, проводится тотальная модернизация. В любом случае за такое время подходы и инструменты себя изживают, и их надо полностью менять. Если же писать фреймворки самим, то будущее у них то же самое, при этом будет потрачена куча времени на разработку и выгребание ошибок. А если другим языком, это раздувание бюджета с потерей качества.
Упала бы давно, если бы граждане не выполняли с остервенением абсолютно любой приказ. Но они выполняют и будут выполнять, потому просвета нет и не будет.
Не помню в каком разборе видел, как косвенный признак использовали анализ последовательности розыгрыша дебютов. Если вдруг игрок начинает делать нетипичные для себя ходы в определенных началах, то это хоть небольшой, но повод задуматься. Еще часто анализируют время на ход. Если оно всегда одинаковое, то тут всё очевидно.
Оно бы хорошо, если бы использовалось в играх против компьютера. Так нет же, автор играет 10 минутные игры и хочет использовать свою разработку там.
Чтобы меньше зевать, нужно тренироваться, а не читить. Это убого, смысла в этом ноль. Весь смысл этой игры в том, чтобы видеть и свои возможности и угрозы со стороны соперника.
В переговорах на текущем месте работы по настоящему работает только заявление на увольнение, в другом случае либо прибавка в три копейки, либо плюс много работы за прибавку в пять копеек. Цель любого бизнеса больше прибыли меньшими затратами, потому не стоит играть в благородство.
Лояльность тут как раз при том, что ее быть не должно. Когда у бизнеса нужда, они поют про семью и общее важное дело. А когда нужды нет, или потребуешь отработанное бабло - то уже не семья, у нас бизнес.
Меня это тоже поражает. Если для прохождения отбора необходимо отдельно готовиться и задания не коррелируют с рабочими процессами, то это шляпа какая то, а не отбор.
У нас много таких спецов. Могут многое, но всё по верхам. Работодатель этим пользуется, не доплачивает, остальным они просто не нужны. Точнее нужны, но на грейд не выше мидла. Вот тебе и T-shape.
Я, чтобы не донимать домашних созвонами, думал вообще снимать офис или в коворкинг свалить, но коворкинги, как я понимаю, все в Твери померли.
Я прошел по такому же сценарию, только вместо Питера была Москва. Иногда езжу в Москву в офис, чисто бумажные дела решить да поболтать вживую, в одну сторону из Твери три с половиной часа получается. Когда жил в Москве, ощущалась именно как вахта. Если туда ехать снова жить, то надо зарабатывать раза в два с половиной больше, но в нашей отрасли такие расценки только среднее звено имеет.