Ректальное программирование как метод не должно ограничиваться технологиями 1С. Обращаюсь к сообществу с просьбой проекции и миграции передового опыта на другие технологии.
Лояльность и доверие в отношениях между боссом и подчиненным стоят, к сожалению, на первом месте по сравнению с навыками и профессионализмом ("Лестница в небо", Хазин, Щеглов). ИТ-шники, пробивающие себе дорогу учебой и трудом, к сожалению, имеют меньше шансов на повышение по сравнению с теми, кто профессионально лижет зад начальнику. Об этих софт скиллс идет речь? Разработка ИТ систем - это зачастую борьба с собственными слабостями и окружающими бесами. И да, никому не понравится сотрудник, который старается улучшить процессы и системы, критикует дерьмовые решения, доставляя тем самым дискомфорт руководству и подлецам в его окружении
gRPC — ok, но что за политика такая, когда старые технологии просто забрасываются и дальше поступай как знаешь. Многие системы физически невозможно ни переписать из-за их размера, ни переехать на другую технологию.
The .NET Portability Analyzer — неплохо, лучше чем ничего. Но как конвертировать проект в 270 сборок? Никаких шансов из-за взаимных зависимостей
То что я описал меня сначала тоже удивляло. Но в больших фирмах в РФ все так или почти так. Предположим есть некая система и ее надо слегка доработать. На разработку уйдет 6 ч одного программиста. При стоимости часа пускай даже 1000 р фирма ничего не заработает. А теперь представьте, что компания собирает команду из 2 разработчиков, тестировщика, аналитика, архитектора, менеджера проектов, владельца продукта. Эти 7 человек получают, предположим, по 100000/мес плюс соц выплаты, а проект берется на сопровождение на 1 год, плюс маржа. Контракт получается на 20 лямов минимум. Вот так можно вести бизнес, а мы тут сайтики за 50$ на вордпрессе делаем. Мы живем в таком месте и в такое время, что маленькая цена неинтересна не только исполнителю, но и заказчику, особенно если он государственный
То что Вы назвали Senior я встречал в виде Team leader. Но тимлид не тащит проект. В крайнем случае с ним советуется архитектор и аналитик. На проекте формируется команда (Product owner, PM, архитектор, аналитик, программисты, тимлид, тестировщики). В итоге, каждый разработчик получает конкретный тикет и пилит его в соответствии с Description, который отражает фрагмент ТЗ. Разработчик может быть на разных проектах одновременно.
В небольших компаниях ничего такого нет и да, каждому программисту дают в разработку существующую или новую систему. Иногда нет никакого деления на тимлидов, сеньоров и джунов, а в трудовую разрешают записать любую формулировку, например «Старший инженер-программист». Но это, конечно, уходит в прошлое, сейчас кругом сплошной Agile/Scrum
Наткнулся на статью «Собеседование в Додо Пиццу», там много поводов для спора, но сама идея тестового дня мне нравится. Это еще один прекрасный способ выяснить уровень кандидата, не прибегая к тестам. Наверное самый эффективный, причем он намного лучше проверки на испытательном сроке, пускай даже очень коротком. Кроме того, это честно по отношению к кандидату тоже, поскольку тестируют тебя как в Гугл, а работать в итоге приходится с очень кастомным и махровым легаси. Только я считаю, что тестовый день должен оплачиваться.
Кстати я проходил тестовый день, точнее это была тестовая ночь — компания работает по американскому времени в Москве. ЗП предлагали сильно выше чем у сеньора по рынку, (ЗП была просто конская). В этот тестовый рабочий день я пофиксил баг в незнакомой мне системе, мои шансы стали очень высоки, но на следующий день я отказался. 1) Компания не софтверная, два разработчика пилят CRM-ку для себя. 2) Работать с 18:00 до 3:00 (1 час на бед) оказалось нереально сложно. Даже адаптировавшись я не смог бы нормально общаться с семьей, поскольку днем я бы отсыпался, да и в выходные дни был бы вынужден жить по такому же распорядку. 3) Бэкенд на Node.js и взаимодействие с БД представляет собою спагетти-код от земли до неба и глядя на все это, и вспоминая .net, EF, Linq, я понял, что это будет не работа а мучение.
Почему сразу увольняли? Например, меня, за более чем 20 лет карьеры увольняли всего 1 раз по надуманной причине и не смогли уволить. В итоге я ушел сам через 3 месяца, причем получил грамоту от Минкомсвязи. Я меняю сместо работы довольно часто, в среднем раз в 1.5 года. Но это становится нормой в ИТ сфере, поскольку длительность всовременного стартапа (взлетная полоса) варьируется в интервале 6 мес — 1.5 года. Зайдите на Upwork и посмотрите какова длительность проектов. И long term позиции там не в большинстве.
адепт развития в стиле resume driven development
Именно! Попробуйте сегодня устроиться без резюме. От качества резюме зависят ваши шансы. Существует целая наука о том как составлять резюме. Каждый разработчик заботится о собственном резюме. Понятно, что за резюме должно быть что-то реальное.
Вы ему будете нужны только для того, чтобы набить свое резюме
Разработчик заинтересован в том, чтобы в резюме красовались знаменитые бренды, в этом нет ничего странного. Это как в универе, первые три сессии ты работаешь на зачетку, остальные сессии зачетка работает на тебя.
у человека до фига свободного времени
далее идет очень странный вывод, комментировать его не могу, но что касается времени, то его действительно много, только большинство тратит его не на карьеру. Попробуйте отказаться от компьютерных игр, сериалов и тиктока и Вы заметите, что сможете делать по одному тестовому заданию в день
Если бы разработка сводилась к такой вот сборке, этот процесс давно бы уже автоматизировали, сравнение со шкафом неудачное
это каноническое определение велосипедного кода
Но с точки зрения программиста это все равно творчества, поскольку он не знает о другой реализации. Да и абсолютно одинаковых велосипедов Вы не встретите, если это не копипаст, согласитесь?
Да. В этом контексте «качественно новые» обозначают несуществующие на данный момент, обладающие новыми качествами. Код, обладающий теми же самыми качествами не создается повторно и собирается в библиотеки классов. Говоря о схеме, она не может быть бесконечно детализированной, поскольку если это так, она даже может стать кодом. Поэтому небольшая свобода выбора у разработчика всегда есть
Творчество — процесс деятельности, создающий качественно новые материалы и духовные ценности или итог создания объективно нового. Основной критерий, отличающий творчество от изготовления (производства), — уникальность его результата.
Труд программиста, в основном, уникален, поскольку повторяющиеся фрагменты кода складываются в библиотеки классов. С учетом определения творчества, труд программиста творческий, т.к. он создает, то есть творит и всегда что-то новое. Можно возразить, дескать у многих программистов нет свободы выбора — это не так, свобода выбора способа решения задачи, даже минимальная, всегда сохраняется.
но я ничего не слышал про существование компаний, в которых их не бывает
Все правильно, в хороших компаниях это происходит редко, тут Вы мне не противоречите. Но я хотел бы добавить, что не в каждой компании баги на проде превращаются в непрерывную истерику менеджмента.
если вы ей сильно увлечётесь, она вашу компанию и похоронит
Смотря что Вы понимаете под корпоративной культурой. Корпоративная культура некоторых сообществ позволяла им выжывать в самых экстремальных ситуациях на протяжении столетий и в итоге влиять на судьбы мира, все зависит от сути и качества этой самой корпоративной культуры.
Программирование — это творческая профессия. Если разрабатывать код (фиксить баг) в условиях, когда все вокруг вас сходят с ума и хватают вас за грудки, ничего хорошего из этого не выйдет. И нечего делать в такой компании.
Разве ошибки в проде не являются чем-то ненормальным и нестандартным, редким? Или в Вашей компании это норма и происходит постоянно? Если норма, то новичку нечего там делать. Скорее всего у вас бардак, невыстроенные процессы, нехватка ресурсов, нет код ревью и тестов, посредственный уровень разработчиков, обусловленный невозможностью нанять хороших или даже блатом и кумовством.
Корпоративная культура — единственная причина, по которой компания будет существовать, это как билет в будущее, многие этого не понимают.
Собеседование и решение тестов нельзя сравнивать с багфиксом. Я много лет фиксил баги и считаю, что это скорее как решение интересних ребусов, как возможность показать в очередной раз свой уровень, внести вклад. И разговоры бывают разные, и тон разговоров. И Ваше высказывание о вытирании соплей говорит скорее не о развитой корпоративной культуре, а об ее отсутствии
Ректальное программирование как метод не должно ограничиваться технологиями 1С. Обращаюсь к сообществу с просьбой проекции и миграции передового опыта на другие технологии.
Лояльность и доверие в отношениях между боссом и подчиненным стоят, к сожалению, на первом месте по сравнению с навыками и профессионализмом ("Лестница в небо", Хазин, Щеглов). ИТ-шники, пробивающие себе дорогу учебой и трудом, к сожалению, имеют меньше шансов на повышение по сравнению с теми, кто профессионально лижет зад начальнику. Об этих софт скиллс идет речь? Разработка ИТ систем - это зачастую борьба с собственными слабостями и окружающими бесами. И да, никому не понравится сотрудник, который старается улучшить процессы и системы, критикует дерьмовые решения, доставляя тем самым дискомфорт руководству и подлецам в его окружении
https://kraevoy.com/kriterii-celi-po-maksimu-batyrevu.html
The .NET Portability Analyzer — неплохо, лучше чем ничего. Но как конвертировать проект в 270 сборок? Никаких шансов из-за взаимных зависимостей
Когда появится полноценный тул для миграции с .net Framework 4.x на .net Core?
То что я описал меня сначала тоже удивляло. Но в больших фирмах в РФ все так или почти так. Предположим есть некая система и ее надо слегка доработать. На разработку уйдет 6 ч одного программиста. При стоимости часа пускай даже 1000 р фирма ничего не заработает. А теперь представьте, что компания собирает команду из 2 разработчиков, тестировщика, аналитика, архитектора, менеджера проектов, владельца продукта. Эти 7 человек получают, предположим, по 100000/мес плюс соц выплаты, а проект берется на сопровождение на 1 год, плюс маржа. Контракт получается на 20 лямов минимум. Вот так можно вести бизнес, а мы тут сайтики за 50$ на вордпрессе делаем. Мы живем в таком месте и в такое время, что маленькая цена неинтересна не только исполнителю, но и заказчику, особенно если он государственный
В небольших компаниях ничего такого нет и да, каждому программисту дают в разработку существующую или новую систему. Иногда нет никакого деления на тимлидов, сеньоров и джунов, а в трудовую разрешают записать любую формулировку, например «Старший инженер-программист». Но это, конечно, уходит в прошлое, сейчас кругом сплошной Agile/Scrum
Кстати я проходил тестовый день, точнее это была тестовая ночь — компания работает по американскому времени в Москве. ЗП предлагали сильно выше чем у сеньора по рынку, (ЗП была просто конская). В этот тестовый рабочий день я пофиксил баг в незнакомой мне системе, мои шансы стали очень высоки, но на следующий день я отказался. 1) Компания не софтверная, два разработчика пилят CRM-ку для себя. 2) Работать с 18:00 до 3:00 (1 час на бед) оказалось нереально сложно. Даже адаптировавшись я не смог бы нормально общаться с семьей, поскольку днем я бы отсыпался, да и в выходные дни был бы вынужден жить по такому же распорядку. 3) Бэкенд на Node.js и взаимодействие с БД представляет собою спагетти-код от земли до неба и глядя на все это, и вспоминая .net, EF, Linq, я понял, что это будет не работа а мучение.
Именно! Попробуйте сегодня устроиться без резюме. От качества резюме зависят ваши шансы. Существует целая наука о том как составлять резюме. Каждый разработчик заботится о собственном резюме. Понятно, что за резюме должно быть что-то реальное.
Разработчик заинтересован в том, чтобы в резюме красовались знаменитые бренды, в этом нет ничего странного. Это как в универе, первые три сессии ты работаешь на зачетку, остальные сессии зачетка работает на тебя.
далее идет очень странный вывод, комментировать его не могу, но что касается времени, то его действительно много, только большинство тратит его не на карьеру. Попробуйте отказаться от компьютерных игр, сериалов и тиктока и Вы заметите, что сможете делать по одному тестовому заданию в день
Но с точки зрения программиста это все равно творчества, поскольку он не знает о другой реализации. Да и абсолютно одинаковых велосипедов Вы не встретите, если это не копипаст, согласитесь?
Труд программиста, в основном, уникален, поскольку повторяющиеся фрагменты кода складываются в библиотеки классов. С учетом определения творчества, труд программиста творческий, т.к. он создает, то есть творит и всегда что-то новое. Можно возразить, дескать у многих программистов нет свободы выбора — это не так, свобода выбора способа решения задачи, даже минимальная, всегда сохраняется.
Все правильно, в хороших компаниях это происходит редко, тут Вы мне не противоречите. Но я хотел бы добавить, что не в каждой компании баги на проде превращаются в непрерывную истерику менеджмента.
Смотря что Вы понимаете под корпоративной культурой. Корпоративная культура некоторых сообществ позволяла им выжывать в самых экстремальных ситуациях на протяжении столетий и в итоге влиять на судьбы мира, все зависит от сути и качества этой самой корпоративной культуры.
Разве ошибки в проде не являются чем-то ненормальным и нестандартным, редким? Или в Вашей компании это норма и происходит постоянно? Если норма, то новичку нечего там делать. Скорее всего у вас бардак, невыстроенные процессы, нехватка ресурсов, нет код ревью и тестов, посредственный уровень разработчиков, обусловленный невозможностью нанять хороших или даже блатом и кумовством.
Корпоративная культура — единственная причина, по которой компания будет существовать, это как билет в будущее, многие этого не понимают.
Собеседование и решение тестов нельзя сравнивать с багфиксом. Я много лет фиксил баги и считаю, что это скорее как решение интересних ребусов, как возможность показать в очередной раз свой уровень, внести вклад. И разговоры бывают разные, и тон разговоров. И Ваше высказывание о вытирании соплей говорит скорее не о развитой корпоративной культуре, а об ее отсутствии