Плюсы и минусы продолжительной работы на одном месте
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
О чем еще нужно помнить
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Как сделать задачу, если недостаточно требований?
Мы много говорим о том, что нужно правильно описываться задачи и хорошо настраивать процессы. Но все это в идеале, а работать нужно прямо сейчас. А что если ваш бизнес не умеет формулировать требования к задачам? Ну вот не умеет и все тут. Допустим увольняться вы из-за этого не готовы, но и переделывать потом все с нуля пока не угадаете, что было нужно, не хотите. Сейчас мы разберем алгоритм, по которому вы сможете не только сами понять составляющие и последовательность выполнения задачи, но и сможете уточнить требования до необходимого вам уровня детализации у бизнеса.
Пользовательские пути - основа основ
Первое, что вам нужно сделать, познакомиться с понятие пользовательских путей. Пользовательский путь - это путь клиента к достижению цели, описывающий его полное взаимодействие с продуктом. Все, что мы видим в продукте состоит из пользовательских путей (как минимум должно из них состоять, но даже не каждый бизнес знает, что это такое, поэтому иногда пользователи заходят в тупик). Путь состоит из действий пользователя, например: пользователь зашел на главную страницу -> пользователь кликнул на ссылку статьи -> пользователь нажал 'написать комментарий' и т.д. Действия могут быть разного уровня детализации.
Как пользовательские пути использовать для уточнения задач
Итак, вы получили непонятную задачу без нормального описания. Постарайтесь переложить все, что вам о ней известно, на пользовательский путь или пути. Начните с самого начала, как пользователь зашел на продукт, как он попал к нужному функционалу новой задачи, что он в нем делает в какой последовательности. Так как данных у вас недостаточно, вы обязательно упретесь в непонимание, что конкретно должно происходить и как это должно выглядеть, или увидите тупик, который никуда не ведет. Каждое такое непонятное место запишите в список. С этим списком идите к тому, кто выдал вам эту задачу и начинайте его спрашивать по порядку, что в каждом из этих мест должно происходить. Естественно все за ним записываете. После того, как на все ваши вопросы ответили, дополняете свою схему пользовательских путей этой новой информацией. Снова проходитесь по каждому пути и задаете себе вопрос, понимаете ли вы каждый шаг и что вам в нем нужно сделать. Если вы опять начинаете где-то упираться в вопросы, составляете из них новый список и снова идете спрашивать. Так вы ходите итерационно, пока вам не станет все ясно.
У вас может создаться впечатление, что выглядит так, будто вы “как дурак” не можете разобраться со своей задачей и пристаете к бизнесу. А оно вам надо? Во-первых, если вам так покажется, то помните, что дурак не тот, кто спрашивает, когда ему непонятно, а тот, кто делает сам не зная что и тратит время и деньги компании впустую, а потом он же еще и остается виноват в результате (вот вам надо быть потом виноватым?). Не делайте то, что вам непонятно, и уж точно не додумывайте задачи за бизнес. Вы можете нанести вред не только себе, но и всему продукту. Во-вторых, а какая у вас альтернатива? Если вы сделаете то, что не понимаете, то вы точно где-то промахнетесь, потом вам придется это переделывать, а может и не раз, вы не уложитесь в сроки, потому что невозможно оценить правильно то, что не понимаешь, а с переделками сроки вообще остануться сильно далеко. В итоге, вы только намучаетесь и потратите в разы больше времени, получив недовольное начальство, бизнес и сомнительный результат. В-третьих, само собой разумеется, что бизнес должен с самого начала сам все продумывать и давать вам хорошие описания задач. Но мы не живем в идеальном мире, и иногда, чтобы делать свою работу, нам приходится помогать с задачами за границами наших компетенций. Новый опыт с этого вы точно получите и лучше начнете понимать не только свою работу, но и продукт, над которым работаете. А в конце сможете гордиться проделанной на совесть работой. Делать ли это? Решение за вами.
#разработчику
Мы много говорим о том, что нужно правильно описываться задачи и хорошо настраивать процессы. Но все это в идеале, а работать нужно прямо сейчас. А что если ваш бизнес не умеет формулировать требования к задачам? Ну вот не умеет и все тут. Допустим увольняться вы из-за этого не готовы, но и переделывать потом все с нуля пока не угадаете, что было нужно, не хотите. Сейчас мы разберем алгоритм, по которому вы сможете не только сами понять составляющие и последовательность выполнения задачи, но и сможете уточнить требования до необходимого вам уровня детализации у бизнеса.
Пользовательские пути - основа основ
Первое, что вам нужно сделать, познакомиться с понятие пользовательских путей. Пользовательский путь - это путь клиента к достижению цели, описывающий его полное взаимодействие с продуктом. Все, что мы видим в продукте состоит из пользовательских путей (как минимум должно из них состоять, но даже не каждый бизнес знает, что это такое, поэтому иногда пользователи заходят в тупик). Путь состоит из действий пользователя, например: пользователь зашел на главную страницу -> пользователь кликнул на ссылку статьи -> пользователь нажал 'написать комментарий' и т.д. Действия могут быть разного уровня детализации.
Как пользовательские пути использовать для уточнения задач
Итак, вы получили непонятную задачу без нормального описания. Постарайтесь переложить все, что вам о ней известно, на пользовательский путь или пути. Начните с самого начала, как пользователь зашел на продукт, как он попал к нужному функционалу новой задачи, что он в нем делает в какой последовательности. Так как данных у вас недостаточно, вы обязательно упретесь в непонимание, что конкретно должно происходить и как это должно выглядеть, или увидите тупик, который никуда не ведет. Каждое такое непонятное место запишите в список. С этим списком идите к тому, кто выдал вам эту задачу и начинайте его спрашивать по порядку, что в каждом из этих мест должно происходить. Естественно все за ним записываете. После того, как на все ваши вопросы ответили, дополняете свою схему пользовательских путей этой новой информацией. Снова проходитесь по каждому пути и задаете себе вопрос, понимаете ли вы каждый шаг и что вам в нем нужно сделать. Если вы опять начинаете где-то упираться в вопросы, составляете из них новый список и снова идете спрашивать. Так вы ходите итерационно, пока вам не станет все ясно.
У вас может создаться впечатление, что выглядит так, будто вы “как дурак” не можете разобраться со своей задачей и пристаете к бизнесу. А оно вам надо? Во-первых, если вам так покажется, то помните, что дурак не тот, кто спрашивает, когда ему непонятно, а тот, кто делает сам не зная что и тратит время и деньги компании впустую, а потом он же еще и остается виноват в результате (вот вам надо быть потом виноватым?). Не делайте то, что вам непонятно, и уж точно не додумывайте задачи за бизнес. Вы можете нанести вред не только себе, но и всему продукту. Во-вторых, а какая у вас альтернатива? Если вы сделаете то, что не понимаете, то вы точно где-то промахнетесь, потом вам придется это переделывать, а может и не раз, вы не уложитесь в сроки, потому что невозможно оценить правильно то, что не понимаешь, а с переделками сроки вообще остануться сильно далеко. В итоге, вы только намучаетесь и потратите в разы больше времени, получив недовольное начальство, бизнес и сомнительный результат. В-третьих, само собой разумеется, что бизнес должен с самого начала сам все продумывать и давать вам хорошие описания задач. Но мы не живем в идеальном мире, и иногда, чтобы делать свою работу, нам приходится помогать с задачами за границами наших компетенций. Новый опыт с этого вы точно получите и лучше начнете понимать не только свою работу, но и продукт, над которым работаете. А в конце сможете гордиться проделанной на совесть работой. Делать ли это? Решение за вами.
#разработчику
Командность
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
В чем смысл требовать опыт 1-2 года, если есть технические знания?
Столкнулась с таким вопросом в одном из чатов разработчиков: “Зачем в вакансиях требуют опыт 1-2 года, если у человека есть достаточно технических знаний, хоть он и не работал никогда?”. Давайте попробуем разобраться.
Основное, что дает вам опыт, это умение применять знания и находить решения там, где, казалось бы, их нет, в том числе умение искать решения (как ни странно, при всей доступности интернета, искать в нем решения тоже умеет не каждый). Все это приходит с опытом и никакими техническими знаниями не компенсируется.
У меня на практике была одна очень показательная история. Я работа ведущим фронтенд-разработчиком на проекте. У меня в команде были мидл/джун разработчики. Одному из них пришла задача сделать в многострочном блоке в конце троеточие. Из коробки такая задача не делается, такой технической возможности нет. Если начать гуглить решения люди всячески изгаляются, но у всех решений есть минусы. Человек в итоге зашел в тупик и пришел ко мне с этой проблемой. Я решила проблему просто: придумала альтернативное решение - заменить троеточие на градиент внизу блока, который делается элементарно, мы сходили и договорились с дизайнером о новом подходе к отображению блоков, объяснив ситуацию.
Чем показательна эта история? Разработчик был молодец, у него правда было достаточно технических знаний для его уровня. Но эта задача техническими знаниями не решалась, сколько ты в нее не бейся. Зато очень легко решалась в обход. Нужно было лишь придумать решение и правильно его аргументировать. В таких задачах как раз все решает опыт. Именно поэтому джуны без опыта работы смогут делать какие-то простые задачи, но на подобных ситуациях, а они случаются достаточно часто на практике, будут заходить в тупик. А вся эта лишняя работа будет падать на старших разработчиков и мешать им делать свои задачи. Такую инвестицию, с учетом того, что джуны растут быстрее, чем компания может их повышать, поэтому часто быстро увольняются, может себе позволить мало какая компания.
Умение договариваться и аргументировать, почему надо сделать не так, а иначе, особенно с ребятами из бизнеса, тоже приходит с опытом, после десятков споров и обсуждений. Никогда нельзя забывать, что наши коллеги из бизнеса не могут знать какие там точки где не получится поставить. А это еще очень просто объяснить, обычно все намного сложнее. Как-то раз, я битый час объясняла начальнику-бэкендеру, к которому пришла за помощью ПМ, которая вообще ничего не могла понять, почему отрисовка слишком длинного списка может повлиять на производительность браузера. Ему никак не удавалось понять, в чем у меня проблема перебрать значения в массиве и вывести этот злосчастный бесконечный список, который просит ПМ. А ведь он тоже разработчик, ребята из бизнеса - люди вообще никак не связанные с разработкой, попробуйте им такое объяснить (ПМ тогда просто стояла и беспомощно хлопала глазами, мне ее был честно жаль). Тем не менее, наша задача, как разработчиков, вовремя вмешаться в задачу и умело донести, что вот так делать не надо, это будет плохо, а сделать лучше вот так. И иногда это бывает очень сложно. Мы собрали целый список подобных примеров с разборами, как и в какой ситуации объяснить ПО или ПМу, почему что-то нужно сделать так, а не иначе, ознакомиться можно тут.
Вот основные моменты, которые приходят с опытом и никак не компенсируются техническими знаниями. Конечно недостаток всех этих умений придется компенсировать компании, и понятно почему они этого делать не хотят. Время - деньги, и за наше обучение никому платить не интересно. Кто вспомнит еще примеры знаний, которые приходят в опытом, пишите в комментариях, обсудим.
Александра Шаламова
#разработчику
Столкнулась с таким вопросом в одном из чатов разработчиков: “Зачем в вакансиях требуют опыт 1-2 года, если у человека есть достаточно технических знаний, хоть он и не работал никогда?”. Давайте попробуем разобраться.
Основное, что дает вам опыт, это умение применять знания и находить решения там, где, казалось бы, их нет, в том числе умение искать решения (как ни странно, при всей доступности интернета, искать в нем решения тоже умеет не каждый). Все это приходит с опытом и никакими техническими знаниями не компенсируется.
У меня на практике была одна очень показательная история. Я работа ведущим фронтенд-разработчиком на проекте. У меня в команде были мидл/джун разработчики. Одному из них пришла задача сделать в многострочном блоке в конце троеточие. Из коробки такая задача не делается, такой технической возможности нет. Если начать гуглить решения люди всячески изгаляются, но у всех решений есть минусы. Человек в итоге зашел в тупик и пришел ко мне с этой проблемой. Я решила проблему просто: придумала альтернативное решение - заменить троеточие на градиент внизу блока, который делается элементарно, мы сходили и договорились с дизайнером о новом подходе к отображению блоков, объяснив ситуацию.
Чем показательна эта история? Разработчик был молодец, у него правда было достаточно технических знаний для его уровня. Но эта задача техническими знаниями не решалась, сколько ты в нее не бейся. Зато очень легко решалась в обход. Нужно было лишь придумать решение и правильно его аргументировать. В таких задачах как раз все решает опыт. Именно поэтому джуны без опыта работы смогут делать какие-то простые задачи, но на подобных ситуациях, а они случаются достаточно часто на практике, будут заходить в тупик. А вся эта лишняя работа будет падать на старших разработчиков и мешать им делать свои задачи. Такую инвестицию, с учетом того, что джуны растут быстрее, чем компания может их повышать, поэтому часто быстро увольняются, может себе позволить мало какая компания.
Умение договариваться и аргументировать, почему надо сделать не так, а иначе, особенно с ребятами из бизнеса, тоже приходит с опытом, после десятков споров и обсуждений. Никогда нельзя забывать, что наши коллеги из бизнеса не могут знать какие там точки где не получится поставить. А это еще очень просто объяснить, обычно все намного сложнее. Как-то раз, я битый час объясняла начальнику-бэкендеру, к которому пришла за помощью ПМ, которая вообще ничего не могла понять, почему отрисовка слишком длинного списка может повлиять на производительность браузера. Ему никак не удавалось понять, в чем у меня проблема перебрать значения в массиве и вывести этот злосчастный бесконечный список, который просит ПМ. А ведь он тоже разработчик, ребята из бизнеса - люди вообще никак не связанные с разработкой, попробуйте им такое объяснить (ПМ тогда просто стояла и беспомощно хлопала глазами, мне ее был честно жаль). Тем не менее, наша задача, как разработчиков, вовремя вмешаться в задачу и умело донести, что вот так делать не надо, это будет плохо, а сделать лучше вот так. И иногда это бывает очень сложно. Мы собрали целый список подобных примеров с разборами, как и в какой ситуации объяснить ПО или ПМу, почему что-то нужно сделать так, а не иначе, ознакомиться можно тут.
Вот основные моменты, которые приходят с опытом и никак не компенсируются техническими знаниями. Конечно недостаток всех этих умений придется компенсировать компании, и понятно почему они этого делать не хотят. Время - деньги, и за наше обучение никому платить не интересно. Кто вспомнит еще примеры знаний, которые приходят в опытом, пишите в комментариях, обсудим.
Александра Шаламова
#разработчику
Чем занят руководитель?
Очевидным ответом для многих является “ничем”, так же, как и очевидно, что все проблемы связаны с руководителем, а победы общие. Я видел достаточно руководителей, которые реально очень мало вкладывались в свою работу, но обычно все несколько сложнее.
Задачи руководителя
Что на мой взгляд делает руководитель:
- добывает необходимые ресурсы для достижения результата. И тут речь обо всем: от денег до людей.
формирует цели и метрики для команд и/или проектов (детали зависят от уровня руководителя и специфики).
- занимается ростом и развитием команды, напрямую растит -1 и частично -2.
- выстраивает процесс работы в рамках своей зоны ответственности (как минимум формулирует, что должно быть и добивается того, чтобы по факту это так и работало)
- подключается к решению нестандартных проблем и ситуаций, либо когда вообще не ясно, что делать, либо когда нужна помощь организовать или договориться.
В налаженных проектах, где нет бурного роста или большого накопленного долга (тех или бизнесового), руководители могут иметь много свободного времени, при этом претензий к ним быть не может. Все работает, развитие идет согласно плану, текучка делегирована или закрыта. Прийти к такому дорогого стоит, правда потом возникнет вопрос, а что дальше, но до этого надо дойти. Я дошел до этого один раз и принял решение двигаться дальше, в новой компании, с новыми вызовами и целями.
Так же, чем дальше вы от позиции руководителя команды, тем меньше ребята в командах понимают ваш вклад и вообще знают, когда вы подключались к решению проблемы, а когда нет.
Если про загруженность говорить в проектах, где до отлаженности еще далеко, то можно на основе своего календаря и людей, которых я знаю примерно смоделировать день руководителя.
Типичный день руководителя
Есть регулярная текучка, сюда входят встречи с руководством, встречи со смежниками, обсуждения и проработка участия в разных инициативах компании и т.д. Если вы склонны посещать только необходимые мероприятия и стараетесь делегировать там, где это уместно, то, допустим, со временем ваш календарь будет занят этим на 40% (я ставлю в календарь встречи для самого себя, когда хочу уделить время какой-то задаче). Дальше, я надеюсь, вы хотите понимать, как дела обстоят в ваших проектах и командах, сюда уходит еще 20% вашего времени (это при условии, что вы активно не перестраиваете команды или проекты). Конечно постоянно нужно работать с разными запросами и проблемами от команд: перемещение людей между командами, повышения, споры между командами, участие в согласовании больших релизов, работа с целями команд и т.д. Ну допустим это еще 15% отнимет, если повезет.
Нештатные ситуации
Ну и казалось бы вот оно счастье, столько времени осталось свободного. Но дальше идет работа с нештатными ситуациями. Скажем если возьму просто прошлый день от написания статьи только по нештатным ситуациям будет такая картина за один день:
- нужно было договориться о перераспределении денег для выделения новых серверов под проекты;
убедить нескольких смежников проводить релиз так, как нужно нашей команде, потому что скорость критична;
- провести собеседование человека для усиления сопровождения, где были проблемы и надо срочно усиливаться;
- договориться о составе и размере команды под новый проект;
- убедить коллег из смежной системы поправить проблемы не по своему графику, а день в день.
Какие-то задачи приходится делать самому, в каких-то нужно найти правильных людей и свести со своими, где-то надо подпихнуть своих ребят. В общем, так оглядываешься порой и понимаешь, что рабочий день по графику то давно закончился. Понятно, что сейчас у нас на одном проекте период роста, а на втором глобальная перестройка, но моментами от этого не легче. Собственно, если есть желание делать проекты хорошо, то работа на любой позиции стороной вас не обойдет, главное быть на своем месте и получать удовольствие от процесса.
Максим Шаламов
#руководителю #разработчику
Очевидным ответом для многих является “ничем”, так же, как и очевидно, что все проблемы связаны с руководителем, а победы общие. Я видел достаточно руководителей, которые реально очень мало вкладывались в свою работу, но обычно все несколько сложнее.
Задачи руководителя
Что на мой взгляд делает руководитель:
- добывает необходимые ресурсы для достижения результата. И тут речь обо всем: от денег до людей.
формирует цели и метрики для команд и/или проектов (детали зависят от уровня руководителя и специфики).
- занимается ростом и развитием команды, напрямую растит -1 и частично -2.
- выстраивает процесс работы в рамках своей зоны ответственности (как минимум формулирует, что должно быть и добивается того, чтобы по факту это так и работало)
- подключается к решению нестандартных проблем и ситуаций, либо когда вообще не ясно, что делать, либо когда нужна помощь организовать или договориться.
В налаженных проектах, где нет бурного роста или большого накопленного долга (тех или бизнесового), руководители могут иметь много свободного времени, при этом претензий к ним быть не может. Все работает, развитие идет согласно плану, текучка делегирована или закрыта. Прийти к такому дорогого стоит, правда потом возникнет вопрос, а что дальше, но до этого надо дойти. Я дошел до этого один раз и принял решение двигаться дальше, в новой компании, с новыми вызовами и целями.
Так же, чем дальше вы от позиции руководителя команды, тем меньше ребята в командах понимают ваш вклад и вообще знают, когда вы подключались к решению проблемы, а когда нет.
Если про загруженность говорить в проектах, где до отлаженности еще далеко, то можно на основе своего календаря и людей, которых я знаю примерно смоделировать день руководителя.
Типичный день руководителя
Есть регулярная текучка, сюда входят встречи с руководством, встречи со смежниками, обсуждения и проработка участия в разных инициативах компании и т.д. Если вы склонны посещать только необходимые мероприятия и стараетесь делегировать там, где это уместно, то, допустим, со временем ваш календарь будет занят этим на 40% (я ставлю в календарь встречи для самого себя, когда хочу уделить время какой-то задаче). Дальше, я надеюсь, вы хотите понимать, как дела обстоят в ваших проектах и командах, сюда уходит еще 20% вашего времени (это при условии, что вы активно не перестраиваете команды или проекты). Конечно постоянно нужно работать с разными запросами и проблемами от команд: перемещение людей между командами, повышения, споры между командами, участие в согласовании больших релизов, работа с целями команд и т.д. Ну допустим это еще 15% отнимет, если повезет.
Нештатные ситуации
Ну и казалось бы вот оно счастье, столько времени осталось свободного. Но дальше идет работа с нештатными ситуациями. Скажем если возьму просто прошлый день от написания статьи только по нештатным ситуациям будет такая картина за один день:
- нужно было договориться о перераспределении денег для выделения новых серверов под проекты;
убедить нескольких смежников проводить релиз так, как нужно нашей команде, потому что скорость критична;
- провести собеседование человека для усиления сопровождения, где были проблемы и надо срочно усиливаться;
- договориться о составе и размере команды под новый проект;
- убедить коллег из смежной системы поправить проблемы не по своему графику, а день в день.
Какие-то задачи приходится делать самому, в каких-то нужно найти правильных людей и свести со своими, где-то надо подпихнуть своих ребят. В общем, так оглядываешься порой и понимаешь, что рабочий день по графику то давно закончился. Понятно, что сейчас у нас на одном проекте период роста, а на втором глобальная перестройка, но моментами от этого не легче. Собственно, если есть желание делать проекты хорошо, то работа на любой позиции стороной вас не обойдет, главное быть на своем месте и получать удовольствие от процесса.
Максим Шаламов
#руководителю #разработчику
Выгорание у джунов до старта работы - миф или реальность?
У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.
Во-первых, есть такое понятие, как академическое выгорание - выгорание от учебы (я вот почитала про него и поставила себе диагноз задним числом, может и у вас оно было). Большинство взрослых людей, хоть раз просыпались от кошмаров про экзамены. Какой бы нам не казалась сейчас сложной жизнь, для большинства учеба это огромный стресс. А стресс - это главный друг выгорания. Я тут вам сейчас про методы борьбы со стрессом рассказывать не буду, как-то у нас уже был такой пост.
Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.
Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.
Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.
Александра Шаламова
#разработчику #тимлиду
У каждого разработчика настает однажды такой момент, когда его все задолбало и хочется на дачу жарить шашлыки или пару недель позалипать в компьютерные игры. Ну вот кто нынче не выгорал? Но оказывается, чтобы выгореть не обязательно даже начинать работать. Пошла такая тенденция, что джуны, иногда даже без опыта работы, уже приходят на собеседование с историями о выгорании. Уже не раз слышала и от обучающихся еще разработке ребят: "что делать, помогите, три месяца учусь программированию, больше не могу...". Честно вам скажу, ребята, первая моя реакция на такое была в стиле "да что ты, сосунок, знаешь о выгорании?!". Но все не так просто. Разберемся с основными причинами, тем более, что они общие для всех.
Во-первых, есть такое понятие, как академическое выгорание - выгорание от учебы (я вот почитала про него и поставила себе диагноз задним числом, может и у вас оно было). Большинство взрослых людей, хоть раз просыпались от кошмаров про экзамены. Какой бы нам не казалась сейчас сложной жизнь, для большинства учеба это огромный стресс. А стресс - это главный друг выгорания. Я тут вам сейчас про методы борьбы со стрессом рассказывать не буду, как-то у нас уже был такой пост.
Второе, это умение организации времени. Согласитесь, что даже опытные ребята не всегда это умеют, а что говорить про тех, кто только начал. Большинство гордиться своим умением сидеть за компом не вставая по 5-8-12 часов. Признаюсь, я сама через такую проблему прошла, к счастью Максим мне помог осознать свою проблему и теперь я сажусь за задачи с будильником, иначе не умею вовремя оторваться и сделать перерыв. Даже если вам кажется, что вы можете 5 часов не вставать и не отдыхать, поверьте, ваш организм не может. Не мучайте его и тоже заведите себе будильник. Заметите как стали меньше уставать и больше и качественнее работать. По циклу работы тут нужно подбирать под себя, но по классике в "методе помидора" цикл длится пол часа: 25 минут работа и 5 перерыв. Но делать цикл больше 90 минут я бы не советовала. И учтите, что чем длиннее шаг цикла, тем дольше нужен перерыв.
Третий момент, который влияет на нас на всех, но для джунов может быть особо шокирующим, это несоответствие работы представлениям о ней. Эта тема изучается не только в ИТ, это уже известный феномен - молодые специалисты, недавно вышедшие на работу впадают в шок от всего, что на них неожиданно сваливается, и не могут справится с такими нагрузками. Один из моментов, когда высок риск смены профессии. К сожалению, образовательные учреждения не дают многих практических навыков и совершенно не знакомят молодых ребят с реальностью будущей работы. Что с этим можно сделать? Было бы здорово начинать работу постепенно, еще во время учебы. Я, на пример, начинала с фриланса (один из самых простых способов для студентов), и работа в небольшой студии после этого мне показалась отдыхом.
Вывод: да, джуны могут выгореть, есть реальные причины, которые к этому приводят. Не всегда это так, но об этом мы поговорим как-нибудь в следующий раз. А если вы подозреваете у себя выгорание, то определить его вам поможет тест Маслач, который вы найдете в этом посте. Там же написано, что делать дальше.
Александра Шаламова
#разработчику #тимлиду
Многоэтапные собеседования - зачем?
Многоэтапные собеседования бесят большинство собеседующихся и многие правда не понимают зачем это все. Самым интересным оказалось то, что ребята проводящие первый этап часто сильно недовольны, что их мнения недостаточно. Я, как всегда, поделюсь своим мнением и видением этой ситуации.
Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.
Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.
Очень часто я прихожу на последний этап и вижу ребят, которые вообще не хотят ничего делать. Мыслят в стиле: платите деньги, а я может выделю время пару задач закрыть. Конечно же дайте мне еще удаленки, конференции, дни к отпуску и т.д. А вот изучить что-то новое, взять ответственность за что-то, стараться и т.д., неее, это сложно. Они уже все узнали, все изучили, им все скучно и не интересно. Кто нанимает много, понимает о каких ребятах я говорю.
Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.
Выводы
Получилось, что-то больше похожее на обзор, чем на то, из чего можно сделать выводы, но если попробовать, то многоэтапные собеседования (на мой взгляд должно быть не больше трех) это необходимость для компаний. А чтобы на основе только вашего мнения принимали решения о наймах, повышайте свою репутацию и доверие к себе.
Максим Шаламов
#тимлиду #разработчику
Многоэтапные собеседования бесят большинство собеседующихся и многие правда не понимают зачем это все. Самым интересным оказалось то, что ребята проводящие первый этап часто сильно недовольны, что их мнения недостаточно. Я, как всегда, поделюсь своим мнением и видением этой ситуации.
Почему компании делают несколько собеседований
Для вас, как для собеседующегося, нужно понимать, что, если бы компании впихивали всех в одно собеседование, то просто бы сломали себе процесс найма, а вы бы постоянно сталкивались с переносами собеседований. Свободное время у нанимающих руководителей найти не так просто (у меня бывают недели где с 6 утра до 23 время под собеседования я найти не смогу), а с учетом большого числа отсевов на первом этапе, собирать всех в один тур будет не эффективно для компаний с большим числом открытых вакансий. Я сейчас воспринимаю такую систему без эмоций. Проще в маленьких компаниях, но там и потребность меньше, поэтому решение в один тур не редкость.
Почему руководители проверяют людей после технического собеседования
Что касается расстройства собеседующих, что их мнения недостаточно. Тут все довольно просто, брать кота в мешке никто не хочет. Пусть кандидат удовлетворяет техническим запросам компании, но намного важнее впишется ли он в вашу команду, мотивирован ли он, умеет ли работать в команде и т.д.
Очень часто я прихожу на последний этап и вижу ребят, которые вообще не хотят ничего делать. Мыслят в стиле: платите деньги, а я может выделю время пару задач закрыть. Конечно же дайте мне еще удаленки, конференции, дни к отпуску и т.д. А вот изучить что-то новое, взять ответственность за что-то, стараться и т.д., неее, это сложно. Они уже все узнали, все изучили, им все скучно и не интересно. Кто нанимает много, понимает о каких ребятах я говорю.
Как я делегирую принятия решений о найме подчиненным
Лично я очень просто подхожу к вопросу делегирования принятия решений, я хожу какое-то время с выбранными ребятам на собеседования. В начале собеседования веду я, объясняю, что и зачем я спрашиваю, как принимаю решения, что важно на какую позицию и как правильно задавать вопросы и интерпретировать ответы. Потом я хожу в режиме слушателя, проверяю все ли ребята делают правильно. Затем я перестаю ходить на собеседования, но мы проводим разборы в случае найма неудачных кандидатов, если видна проблема или непонимание, повторяем цикл. Если говорить о своем старте лидом, то в Рамблере мне просто приводили людей, такой был процесс. В Сбере уже таких проблем не было, я сам отбирал себе людей и, с учетом самых высоких требований к кандидатам, за мной другие обычно не перепроверяли.
Выводы
Получилось, что-то больше похожее на обзор, чем на то, из чего можно сделать выводы, но если попробовать, то многоэтапные собеседования (на мой взгляд должно быть не больше трех) это необходимость для компаний. А чтобы на основе только вашего мнения принимали решения о наймах, повышайте свою репутацию и доверие к себе.
Максим Шаламов
#тимлиду #разработчику
Что делать, если тебя не уважают
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающиеего ваш продукт, это будет вызывать в нем уважение. Вы же свой человек, вы хотите того же, что и он, но делаете это методами, которыми он не владеет. А чтобы он видел, что это реально приносит пользу, опять же нужно учиться правильно преподносить результаты своей работы.
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Один разработчик поведал мне одну прекрасную историю. Устроился он в новую компанию, где задачи ему приходили от владельца продукта. Получив первую свою задачу, он внимательно на нее посмотрел и понял, что данных для ее решения не хватает. Естественно, единственный человек, который мог решить его проблему был тот самый владелец продукта. Но при первой же попытке задать вопрос, мой знакомый получил жесткий ответ: "Значит так! Тебя взяли сюда работать, а не вопросы задавать. Вот иди и делай". Угадайте, кто остался виноват, что задача сделана не правильно?
Бизнес-команда любит недооценивать разработку. Они придумывают крутые фичи, знают рынок, как свои пять пальцев (обычно нет), ежедневно решают будущее продукта, а все что остается разработчику - просто сделать, что ему сказали. Ну на сколько это сложно? Конечно, история выше из ряда вон, но на бытовом уровне с неуважением со стороны бизнес-команды сталкивался практически каждый разработчик.
Есть много подходов, которые помогут вам изменить ситуацию, но мы сейчас поговорим, о самом основополагающем. Самое важное, что вам нужно, чтобы бизнес начал относится к вам более уважительно, это стать для него решением его проблем, решением, без которого он конечно же не справится. Всего-то надо стать незаменимым, тоже мне задача.
Во-первых, давайте разберем подход, который очень часто встречается среди коллег, и который тоже, как это ни странно работает - рассказывать всем, как много и усиленно ты работал, даже если ты на самом деле почти ничего не делал. Нет ли у вас такого коллеги, который постоянно ходит и рассказывает, как ему тяжело, как он работал все выходные, какую неимоверно сложную задачу ему пришлось затащить, а какие у него мешки под глазами (вот-вот смотри!)? Как ни странно, таким ребятам верят и часто относятся к ним с уважением. Все потому, то они убеждают всех, что они реально тащат неимоверный груз и очевидно всех спасают. Какую бы мелочь они не сделали - все узнают о тех усилиях, которые они приложили! Главное для них, это не попасть под опытного управленца, который знаком с таким типом людей и умеет с ним работать. Тогда им либо правда придется работать, как они рассказывают, либо довольно быстро отправиться искать другое место работы.
На самом деле, показывать бизнесу то, какую пользу вы ему приносите, очень важно для формирования уважения. Но можно это делать и иначе. Для этого надо учиться хорошо презентовать свою работу. Не только делать задачи, но и красиво преподносить их решение. Обязательно хорошо готовиться к общим встречам, особенно демонстрации результатов спринтов и релизов. Показывать, что было сделано, какие проблемы были решены, какие метрики изменились в лучшую сторону и как это положительно повлияет на ваш продукт. В общем, корректно, но во всей красе показывать, как хорошо вы работаете.
Еще один важный момент, в том числе формирующий уважение, это правильное преподнесение проблем и технических задач. Заход в бизнес с идеей потратить пару месяцев на внедрение тестов в проект "потому что надо", точно положительно не скажется на уважении к вам. Бизнес тут дело делает, а вы с какой-то очередной дикой идеей пришли, лишь бы время потратить в свое удовольствие. Важно заходить со стороны понимания важности продукта, заботы о нем и его качестве для пользователя. Если владелец продукта раз за разом будет видеть, как вы приносите идеи, улучшающие
Если хотите получать больше уважения от бизнеса, учитесь применять эти подходы. Больше про методы формирования уважения, представления своей работы и идей перед бизнесом, вы найдете в нашей документации к работе с PO и PM.
Александра Шаламова
#разработчику #тимлиду
Говнокод или ступень роста
Тему этого поста мне навеяла одна история. Знакомый начинающий разработчик пожаловался, что не может больше работать с собственным проектом, потому что там один говнокод и ему тяжело на это все смотреть, хочется все переписать сначала. Стоит ли расстраиваться из-за такой ситуации и как правильно на нее реагировать, чтобы не впасть в уныние?
Во-первых, если код написанный вами пол года назад, кажется вам говнокодом (а пол года назад не казался), то у меня для вас хорошая новость: вы не стоите на месте, вы растете и начинаете видеть свои ошибки. И это просто замечательно, и вместо того, чтобы ругать себя за плохой код, похвалите себя за быстрый рост. Такой этап происходит в любой деятельности. Вы поднимаетесь на уровень выше и начинаете видеть собственные ошибки. Намного хуже, когда этого не происходит.
Следующий момент, нужно правильно понимать свое место в компании. Зачем компания взяла начинающего специалиста? Скорее всего он стоит недорого и есть набор задач, которые не выгодно отдавать разработчикам более высокого уровня. Еще одна частая причина - вырастить разработчика под свои нужды, по своим требованиям. То есть компания наняла вас осознанно, следуя своим целям, зная, что вы будете писать код определенного уровня. Если вы справляетесь со своей работой и все довольны, значит вы реализуете цель, ради которой вас наняли. Более того, слишком быстрый рост разработчика может быть даже минусом для компании. Компания тратит ресурсы на поиск нужных людей, а они растут слишком быстро, чтобы успеть себя оправдать и уходят на более высокие позиции. Это проблема. Многие компании предпочитаются, чтобы младший разработчик оставался младшим разработчиком навсегда.
Теперь собственно о говнокоде и что с ним делать. Здорово, если у вас в компании и отделе есть определенные стандарты, по которым проводится улучшение кода. Если это так, то просто следуйте этим правилам и постепенно улучшайте старый код. Если таких стандартов нет, то стоит их разработать (пишите в комментариях, если нужен пост с примером, как это можно сделать). В любом случае, прежде, чем что-то менять, задайте себе следующие вопросы:
- Выполняет ли код работу, которую должен?
- Есть ли ошибки в этом коде, которые мешают его выполнению?
- Достаточно ли эффективно работает этот код? Если сделать эффективнее, что-то изменится в лучшую сторону?
- Есть ли сложность в понимании этого кода вами или вашими коллегами?
- Есть ли задачи, выполнению которых мешает текущая структура этого кода?
И если вы видите, что код работает хорошо, его легко понять, он ничему не мешает и пользователь никак не заметит ваших улучшений, то спросите себя, а какую цель вы преследуете изменяя работающий код? И если ответа кроме, как улучшить свое настроение, потому что код вам визуально не нравится, нет, то займитесь лучше другими задачами, за которые вам платит компания. Всегда нужно помнить, что у любой задачи должна быть цель, в том числе у улучшения кода.
Александра Шаламова
#джуну #разработчику
Тему этого поста мне навеяла одна история. Знакомый начинающий разработчик пожаловался, что не может больше работать с собственным проектом, потому что там один говнокод и ему тяжело на это все смотреть, хочется все переписать сначала. Стоит ли расстраиваться из-за такой ситуации и как правильно на нее реагировать, чтобы не впасть в уныние?
Во-первых, если код написанный вами пол года назад, кажется вам говнокодом (а пол года назад не казался), то у меня для вас хорошая новость: вы не стоите на месте, вы растете и начинаете видеть свои ошибки. И это просто замечательно, и вместо того, чтобы ругать себя за плохой код, похвалите себя за быстрый рост. Такой этап происходит в любой деятельности. Вы поднимаетесь на уровень выше и начинаете видеть собственные ошибки. Намного хуже, когда этого не происходит.
Следующий момент, нужно правильно понимать свое место в компании. Зачем компания взяла начинающего специалиста? Скорее всего он стоит недорого и есть набор задач, которые не выгодно отдавать разработчикам более высокого уровня. Еще одна частая причина - вырастить разработчика под свои нужды, по своим требованиям. То есть компания наняла вас осознанно, следуя своим целям, зная, что вы будете писать код определенного уровня. Если вы справляетесь со своей работой и все довольны, значит вы реализуете цель, ради которой вас наняли. Более того, слишком быстрый рост разработчика может быть даже минусом для компании. Компания тратит ресурсы на поиск нужных людей, а они растут слишком быстро, чтобы успеть себя оправдать и уходят на более высокие позиции. Это проблема. Многие компании предпочитаются, чтобы младший разработчик оставался младшим разработчиком навсегда.
Теперь собственно о говнокоде и что с ним делать. Здорово, если у вас в компании и отделе есть определенные стандарты, по которым проводится улучшение кода. Если это так, то просто следуйте этим правилам и постепенно улучшайте старый код. Если таких стандартов нет, то стоит их разработать (пишите в комментариях, если нужен пост с примером, как это можно сделать). В любом случае, прежде, чем что-то менять, задайте себе следующие вопросы:
- Выполняет ли код работу, которую должен?
- Есть ли ошибки в этом коде, которые мешают его выполнению?
- Достаточно ли эффективно работает этот код? Если сделать эффективнее, что-то изменится в лучшую сторону?
- Есть ли сложность в понимании этого кода вами или вашими коллегами?
- Есть ли задачи, выполнению которых мешает текущая структура этого кода?
И если вы видите, что код работает хорошо, его легко понять, он ничему не мешает и пользователь никак не заметит ваших улучшений, то спросите себя, а какую цель вы преследуете изменяя работающий код? И если ответа кроме, как улучшить свое настроение, потому что код вам визуально не нравится, нет, то займитесь лучше другими задачами, за которые вам платит компания. Всегда нужно помнить, что у любой задачи должна быть цель, в том числе у улучшения кода.
Александра Шаламова
#джуну #разработчику