А что делать-то, если это так. Как стать сеньором, если сеньоров мало, а новых не делают? Вариантов вроде как немного - прийти в другую фирму на позицию сеньора в качестве мидл+ и быстро догнать тему под возложенной ответственностью. В текущем проекте дождаться, пока текущая верхушка сеньоров свалит и перехватить инициативу. Как-то самому развиваться помимо работы на опенсурс проектах. Сделать вид, что ты сеньор, чтобы пройти интервью.
Подскажите, пожалуйста, какие ещё есть варианты стать сеньором?
Пока ещё да, но ещё питон вышел в лидеры, а ещё хорошо платят go-девам, и проекты на котлин появляются. Автор мог бы давно перейти на питон разработку, так как там порог входа значительно ниже чем в джаве и уже несколько лет работать разработчиком на этом языке. Но он остался на мейнфрейме, остаётся только развести руками
Автор несколько раз повторил, что был спокоен, так как он хорошо знал "бизнес", хотя у современного человека обратная реакция. Кажется очевидным и не нужным объяснения, что знания "бизнеса" ничего не стоят. Так как вне этой компании нужны технические навыки, а не знания какого-то конкретного бизнеса.
Так же, достаточно размыто и вяло было рассказано про то, что человек якобы изучал современные языки программирования. Но при этом почему-то так и остался на мейнфреймах. Здесь хочется развести руки в сторону. Если бы он действительно их изучал, то понял бы, что новые технологии пускай и не менее сложные, а иногда даже более сложные, но при этом они и удобнее, чем эти мейнфреймы, он бы тупо отдыхал бы от своей допотопщины и остался бы на волне, сменив компанию. Но видимо чего-то нехватило.
По какой-то там статистике специалисты меняют специализацию 3 раза в жизни, как раз из-за движения технологий, а так же просто потому что надоедает десятками лет делать одно и то же. Но здесь этого не произошло и вот, ему сказали, что пора.
Было ли это ожидаемо? Было. Почему человек кормил себя сказками десятки лет? Загадка.
Я думаю, в айти сфере надо быть более осторожным, и следить, куда движутся технологии.
300 лямов на три года - это не распил , а бюджет центра разработки на 3 года, где есть аналитики, разработчики, тестировщики, менеджеры и начальники + расходы на оборудование и начальную эксплуатацию и наладку + премии.
На практике не каждая роль проекта может быть совмещена с другой ролью. Это означает, что твой комфорт сильно зависит от наличия хотя бы одного коллеги рядом, кто мог бы подменить тебя в отпуске. Тут кстати про отдых ни слова. А между делом work / life balance очень важен для достижения результата.
У кого как, у кого-то это регулярное «собрание» на кухне, у кого-то по телефону, суть не в том, где и в какое время, а в их количестве. Если вам нравится проводить один рандомный митап на кухне — пожалуйста, у нас нет такой возможности, так что мы проводим обычную планерку один раз в день удаленно по конференц-связи. важно, что она одна.
кроме того, стоит также сказать, что обмен идеями не всегда зависит от способа и места коммуникации, а еще от людей. Если люди не готовы делиться идеями, это не будет работать ни на собрании, ни в кафе.
Хотя конечно иногда митапов на кухне нехватает, но реальность немного изменилась.
Спасибо за развернутый ответ. Читал его и понял, что намного шире эту проблему описывает Эрик Эванс в книге доменно-ориентированное проектирование.
В его книге спайк — это доменная модель и система взаимодействия ее компонентов, где-то составленная, сохраненная и визуализированная.
Доменная модель основана на едином языке, понятном бизнесу и команде разработки.
Если невозможно построить доменную модель, значит анализ не завершен.
Какой смысл тогда делать что-то, если за границами решения, которое планируется сделать нет знаний? Сделаешь — придется переделывать. Спайк — это вовсе не визуализация письма в почте. А модель, в которой есть входные данные от пользователя, процесс их движения в системе и влияние на систему, и результат.
В общем, как он это называет — управление сложностью
Хочется больше примеров. Какие ещё есть варианты спайков. Также как сделать так, чтобы спайк внезапно не стал рабочим решением которое отгрузят? Что именно на выходе получается от спайка? Что такое "глубже погрузиться в проблему"? Как вам помогает прототип в виде бумаги? Неужели это письмо нельзя сконфигурить находу? Разве оформление на бумаге помогает решить технические проблемы? Полагаю, что нет. Нужны примеры того, как именно спайк может помочь на практике для решения технической проблемы.
Если это можно взять и использовать, почему нет? Вы же когда машину покупаете, не идете в техникум или универ, где изучаете фундаментальную теорию создания сложных технических устройств? Нет, конечно, вы просто изучаете мануал к автомобилю. Тут так же, для учебных проектов, чтобы зайти в область — нормально. И можно только порадоваться стремлению к инженерному делу. Дальше надо дать конструктивные советы по плану более глубокого изучения этого дела. Чтобы человеку было понятно, куда двигаться дальше. Как раз будет чем заняться до конца школы.
Правда состоит в том, что люди всегда остаются людьми. Человек делает то, что надо ему в данный конкретный момент времени и ему плевать на индустрию в целом. Хочет американской мечты — едет в калифорнию выбивать чек на 5 лямов, чтобы жить согласно своему представлению. И поведет себя как человек. Хочет он прокачать свои навыки, подумать мозгом, решить сложнейшую задачу — он никуда не едет, ни в какую калифорнию, а остаётся в Питере и пишет язык Котлин.
Да, может показаться, что человек делает это для индустрии, но на самом деле это не так. Человек в первую очередь делает это для себя самого. Он бы не писал этот язык, если бы не кайфовал от сложной задачи.
В первом случае человек кайфует от денег и возможности управлять стартапом, во втором, от решения сложной задачи, оказавшись в нужном месте в нужное время.
Стоит при этом отметить, что он пока не знает, куда он придёт. Картинка будущего не равна будущему, которое произойдет.
Вполне возможно, что через 10 лет оба эти человека будут видеть результаты своих трудов и понимать, что и то и другое было зря.
Дудя тоже можно понять. Ему хочется яркой картинки. И он делает этот репортаж тоже по сугубо своим личным приоритетам. Чтобы заработать больше денег.
Вывод из этого всего один — человек, который занимается наукой ничем не отличается от человека, тупо зарабатывающего деньги. Все эти идейные размышления — фейк. Учёный, идущий в науку ради науки точно так же эксплуатирует чувство собственной значимости, как и человек, кричащий о пяти миллионом чеке в интервью.
Думаю, что статья поставила всех в диссонанс, потому что читая ее, постоянно возникает вопрос "нафига вся эта чушь вообще нужна, какие-то лишние совершенно запары и суета".
Классическая ошибка — недостаток контекста у читателя. Его надо было создать, а не писать все в виде лапши.
Надо более системно подходить:
Предисловие
описание команды, кто что зачем, что делаете
когда, как давно и по каким соображениям в команде сделали скрам, что изменилось с его введением, команде хорошо или плохо или может нафиг он никому не нужен?
вести основные идеи скрама, ещё раз для понимания и контекста
обязанности скрам мастера, какие ещё роли есть в процессе кроме него, кто что делает, какую проблему решает
Что такое agile
Как выглядел процесс разработки, каким он стал после скрама, каким он стал "после вас".
Например, изначально были двухнедельные спринты, но стало понятно, что фичи пилить сложно ввиду разных зависимостей и недостатка знаний и временно спринты стали размером в месяц. Да что угодно.
В конце статьи непонятно, добились ли вы своих целей или все как было непонятным сбродом, так и осталось.
Вы закончили статью опять какими-то абстрактными навыками опять же оторванными от контекста.
Статьи о любой методологии и процессе должны быть цельными на мой взгляд, идти бок о бок с этой методологией.
Они должны описывать в целом экосистему, ее эволюцию при внедрении методологии и эволюцию вашего личного опыта.
Ну, например, тезис о цикле Деминга и о постоянном совершенствовании процесса.
Например, тезис о том, как не закрывать глаза на проблемы, а наоборот, выносить их как можно быстрее наверх и быстрее на них реагировать.
Сверху означает «с начальством».
Я считаю, что эффективность и отношение к делу связаны напрямую. Потому что количество неубранных за своей работой какашек напрямую отражается на всеобщей работе в дальнейшем. Это не связано с вашей текущей задачей, а имеет накопительный эффект в перспективе.
> Он может лучше.
Да, вы правы, здесь я поторопился.
Написано очень хорошо и во многом я согласен с тезисами.
Очень хочется прочитать главу про то, как не будучи руководителем доказывать эти тезисы сверху.
Нормальная тема, лучше чем смотреть на стандартный вывод. Любителям настраивать все под себя должно понравиться. Думаю, можно расширить проект. Добавить выбор стиля прогресс бара. Пускай это будет репозиторий стилей и одновременно тулза для их смены. Чтобы опенсурс сообщество добавило в твой проект другие приколы. Для этого придется переименовать пакет.
А что делать-то, если это так. Как стать сеньором, если сеньоров мало, а новых не делают? Вариантов вроде как немного - прийти в другую фирму на позицию сеньора в качестве мидл+ и быстро догнать тему под возложенной ответственностью. В текущем проекте дождаться, пока текущая верхушка сеньоров свалит и перехватить инициативу. Как-то самому развиваться помимо работы на опенсурс проектах. Сделать вид, что ты сеньор, чтобы пройти интервью.
Подскажите, пожалуйста, какие ещё есть варианты стать сеньором?
Пока ещё да, но ещё питон вышел в лидеры, а ещё хорошо платят go-девам, и проекты на котлин появляются. Автор мог бы давно перейти на питон разработку, так как там порог входа значительно ниже чем в джаве и уже несколько лет работать разработчиком на этом языке. Но он остался на мейнфрейме, остаётся только развести руками
Автор несколько раз повторил, что был спокоен, так как он хорошо знал "бизнес", хотя у современного человека обратная реакция. Кажется очевидным и не нужным объяснения, что знания "бизнеса" ничего не стоят. Так как вне этой компании нужны технические навыки, а не знания какого-то конкретного бизнеса.
Так же, достаточно размыто и вяло было рассказано про то, что человек якобы изучал современные языки программирования. Но при этом почему-то так и остался на мейнфреймах. Здесь хочется развести руки в сторону. Если бы он действительно их изучал, то понял бы, что новые технологии пускай и не менее сложные, а иногда даже более сложные, но при этом они и удобнее, чем эти мейнфреймы, он бы тупо отдыхал бы от своей допотопщины и остался бы на волне, сменив компанию. Но видимо чего-то нехватило.
По какой-то там статистике специалисты меняют специализацию 3 раза в жизни, как раз из-за движения технологий, а так же просто потому что надоедает десятками лет делать одно и то же. Но здесь этого не произошло и вот, ему сказали, что пора.
Было ли это ожидаемо? Было. Почему человек кормил себя сказками десятки лет? Загадка.
Я думаю, в айти сфере надо быть более осторожным, и следить, куда движутся технологии.
300 лямов на три года - это не распил , а бюджет центра разработки на 3 года, где есть аналитики, разработчики, тестировщики, менеджеры и начальники + расходы на оборудование и начальную эксплуатацию и наладку + премии.
Это нормальная цена, ни много ни мало.
На практике не каждая роль проекта может быть совмещена с другой ролью. Это означает, что твой комфорт сильно зависит от наличия хотя бы одного коллеги рядом, кто мог бы подменить тебя в отпуске. Тут кстати про отдых ни слова. А между делом work / life balance очень важен для достижения результата.
Не поверю, что человек ради рекламы разгребал все это дело.
Тут суть не в результате, а в процессе. Интересны именно технические подробности, детали.
кроме того, стоит также сказать, что обмен идеями не всегда зависит от способа и места коммуникации, а еще от людей. Если люди не готовы делиться идеями, это не будет работать ни на собрании, ни в кафе.
Хотя конечно иногда митапов на кухне нехватает, но реальность немного изменилась.
А было бы точнее проще в реализации и удобнее перчатки с маячками и камера? Руку детектировать сложнее, руки разные бывают
Спасибо за развернутый ответ. Читал его и понял, что намного шире эту проблему описывает Эрик Эванс в книге доменно-ориентированное проектирование.
В его книге спайк — это доменная модель и система взаимодействия ее компонентов, где-то составленная, сохраненная и визуализированная.
Доменная модель основана на едином языке, понятном бизнесу и команде разработки.
Если невозможно построить доменную модель, значит анализ не завершен.
Какой смысл тогда делать что-то, если за границами решения, которое планируется сделать нет знаний? Сделаешь — придется переделывать. Спайк — это вовсе не визуализация письма в почте. А модель, в которой есть входные данные от пользователя, процесс их движения в системе и влияние на систему, и результат.
В общем, как он это называет — управление сложностью
Хочется больше примеров. Какие ещё есть варианты спайков. Также как сделать так, чтобы спайк внезапно не стал рабочим решением которое отгрузят? Что именно на выходе получается от спайка? Что такое "глубже погрузиться в проблему"? Как вам помогает прототип в виде бумаги? Неужели это письмо нельзя сконфигурить находу? Разве оформление на бумаге помогает решить технические проблемы? Полагаю, что нет. Нужны примеры того, как именно спайк может помочь на практике для решения технической проблемы.
Хорошо, соглашусь. С первым тезисами, с последним только отчасти.
Я бы хотел, чтобы от критики подхода, которую мы уже обсудили, перешли к плану обучения, который был бы грамотным с точки зрения комьюнити.
Вот, что бы вы посоветовали ему изучить и в каком порядке, каких авторов и какие книги в ближайшие 5 лет?
Если это можно взять и использовать, почему нет? Вы же когда машину покупаете, не идете в техникум или универ, где изучаете фундаментальную теорию создания сложных технических устройств? Нет, конечно, вы просто изучаете мануал к автомобилю. Тут так же, для учебных проектов, чтобы зайти в область — нормально. И можно только порадоваться стремлению к инженерному делу. Дальше надо дать конструктивные советы по плану более глубокого изучения этого дела. Чтобы человеку было понятно, куда двигаться дальше. Как раз будет чем заняться до конца школы.
Правда состоит в том, что люди всегда остаются людьми. Человек делает то, что надо ему в данный конкретный момент времени и ему плевать на индустрию в целом. Хочет американской мечты — едет в калифорнию выбивать чек на 5 лямов, чтобы жить согласно своему представлению. И поведет себя как человек. Хочет он прокачать свои навыки, подумать мозгом, решить сложнейшую задачу — он никуда не едет, ни в какую калифорнию, а остаётся в Питере и пишет язык Котлин.
Да, может показаться, что человек делает это для индустрии, но на самом деле это не так. Человек в первую очередь делает это для себя самого. Он бы не писал этот язык, если бы не кайфовал от сложной задачи.
В первом случае человек кайфует от денег и возможности управлять стартапом, во втором, от решения сложной задачи, оказавшись в нужном месте в нужное время.
Стоит при этом отметить, что он пока не знает, куда он придёт. Картинка будущего не равна будущему, которое произойдет.
Вполне возможно, что через 10 лет оба эти человека будут видеть результаты своих трудов и понимать, что и то и другое было зря.
Дудя тоже можно понять. Ему хочется яркой картинки. И он делает этот репортаж тоже по сугубо своим личным приоритетам. Чтобы заработать больше денег.
Вывод из этого всего один — человек, который занимается наукой ничем не отличается от человека, тупо зарабатывающего деньги. Все эти идейные размышления — фейк. Учёный, идущий в науку ради науки точно так же эксплуатирует чувство собственной значимости, как и человек, кричащий о пяти миллионом чеке в интервью.
Думаю, что статья поставила всех в диссонанс, потому что читая ее, постоянно возникает вопрос "нафига вся эта чушь вообще нужна, какие-то лишние совершенно запары и суета".
Классическая ошибка — недостаток контекста у читателя. Его надо было создать, а не писать все в виде лапши.
Надо более системно подходить:
Предисловие
описание команды, кто что зачем, что делаете
когда, как давно и по каким соображениям в команде сделали скрам, что изменилось с его введением, команде хорошо или плохо или может нафиг он никому не нужен?
вести основные идеи скрама, ещё раз для понимания и контекста
обязанности скрам мастера, какие ещё роли есть в процессе кроме него, кто что делает, какую проблему решает
Что такое agile
Как выглядел процесс разработки, каким он стал после скрама, каким он стал "после вас".
Например, изначально были двухнедельные спринты, но стало понятно, что фичи пилить сложно ввиду разных зависимостей и недостатка знаний и временно спринты стали размером в месяц. Да что угодно.
В конце статьи непонятно, добились ли вы своих целей или все как было непонятным сбродом, так и осталось.
Вы закончили статью опять какими-то абстрактными навыками опять же оторванными от контекста.
Статьи о любой методологии и процессе должны быть цельными на мой взгляд, идти бок о бок с этой методологией.
Они должны описывать в целом экосистему, ее эволюцию при внедрении методологии и эволюцию вашего личного опыта.
Например, тезис о том, как не закрывать глаза на проблемы, а наоборот, выносить их как можно быстрее наверх и быстрее на них реагировать.
Сверху означает «с начальством».
> Он может лучше.
Да, вы правы, здесь я поторопился.
С вашей точки зрения, говно лежало всегда и так и будет лежать каждый год дальше, выползать из под снега и радовать своими красками.
Я лично считаю, что суть идеи в борьбе с невежеством и некомпетентностью любого рода.
Очень хочется прочитать главу про то, как не будучи руководителем доказывать эти тезисы сверху.
Нормальная тема, лучше чем смотреть на стандартный вывод. Любителям настраивать все под себя должно понравиться. Думаю, можно расширить проект. Добавить выбор стиля прогресс бара. Пускай это будет репозиторий стилей и одновременно тулза для их смены. Чтобы опенсурс сообщество добавило в твой проект другие приколы. Для этого придется переименовать пакет.