Ой ну наконец-то, хоть кто-то как по учебнику делает. Жаль что учебников пока на эту тему не пишут. Поэтому торчим на технических секциях по 2,5-4 часа, выходя с которых думаешь "а это они кого ищут и для чего". И напротив - ищешь себе человека с опытом в системном дизайне в продуктовую команду, а идут подготовленные к литкоду и очень смутным пониманием архитектурных принципов, особенно в том как они на практике работают. Беда-беда.
Ой ну такие все нежные прям. Взяли весь рабочий сленг и записали в коллективное "общебесительное". Ну и как теперь работать? Зачитывать по-английски, или дословно переводить, сидя прямо в накрахмаленной рубашке и отпивая эспрессо из маленькой чашечки, оттопырив мизинчик?
Главное помните - средний разраб переходит с айти-суржика на государственный (на работе) только разговаривая с дебилами. Так что если с вами говорят максимально понятно и доступно, то вы очевидно не свой.
Не бывают они плохие и хорошие. По вашим же словам они бывают подходящие и нет. Но это вы в СПГС ударились. Я часто провожу собесы. Приходит чувак и говорит "я SQL руками не пишу" (это кстати не единичный случай). Не конкретно в решении где нужно поддерживать разные диалекты, и не по другим каким-то привязанным к задачам причинам. Просто не пишет. Принцип такой. Или не признает в принципе реляционок. Без привязки к тому что в них лежит и зачем оно там лежит. Просто не признает. Или считает что приложения должны быть 100% онлайн без автономности. Вне зависимости от того зачем они нужны и в каких условиях их эксплуатируют.
Я так-то только за если человек может внятно и связно рассказать где какой инструмент нужен а где не нужен. Это значит что можно не задавать ему глупые вопросы про хеш-таблицу и вызубренные принципы солид, а нормально перетереть за настоящую работу. Но в подавляющем большинстве случаев заявления о неприятии инструмента X - принципиальные и не подкреплены разумными аргументами. Такая вот фигня.
Не может конечно. Когнитивное искажение, уважаемый, это классифицировать инструмент в терминах "от лукавого"/"от бога". Таким людям нужно лечение, а не работа. Без искажений это звучит как "знаю этот инструмент на уровне блаблабла".
Ну тут как сказать. Я однажды искал себе пару мидлов, отсобеседовал за полгода кучу народа, в итоге наняли двух джунов с которыми я увидел что сработаемся. И это было лучшее решение в моей жизни. Один делал быстро и плохо, но позволил здорово сократить сроки, несмотря на то что пришлось потом серьезно рефакторить. Второй делал медленно и вдумчиво, а главное слушал внимательно и в итоге возглавил проект когда я с него уже ушел в другую компанию. Регалии - они такое себе. Надо с людьми работать.
Ну и да, "отличное новое полено" после универа это стажер.
А господин точно лид с 2003-го? Квалифицированный разработчик отличается не скоростью разработки, а скоростью деградации (усложнения поддержки проекта). Она у него ниже чем у неквалифицированного настолько, что может достигать отрицательных значений. Человек усложняющий поддержку не называется сеньором. Нет ну то есть называется, но не является. Джун может работать ооочень быстро, проблема в том что отпущенный в автоном джун разгоняет эту самую деградацию и за ним всегда нужно вдумчивое ревью, жесткая корректировка, или решение прописанное досконально. Так что на любом проекте необходимо n высококвалифицированных сотрудников и n*m сотрудников попроще где m - индивидуально от количества задач которые эти n имеют и главное способны делегировать со всеми отягчающими.
Ну на моей практике надо наваливать про контекст пожирнее, все равно в работе игнорят. Типа три раза сказать, попросить повторить, потом еще раз вернуться и еще раз напомнить.
Да это понятно. Просто подливаю ложку дегтя. Или добавляю акцент. Во внедрении инструментов ключевой же вопрос: "Чтобы что?". Архитектуры, аджайл-практики, различные driven development, воркфлоу, гитфлоу - всегда вяжутся на кадры, особенности продукта, структуру организации, стеки и прочее, в том числе и друг на друга. Этот момент постоянно ускользает из внимания многих даже опытных людей, не то что неофитов.
Скажем даже гитлаб-флоу уже доставляет неудобств при релизах по расписанию. Потому как состав его частенько утверждается после тестирования отдельно по задачам из билдов ci по результатам регресса кандидата с уточнением. И если по итогам всего решили какую-то довольно комплексную задачу не катить, то возникает необходимость хирургического вмешательство в девелоп. А сроки-то первичны. Усугублять это картину еще и тбд нет абсолютно никакого смысла, если оставлять воркфлоу над этим таким же.
Поэтому закрываю форточку и душню что первичен не подход а контекст внедрения.
Что-то основанное на заведомо необходимых черрипиках выглядит плохо. Вообще малой командой можно очень извращенно приседать, вплоть до хранения веток задач порознь до момента релиза который оформляется как кандидат и отправки в девелоп и мастер исключительно его. Все очень зависит от релиз трейна. В мобайле с малыми командами, долгим тестированием и согласованием состава релиза лучше потом много мержить чем постоянно черрипикать. Можно нехило так влететь с ними в сложно диагностируемую неконсистентность.
Вот у вас вроде местами адекватные комментарии (и с огоньком), но статья какая-то как будто натужная и полярно-передернутая. А ведь Акртика и Антактика места весьма негустонаселенные. Вот конкретно это - нормальная и адекватная оценка рисков работника. Но в целом я за двадцать с лишним лет видел все вышеперечисленное и немного больше - не такое оно все и большая проблема. Потому что иногда отыгрывает в обратную сторону. Как и плач предпринимателя о том что он несет риски. Нормально живут с долгами которые им за всю жизнь не выплатить. И продолжают "предпринимать".
Ключевая проблема упомянутых "ждунов-вкатунов" в том что им собственно деньги все заслоняют. И с одной стороны их можно понять - я вырос в неполной семье которая жила на зарплату моей мамы-медсестры и мне понятно её чувство бессилия что-то поменять. Из такого и вылезает поведение "вкатывайся-ври-иди-по-головам". Осуждать я это не вправе. Но сфера-то рисковая, уверенно стоять на ногах вы в ней сможете только имея нехилую базу экспертизы под ногами. И как высоко бы вы не забрались по варианту 2 - если в процессе на экспертизу вы забили (а приобрести ее можно только ненормированным и тяжелым когнитивным трудом) вы будете потом плакать о своих рисках. Будь вы разработчик, техдир, гендир, или владелец компании. На любой позиции, в любой роли. А если она есть - пожмете плечами, скажете что-то типа "придурки" и пойдете дальше. Опять же справедливо для любой роли.
а можно еще "ку" и присесть два раза
но это если штаны малиновые
эРХаЧеПе их называют, цэ там отродясь не бывало
Коллега, у вас стул прожгло!
да чот я не знаю, сказать "кью" как-то несложно, тащемта
Так у вас же ж это, температура там. Стоит ли превращать в "аналитику" факт того что на hh к вам по этой причине охладели.
У вас там ошибочбка, правильно: "надеюсь, меня уволят".
Ой ну наконец-то, хоть кто-то как по учебнику делает. Жаль что учебников пока на эту тему не пишут. Поэтому торчим на технических секциях по 2,5-4 часа, выходя с которых думаешь "а это они кого ищут и для чего". И напротив - ищешь себе человека с опытом в системном дизайне в продуктовую команду, а идут подготовленные к литкоду и очень смутным пониманием архитектурных принципов, особенно в том как они на практике работают. Беда-беда.
Ой ну такие все нежные прям. Взяли весь рабочий сленг и записали в коллективное "общебесительное". Ну и как теперь работать? Зачитывать по-английски, или дословно переводить, сидя прямо в накрахмаленной рубашке и отпивая эспрессо из маленькой чашечки, оттопырив мизинчик?
Главное помните - средний разраб переходит с айти-суржика на государственный (на работе) только разговаривая с дебилами. Так что если с вами говорят максимально понятно и доступно, то вы очевидно не свой.
так ручку ж дергает, и в мыслях не было, трщ прапорщик
кьюеуе ж
Не бывают они плохие и хорошие. По вашим же словам они бывают подходящие и нет. Но это вы в СПГС ударились. Я часто провожу собесы. Приходит чувак и говорит "я SQL руками не пишу" (это кстати не единичный случай). Не конкретно в решении где нужно поддерживать разные диалекты, и не по другим каким-то привязанным к задачам причинам. Просто не пишет. Принцип такой. Или не признает в принципе реляционок. Без привязки к тому что в них лежит и зачем оно там лежит. Просто не признает. Или считает что приложения должны быть 100% онлайн без автономности. Вне зависимости от того зачем они нужны и в каких условиях их эксплуатируют.
Я так-то только за если человек может внятно и связно рассказать где какой инструмент нужен а где не нужен. Это значит что можно не задавать ему глупые вопросы про хеш-таблицу и вызубренные принципы солид, а нормально перетереть за настоящую работу. Но в подавляющем большинстве случаев заявления о неприятии инструмента X - принципиальные и не подкреплены разумными аргументами. Такая вот фигня.
А вот это предлагаю "отлить в граните".
Не может конечно. Когнитивное искажение, уважаемый, это классифицировать инструмент в терминах "от лукавого"/"от бога". Таким людям нужно лечение, а не работа. Без искажений это звучит как "знаю этот инструмент на уровне блаблабла".
Ну тут как сказать. Я однажды искал себе пару мидлов, отсобеседовал за полгода кучу народа, в итоге наняли двух джунов с которыми я увидел что сработаемся. И это было лучшее решение в моей жизни. Один делал быстро и плохо, но позволил здорово сократить сроки, несмотря на то что пришлось потом серьезно рефакторить. Второй делал медленно и вдумчиво, а главное слушал внимательно и в итоге возглавил проект когда я с него уже ушел в другую компанию. Регалии - они такое себе. Надо с людьми работать.
Ну и да, "отличное новое полено" после универа это стажер.
А господин точно лид с 2003-го? Квалифицированный разработчик отличается не скоростью разработки, а скоростью деградации (усложнения поддержки проекта). Она у него ниже чем у неквалифицированного настолько, что может достигать отрицательных значений. Человек усложняющий поддержку не называется сеньором. Нет ну то есть называется, но не является. Джун может работать ооочень быстро, проблема в том что отпущенный в автоном джун разгоняет эту самую деградацию и за ним всегда нужно вдумчивое ревью, жесткая корректировка, или решение прописанное досконально. Так что на любом проекте необходимо n высококвалифицированных сотрудников и n*m сотрудников попроще где m - индивидуально от количества задач которые эти n имеют и главное способны делегировать со всеми отягчающими.
Ну на моей практике надо наваливать про контекст пожирнее, все равно в работе игнорят. Типа три раза сказать, попросить повторить, потом еще раз вернуться и еще раз напомнить.
Да это понятно. Просто подливаю ложку дегтя. Или добавляю акцент. Во внедрении инструментов ключевой же вопрос: "Чтобы что?". Архитектуры, аджайл-практики, различные driven development, воркфлоу, гитфлоу - всегда вяжутся на кадры, особенности продукта, структуру организации, стеки и прочее, в том числе и друг на друга. Этот момент постоянно ускользает из внимания многих даже опытных людей, не то что неофитов.
Скажем даже гитлаб-флоу уже доставляет неудобств при релизах по расписанию. Потому как состав его частенько утверждается после тестирования отдельно по задачам из билдов ci по результатам регресса кандидата с уточнением. И если по итогам всего решили какую-то довольно комплексную задачу не катить, то возникает необходимость хирургического вмешательство в девелоп. А сроки-то первичны. Усугублять это картину еще и тбд нет абсолютно никакого смысла, если оставлять воркфлоу над этим таким же.
Поэтому закрываю форточку и душню что первичен не подход а контекст внедрения.
Что-то основанное на заведомо необходимых черрипиках выглядит плохо. Вообще малой командой можно очень извращенно приседать, вплоть до хранения веток задач порознь до момента релиза который оформляется как кандидат и отправки в девелоп и мастер исключительно его. Все очень зависит от релиз трейна. В мобайле с малыми командами, долгим тестированием и согласованием состава релиза лучше потом много мержить чем постоянно черрипикать. Можно нехило так влететь с ними в сложно диагностируемую неконсистентность.
А как вы определяете методологию
Вот у вас вроде местами адекватные комментарии (и с огоньком), но статья какая-то как будто натужная и полярно-передернутая. А ведь Акртика и Антактика места весьма негустонаселенные. Вот конкретно это - нормальная и адекватная оценка рисков работника. Но в целом я за двадцать с лишним лет видел все вышеперечисленное и немного больше - не такое оно все и большая проблема. Потому что иногда отыгрывает в обратную сторону. Как и плач предпринимателя о том что он несет риски. Нормально живут с долгами которые им за всю жизнь не выплатить. И продолжают "предпринимать".
Ключевая проблема упомянутых "ждунов-вкатунов" в том что им собственно деньги все заслоняют. И с одной стороны их можно понять - я вырос в неполной семье которая жила на зарплату моей мамы-медсестры и мне понятно её чувство бессилия что-то поменять. Из такого и вылезает поведение "вкатывайся-ври-иди-по-головам". Осуждать я это не вправе. Но сфера-то рисковая, уверенно стоять на ногах вы в ней сможете только имея нехилую базу экспертизы под ногами. И как высоко бы вы не забрались по варианту 2 - если в процессе на экспертизу вы забили (а приобрести ее можно только ненормированным и тяжелым когнитивным трудом) вы будете потом плакать о своих рисках. Будь вы разработчик, техдир, гендир, или владелец компании. На любой позиции, в любой роли. А если она есть - пожмете плечами, скажете что-то типа "придурки" и пойдете дальше. Опять же справедливо для любой роли.