На практике работодатель зарабатывает все то, что не доплатил работнику. Поэтому в ход идет все что угодно, чтобы увеличить разницу между прибылью и затратами.
А еще на практике работодатель это не человек, это организация с своими не всегда логичными правилами. Например, бюджет на найм - один, а на повышения - другой, и сильно ограниченный. И начальнику бывает проще не дать повышения, человек уйдет, а потом нанять на еще бОльшие деньги с рынка. Потому что повышение сотрудника ему не согласуют. А найм по причине замены - другая история.
10 разработчиков, несколько проектов, 20% времени на управление, остальное — код, пресейлы, обучение и личные цели. Звучит как типичный день teamlead’а, правда?
Нет, не звучит.
Извините, но так просто не бывает. С 10-ю разработчиками времени писать код не будет. Максимум- ревью, и то не всего. Времени на обучение людей тоже не хватит. Учитывая что вам еще пресейлами надо заниматься.
20% на управление? На пообщаться с разрабами, со стейками, чего-то там запланировать, задачек там нарезать, поставить, проконтролировать выполнение. Так не бывает. 70% на управление - норм. 50% - ну.... если у вас есть пара синьоров на которых вы делегируете половину своей работы. И скорее всего это не ваш случай, т.к. вы описываете себя как единую входную точку.
Мне нравится принцип "ты мне, я - тебе". Пришлось переработать - ок. Но потом если днем надо куда-то отойти - то я так и делаю. И ни у кого никаких вопросов.
Обычно мне удается договориться. Хотя не всегда.
Была у меня недавно одна продакт, которая закатила истерику по поводу того, что в 12-30 я не был на рабочем месте. Я эскалировал выше, и сказал: хотите формализма? ОК. Буду работать строго 9-18 с перерывом в 13. Но учтите, что теперь продукт не будет обновляться в принципе, потому что в релизное окно (которое согласовано только для нерабочих часов) я работать не буду. Ну или откатываем ситуацию, забываем этот скандал, и все будет как раньше, неформально, с гибкими рабочими часами.
Однажды он даже отчитал меня за «слишком долгий» обеденный перерыв, который длился 62 минуты вместо положенных 60
При малейшем опоздании (даже на 2 минуты) он писал мне сообщение: «Где ты? Почему не на работе?»
Может существовать в одной вселенной с этим:
Я всё чаще стал задерживаться допоздна, работать по выходным, но результат всё равно не устраивал Александра
Если у нас гибкий график, и приходится сидеть по вечерам, то та же логика касается, скажем, обедов.
Если обед четко 60 минут и ни минутой больше, значит, 18:01 комп гастится, на рабочие телефонные звонки и на сообщения в мессенджере ответ будет завтра не ранее 09:00
Если уж решил колоться но продолжать есть кактус, то в эту корпоративную игру можно играть вдвоем.
Обновил статью, приведя конкретный пример из жизни.
Мой позиция в том, что массовое АйТи - это не про соцсети. В соцсетях все очень классно работает с микро-сервисами и микро-фронтами. Классно, но абсолютно бесполезно для 99%+ разработчиков. Потому что 99% разработчиков в РФ в аджайл-командах такими вещами не занимаются. Хорошо это или плохо, они пишут что-то под локальные потребности бизнеса. И это что-то выполняет конкретную бизнес-задачу. Оно является либо частью системы, либо очень маленькой системой. В обоих случаях еще мельче дробить это "что-то" редко бывает целесообразно. Нагрузка на это "что-то" маленькая, людей выделяют мало.
А канонические примеры (тот же Амазон, или запрещенный Фейсбук) - это десятки тыщ инженеров. Там только над управлением профиля работают такие толпы, что их приходится делить на отделы и выдавать им крохотный кусочек функционала.
Прощу прощения, возможно, у меня плохо получается выразить простую мысль:
Многие смотрят на подходы тех же соцсетей или Нетфликса, и пытаются применить у себя на работе. Например, пытаются сделать какой-то генератор отчетов в виде десятка сервисов. Задача была на три месяца на одного разработчика и половину тестировщика, а превращается на три месяца на двух разработчиков, тестировщика и девопса.
Я так и не понял, где в статье описывается что всё-таки такое нано сервис
Исправляюсь!
Дано: написать сервис, который берет из бэк-офиса данные о продажах и отправляет операторам электронных касс. Операторы печатают электронные чеки. Пример оператора: Атол (не реклама)
Из-за очень настойчивого мнения руководителя (на прошлой работе) принято решение писать на "микро-сервисах". Микро-сервис "Ядра", преобразующий данные бэк-офиса в нужный формат и балансирующий нагрузку между микро-сервисами адаптеров к операторам.
Теория:
Модно и молодежно. Это же "микро-сервисы"
Максимальная гибкость: можно подключать и отключать операторов без даунтайма ядра.
Масштабируемость
Разные сервисы можно раскидать по разным разрабам
Практика:
Х2 трудозатрат на реализацию. Потому что оверхед на взаимодействие между сервисами, трейсинг и т.д.
Х3 затрат на поддержку. Потому что вместо одного "монолита" получили ряд нано-сервисов. С алертингом, мониторингом, трейсингом, логами. И разбором инцидентов от бухгалтерии вида: "вы опять чек пролюбили"
Полное отсутствие необходимости горизонтального масштабирования. В пике оно кушало пару сотен мб оперативки и 10% ядра процессора. Узкое место - скорость онлайн касс, а не сервисов.
Все заняло у меня 5 недель на разработку и 2 недели на ОПЭ. Привлекать команду для такого микро-проекта избыточно. Более того, в виде одного сервиса реализация была бы в 1.5 раза быстрее.
Вывод: получились нано-сервисы с завышенной стоимостью владения.
Не надо так делать.
Правильно было бы сделать в виде одного микро-сервиса, со своим доменом: печать чеков.
Из-за таких вот определений мир наполнили нано-сервисы: рой сильно-связанных сервисов, которые никак не ложатся ни на домен, ни на орг. структуру.
Приходишь в компанию, а там 30 команд пилят 1500 сервисов. Да еще гордятся этим. Чтобы хоть как-то начать в этом ориентироваться, надо потратить полгода и километр нервов.
Мне удобна вещь которая принадлежит мне. За скромные деньги (+- чашка кофе) покупаю китайский картридж, закрывающий потребности семьи в печати на полгода. Не совсем понимаю, зачем платить в 6 раз дороже. Картридж закончился - беру из ящика запасной, и тут же делаю заказ следующего.
Ах да, раз в год надо лезть рукой куда-то вглубь принтера чтобы нажать на кнопку сброса счетчика страниц. А то эта немецкая техника отказывается принимать китайские расходники. Видимо, исключительно из-за заботы обо мне. Это бесит, но придает уверенности в том, что я все делаю правильно.
Ну не скажите, регулярно пользуюсь. Перекинуть какие-то объемы между двумя компами, один из который - корпоративный. С кучей ограничений, в т.ч. на скачивания из облака.
А как эта гипотеза сочетается с темной материей и ускоренным расширением Вселенной?
Если мы внутри черной дыры, то она вместе со своим содержимым должна ускоренно расширятся. Что кажется странным, ведь содержимое черной дыры падает к центру, а не наоборот.
Отвалилась - это понятно. Но непонятно как воспринимать этот факт. Это плохо? Или не важно? Было бы хуже, если бы отвалилось раньше и какие вообще в связи с этим риски? Вон у одного шаттла как-то тоже кусок теплоизоляции отвалился...
Что сделано/запланировано, чтобы впредь не отваливалось?
Пора НЛО добавить еще один пункт "Сгенерировано нейросетью" в окошко
"Укажите причину минуса, чтобы автор поработал над ошибками"
В теории все очень красиво.
На практике работодатель зарабатывает все то, что не доплатил работнику. Поэтому в ход идет все что угодно, чтобы увеличить разницу между прибылью и затратами.
А еще на практике работодатель это не человек, это организация с своими не всегда логичными правилами. Например, бюджет на найм - один, а на повышения - другой, и сильно ограниченный. И начальнику бывает проще не дать повышения, человек уйдет, а потом нанять на еще бОльшие деньги с рынка. Потому что повышение сотрудника ему не согласуют. А найм по причине замены - другая история.
А чем вас эта не устраивает: "Cracking the coding interview"?
Очевидно же! Будет другой интервьюер.
Нет, не звучит.
Извините, но так просто не бывает. С 10-ю разработчиками времени писать код не будет. Максимум- ревью, и то не всего. Времени на обучение людей тоже не хватит. Учитывая что вам еще пресейлами надо заниматься.
20% на управление? На пообщаться с разрабами, со стейками, чего-то там запланировать, задачек там нарезать, поставить, проконтролировать выполнение. Так не бывает. 70% на управление - норм. 50% - ну.... если у вас есть пара синьоров на которых вы делегируете половину своей работы. И скорее всего это не ваш случай, т.к. вы описываете себя как единую входную точку.
А вот если взглянуть на восточную рекламу (корейская, японская , китайская) - там все наоборот.
Так что эти выводы неверны как минимум для половины населения Земли
Аналогично, коллега )
Нас развели по классике:
Ну вот, кто везет - на том и едут.
Мне нравится принцип "ты мне, я - тебе". Пришлось переработать - ок. Но потом если днем надо куда-то отойти - то я так и делаю. И ни у кого никаких вопросов.
Обычно мне удается договориться. Хотя не всегда.
Была у меня недавно одна продакт, которая закатила истерику по поводу того, что в 12-30 я не был на рабочем месте. Я эскалировал выше, и сказал: хотите формализма? ОК. Буду работать строго 9-18 с перерывом в 13. Но учтите, что теперь продукт не будет обновляться в принципе, потому что в релизное окно (которое согласовано только для нерабочих часов) я работать не буду. Ну или откатываем ситуацию, забываем этот скандал, и все будет как раньше, неформально, с гибкими рабочими часами.
Начальство выбрало второй вариант ))
Непонятно, как вот это:
Может существовать в одной вселенной с этим:
Если у нас гибкий график, и приходится сидеть по вечерам, то та же логика касается, скажем, обедов.
Если обед четко 60 минут и ни минутой больше, значит, 18:01 комп гастится, на рабочие телефонные звонки и на сообщения в мессенджере ответ будет завтра не ранее 09:00
Если уж решил колоться но продолжать есть кактус, то в эту корпоративную игру можно играть вдвоем.
Кажется, в начале статьи нет определения кто же такой тех лид и чем он конкретно занимается.
А раз нет границ зон ответственности, то и возникают казусы вроде прибегающих дизайнеров.
Ничего кроме правды - это тоже может быть сильный ход.
Вот как я первый раз устроился тимлидом:
На обесе рассказал, что работал синьором, ставил задачи двум коллегам, контролировал, собирал результаты их труда вместе, релизил.
Интервьюер спосил: а, так ты управлял?
Я говорю не, у них же другой начальник. Я просто синьор, я отвечал за кусок системы.
Интервьюер: а, так ты еще и скромный. А у нас тут позиция лида тоже имеется. Хочешь?
Обновил статью, приведя конкретный пример из жизни.
Мой позиция в том, что массовое АйТи - это не про соцсети. В соцсетях все очень классно работает с микро-сервисами и микро-фронтами. Классно, но абсолютно бесполезно для 99%+ разработчиков. Потому что 99% разработчиков в РФ в аджайл-командах такими вещами не занимаются. Хорошо это или плохо, они пишут что-то под локальные потребности бизнеса. И это что-то выполняет конкретную бизнес-задачу. Оно является либо частью системы, либо очень маленькой системой. В обоих случаях еще мельче дробить это "что-то" редко бывает целесообразно. Нагрузка на это "что-то" маленькая, людей выделяют мало.
А канонические примеры (тот же Амазон, или запрещенный Фейсбук) - это десятки тыщ инженеров. Там только над управлением профиля работают такие толпы, что их приходится делить на отделы и выдавать им крохотный кусочек функционала.
Прощу прощения, возможно, у меня плохо получается выразить простую мысль:
Многие смотрят на подходы тех же соцсетей или Нетфликса, и пытаются применить у себя на работе. Например, пытаются сделать какой-то генератор отчетов в виде десятка сервисов. Задача была на три месяца на одного разработчика и половину тестировщика, а превращается на три месяца на двух разработчиков, тестировщика и девопса.
Исправляюсь!
Дано: написать сервис, который берет из бэк-офиса данные о продажах и отправляет операторам электронных касс. Операторы печатают электронные чеки. Пример оператора: Атол (не реклама)
Из-за очень настойчивого мнения руководителя (на прошлой работе) принято решение писать на "микро-сервисах". Микро-сервис "Ядра", преобразующий данные бэк-офиса в нужный формат и балансирующий нагрузку между микро-сервисами адаптеров к операторам.
Теория:
Модно и молодежно. Это же "микро-сервисы"
Максимальная гибкость: можно подключать и отключать операторов без даунтайма ядра.
Масштабируемость
Разные сервисы можно раскидать по разным разрабам
Практика:
Х2 трудозатрат на реализацию. Потому что оверхед на взаимодействие между сервисами, трейсинг и т.д.
Х3 затрат на поддержку. Потому что вместо одного "монолита" получили ряд нано-сервисов. С алертингом, мониторингом, трейсингом, логами. И разбором инцидентов от бухгалтерии вида: "вы опять чек пролюбили"
Полное отсутствие необходимости горизонтального масштабирования. В пике оно кушало пару сотен мб оперативки и 10% ядра процессора. Узкое место - скорость онлайн касс, а не сервисов.
Все заняло у меня 5 недель на разработку и 2 недели на ОПЭ. Привлекать команду для такого микро-проекта избыточно. Более того, в виде одного сервиса реализация была бы в 1.5 раза быстрее.
Вывод: получились нано-сервисы с завышенной стоимостью владения.
Не надо так делать.
Правильно было бы сделать в виде одного микро-сервиса, со своим доменом: печать чеков.
Мне этот жанр тоже нравится.
Дальше обычно следует: "что вы знаете про нашу компанию?", "кем вы себя видите [в нашей компании] через 5 лет?"
Из-за таких вот определений мир наполнили нано-сервисы: рой сильно-связанных сервисов, которые никак не ложатся ни на домен, ни на орг. структуру.
Приходишь в компанию, а там 30 команд пилят 1500 сервисов. Да еще гордятся этим. Чтобы хоть как-то начать в этом ориентироваться, надо потратить полгода и километр нервов.
Мне удобна вещь которая принадлежит мне. За скромные деньги (+- чашка кофе) покупаю китайский картридж, закрывающий потребности семьи в печати на полгода. Не совсем понимаю, зачем платить в 6 раз дороже. Картридж закончился - беру из ящика запасной, и тут же делаю заказ следующего.
Ах да, раз в год надо лезть рукой куда-то вглубь принтера чтобы нажать на кнопку сброса счетчика страниц. А то эта немецкая техника отказывается принимать китайские расходники. Видимо, исключительно из-за заботы обо мне. Это бесит, но придает уверенности в том, что я все делаю правильно.
Т-сссс!
Вообще-то блочат, но у меня почему-то досуп остался. И я все забываю дойти до СБ чтобы об этом доложить.
Ну не скажите, регулярно пользуюсь. Перекинуть какие-то объемы между двумя компами, один из который - корпоративный. С кучей ограничений, в т.ч. на скачивания из облака.
А как эта гипотеза сочетается с темной материей и ускоренным расширением Вселенной?
Если мы внутри черной дыры, то она вместе со своим содержимым должна ускоренно расширятся. Что кажется странным, ведь содержимое черной дыры падает к центру, а не наоборот.
Отвалилась - это понятно. Но непонятно как воспринимать этот факт. Это плохо? Или не важно? Было бы хуже, если бы отвалилось раньше и какие вообще в связи с этим риски? Вон у одного шаттла как-то тоже кусок теплоизоляции отвалился...
Что сделано/запланировано, чтобы впредь не отваливалось?