Так а зачем решать менее важнве проблемы первее более важных?
У меня работа команды заблокирована - пойду обсужу бэклог на сдедующий квартал с продактом.
У меня проект не собирается - пойду текст на кнопке поправлю.
У меня человек собрался увольняться - пойду помогу соседней команде с багфиксингом.
Где тут логика?
Бывает иногда такое, что кому-то нужна ваша помощь в пустяковом деле, он её ждёт, но вы всегда заняты "более важными делами".
Тут одно из двух - возможно, действительно другие дела более важны, и тогда делать надо их. Либо это дело только кажется неважным, но на самом деле важное, и тогда ему тоже стоит уделить внимание.
Когда становишься лидом, довольно быстро понимаешь, что чтобы помочь всем и сделать всё красиво, нужно бесконечное количество времени. У вас его нет, значит вы гарантированно кому-то откажете в помощи и никогда не решите их вопрос. Физику не обманешь. От того, что вы вставите какое-то дело между другими двумя, вы не сделаете эти три дела за время двух. Просто несделанным останется не это дело, а какое-то другое.
Что бы вы выбрали - чтобы у вас текст в меню был с ошибкой, или чтобы меню не отображалось вовсе?
Как раз наоборот - чтобы сделать хэш-таблицу без багов и косяков производительности (если вы конечно не делаете это в 25-й раз или не перепечатываете из книжки), нужно очень хорошо и внимательно подумать, написать много тестов, в том числе и на производительность. За 2 часа это физически не сделать.
Даже в стандартных библиотеках периодически находят косяки в реализации структур, хотя к их написанию и тестированию приложено на порядки больше ресурса.
Вы учитываете "эффект учителя"? Это когда вы 25 лет даёте всем одну и ту же задачу, уже 200 раз проверяли её решение, и знаете все места, где можно накосячить. И вам начинает казаться, что там же всё очевидно, и "я сам могу за час сесть и написать", и "как можно было допустить тут такую ошибку, это надо быть совсем некомпетентным".
Сам попадал в такое искажение. Чтобы из него выбраться, есть 2 хороших рецепта:
Дайте эту задачку своим друзьям/коллегам, которых вы считаете компетентными и кто ещё её не решал. Удивитесь, как много из них вы бы отсеяли.
Попробуйте каждому соискателю давать разные задачи на разные структуры. Вам будет, возможно, гораздо сложней, зато будет лучше ощущаться, сколько реально ресурсов надо на задачу.
Говорят, что большинство разработчиков, уже работающих в компании, не смогут пройти собеседование на свою же позицию. И я бы не сказал, что дело тут в их поголовной некомпетентности.
Возможно, имеется в виду среднее. Например, если вы бегаете 1 раз в неделю, то 700/7=100. То есть вы добавляете 100ккал потребления, а не 700. Это и есть 5%.
Если вы бегаете каждый день по часу, то вы к сожалению не средний человек. Но безусловно такие люди есть. Некоторые профессиональные спортсмены жгут по 2000ккал в день чисто тренировками.
Приходилось работать с QA fullstack и знаком с опытом многих коллег, у кого они есть в команде. Можете раскрыть, в чём их мифичность?
Понимаю, что есть более узкие специализации, но не везде подходят отдельные автоматизатор и ручник, т. к. это 2 разных человека, для небольшой команды это обычно нерентабельно.
Очень похоже на то, как работают фулстек-разработчики: либо для экономии ресурса берут одного разработчика, который может делать и фронт и бэк, либо вся команда состоит из таких же фулстеков.
Насколько я знаю, это позволяет конструктивно закрывать потребности в некоторых командах, да и самим фулстекам так работать часто нравится - не все обязательно хотят быть чистыми бэкендерами или писать только фронт. То есть это вин-вин и для работника, и для компании/команды.
Это не continuous delivery, это continuous integration.
Имел в виду всё-таки continuous delivery (подробнее раз, подробнее два), хотя там пожалуй легко было понять не так. Идея в том, что классно иметь релиз сервиса по клику в любое время дня и ночи, или полностью автоматический релиз на каждый коммит.
Вы уверены, что в команде всем разработчикам не всё равно, что там попадет в production? Уверены, что так будет всегда?
Если кому-то у меня в команде станет всё равно, что попадает в прод, это будет значить, что я как тимлид не справился со своими прямыми обязанностями. Я пожалуй сгорю от стыда, в первую очередь перед собой.
В общем, это очень ненормальная ситуация для команды нашего типа, очень много вещей должно пойти не так, чтобы кто-то начал так относиться.
Поэтому ваш опыт должен показать, можно без него обойтись, или нет
Да, пожалуй. Наш показал, что мы обойтись можем, но в долгосрок хорошо бы иметь хотя бы небольшой ресурс своего fullstack QA, хотя бы 0.25 ставки. И для команды, и для проекта это будет оптимально в долгосрок.
Хорошо, что в конечном итоге вы решили оставить тестировщика. Другими словами, с чего начали, к тому и вернулись
Наша жизнь без QA помогла нам лучше, конкретнее понять нашу потребность и получить много нового опыта. Мы теперь уже не те, что раньше. По-другому смотрим на обеспечение качества, участвуя всей командой. Больше понимаем в этом самом качестве после такой продолжительной фокусировки на нём. Лучше понимаем, зачем нам QA, чего мы ждём от человека в этой роли.
Так что на мой взгляд мы сделали несколько шагов вперёд, и очень классно, что теперь это часть нашего опыта.
Тут такая штука. Не ошибается тот, кто ничего не делает. Если пробовать что-то менять, то всегда есть риск допустить ошибки, что-то ухудшить или даже сломать.
Можно жить по принципу "работает - не трогай", но в долгосрок это превращает команду и проект в болото и легаси, если не реагировать на постоянные изменения внешней среды. Из такого болота потом сложно вылезти, и конкурентность сильно падает, изменения становятся долгими и дорогими.
Некоторые крупные компании следуют принципу "move fast and break things". Да, это несёт риски, и клиентам конечно не нравится, когда качество страдает, но и альтернатива в виде проигрыша конкурентам и закрытия бизнеса не радует. Как всегда, где-то посередине стоит искать баланс, подходящий для вашей команды.
В Gradle можно погрузиться, достичь просветления и творить чудеса.
Вот только остальная команда потом офигевает с написанных портянок, где всё вперемешку и творится какая-то магия, которую никто кроме автора не понимает. А чтобы что-то поменять, надо посидеть и сначала разобраться, что там за хрень вообще происходит.
По моему опыту нестрогость подхода в сочетании с кучей возможностей делает Gradle похожим скорее на Javascript в его плохих проявлениях. Maven же даёт чёткую структуру и правила, и не позволяет писать внутри себя скрипты (без откровенных костылей), всё описывается декларативно. Конфиги Maven может поддерживать и изменять любой программист в команде, там не образуется легаси.
Это не говоря о том, что очень тормознуто работает подсветка синтаксиса и выпадающие подсказки по коду, особенно если писать билд файл на котлине. Несколько десятков секунд для выпадающей подсказки - так удобно работать не получится.
У Maven конечно свои минусы в виде многословности, часто странной документации. Плюс Gradle классно интегрируется с IDE для сборки проектов.
Ниже показал, что запрос автора оно спокойно выполняет. Предлагаю вам получше присмотреться к ChatGPT - это практически революция. Она действительно делает вещи, которые прямо сегодня кажутся невероятными.
И хоть "мозгов" у неё ещё не столько же как у нас с вами, но это как в анекдоте:
Идёт мужик по улице, видит сидит дед и с собакой в шахматы играет. Мужик офигевая говорит:
Если полагаться на краткосрочную аренду то надо слишком много зарабатывать. Тут никакая миграция в страну с низким уровнем жизни не поможет.
Мне зарплата в 2500$ уже позволяла снимать жильё на airbnb на несколько дней, на пару недель, на месяц. За 1000$ снимал большую квартиру в центре Стамбула. Вроде бы многим в IT такое доступно, а если вы с партнером работаете удаленно оба, то всё ещё проще.
Сейчас цены на аренду в популярных у россиян странах выросли а разы, а раньше можно было в прошлом году снимать в Тбилиси за 300$ почти в центре. То же самое и про соседние страны.
Когда спадёт ажиотаж на рынке, снова будет дешевле. Но даже сейчас вы за 1000$ снимете очень много где.
Не понимаю, зачем обязательно нужно "слишком много зарабатывать", это совсем не космические деньги.
И да, почта всегда работаю из жилого дома - из своей квартиры или со съемного жилья. Изредка - из хостелов или отелей. В коворкинги не хожу, там обычно не так комфортно.
В офисе был 1 день в этом году, и ходить туда каждый день совсем не хочется.
Преимущество асинхронного типа связи в том, что запрос клиента обрабатывается сразу, в то время, как при синхронной модели вся обработка выполняется одновременно. Поэтому синхронный способ взаимодействия лучше не использовать в рамках исходной операции «запрос-ответ».
Статья для статьи?
Как человек, который с этим всем работает, могу сказать, что смысл из статьи вычленить очень сложно, и если он в ней и был когда-то (вероятно в каком-то оригинале), то теперь по большинству покинул её.
Прошу прощения, если я неправ или обижаю автора, но как будто бы написал человек, который не понимает о чём пишет. Попробуйте дать прочитать 1-2 знакомым, фидбэк от них легко позволит сделать текст лучше.
Это очень близко, но по-моему не совсем то же самое.
Если у вас есть тимлид, техлид, продакт менеджер, аналитик, то задача всех этих людей — взять на себя часть экспертизы и ответственности. Каждый из них должен быть экспертом в своей более узкой области, а разработчик — в своей.
Тимлид пытается ставить понятные задачи с нужной информацией и достижимым результатом, аналитик — дать информацию о бизнес-процессах и фичах, продакт — об ориентации продукта и том, как фичу полезнее сделать для бизнеса, техлид — обсудить векторы решения задачи.
Всё это помогает команде разработчиков сделать свою работу хорошо.
Так вот, синьор разработчик частично может потянуть все эти роли.
Но, во-первых, только частично. Нельзя быть всем и сразу, и делать это лучше, чем все вышеперечисленные люди вместе взятые.
А во-вторых, если все эти люди присутствуют в компании, то делать эту работу за них — это сделать только хуже для компании. Принимать свои собственные решения в обход аналитика, тимлида и прочих — это значит сделать хуже. Тут думаю понятно почему.
Конечно, если в команде нет кого-то из вышеперечисленных людей (а то и всех), то синьор может справляться сам. Но в средних и больших продуктах это скорее всего тупиковый путь развития, не масштабируется.
Тогда всё нормально, можно выгорать :)
Если серьёзно, то психолог в штате — звучит классно, я б попробовал. Только очень хочется верить, что это не как школьные психологи, которые вроде бы и есть, но не сильно помогают.
Никакая, как и у 99% айтишников, которые ищут работу или нанимают :)
В любом случае, текст выше — это просто компиляция моего опыта, который мне показался может быть немного ценным для кого-то. А ваш фидбэк в комментах ценен для меня.
Когда долго варишься в какой-то области, начинает казаться, что все знают то, что знаешь ты, что всё очевидно. Но как показывает практика, это не так. Кто-то ещё не дошёл до чего-то, что понятно мне. А кто-то имеет опыт, противоположный моему. И он может прийти в статью и своим комментарием открыть и для меня что-то новое.
Считайте, что это такой обоюдный обмен опытом, мнениями и знаниями. С работой психолога это всё имеет мало общего.
Под фреймфорком автор имел в виду не технический фреймворк, который для написания кода, а процессный - канбан например.
Так а зачем решать менее важнве проблемы первее более важных?
У меня работа команды заблокирована - пойду обсужу бэклог на сдедующий квартал с продактом.
У меня проект не собирается - пойду текст на кнопке поправлю.
У меня человек собрался увольняться - пойду помогу соседней команде с багфиксингом.
Где тут логика?
Бывает иногда такое, что кому-то нужна ваша помощь в пустяковом деле, он её ждёт, но вы всегда заняты "более важными делами".
Тут одно из двух - возможно, действительно другие дела более важны, и тогда делать надо их. Либо это дело только кажется неважным, но на самом деле важное, и тогда ему тоже стоит уделить внимание.
Когда становишься лидом, довольно быстро понимаешь, что чтобы помочь всем и сделать всё красиво, нужно бесконечное количество времени. У вас его нет, значит вы гарантированно кому-то откажете в помощи и никогда не решите их вопрос. Физику не обманешь. От того, что вы вставите какое-то дело между другими двумя, вы не сделаете эти три дела за время двух. Просто несделанным останется не это дело, а какое-то другое.
Что бы вы выбрали - чтобы у вас текст в меню был с ошибкой, или чтобы меню не отображалось вовсе?
Тимлид как CAP-система? :)
Статью тогда нужно было назвать "Применение QoS и реверс-проксирования трафика для повышения производительности
каналатимлида"Можно подробнее про то, как комментарии позволяют накрутить карму? Одно с другим никак не связано же, или я чего-то не знаю?
Как раз наоборот - чтобы сделать хэш-таблицу без багов и косяков производительности (если вы конечно не делаете это в 25-й раз или не перепечатываете из книжки), нужно очень хорошо и внимательно подумать, написать много тестов, в том числе и на производительность. За 2 часа это физически не сделать.
Даже в стандартных библиотеках периодически находят косяки в реализации структур, хотя к их написанию и тестированию приложено на порядки больше ресурса.
Вы учитываете "эффект учителя"? Это когда вы 25 лет даёте всем одну и ту же задачу, уже 200 раз проверяли её решение, и знаете все места, где можно накосячить. И вам начинает казаться, что там же всё очевидно, и "я сам могу за час сесть и написать", и "как можно было допустить тут такую ошибку, это надо быть совсем некомпетентным".
Сам попадал в такое искажение. Чтобы из него выбраться, есть 2 хороших рецепта:
Дайте эту задачку своим друзьям/коллегам, которых вы считаете компетентными и кто ещё её не решал. Удивитесь, как много из них вы бы отсеяли.
Попробуйте каждому соискателю давать разные задачи на разные структуры. Вам будет, возможно, гораздо сложней, зато будет лучше ощущаться, сколько реально ресурсов надо на задачу.
Говорят, что большинство разработчиков, уже работающих в компании, не смогут пройти собеседование на свою же позицию. И я бы не сказал, что дело тут в их поголовной некомпетентности.
Возможно, имеется в виду среднее. Например, если вы бегаете 1 раз в неделю, то 700/7=100. То есть вы добавляете 100ккал потребления, а не 700. Это и есть 5%.
Если вы бегаете каждый день по часу, то вы к сожалению не средний человек. Но безусловно такие люди есть. Некоторые профессиональные спортсмены жгут по 2000ккал в день чисто тренировками.
Привет, спасибо за такой объёмный комментарий!
Приходилось работать с QA fullstack и знаком с опытом многих коллег, у кого они есть в команде. Можете раскрыть, в чём их мифичность?
Понимаю, что есть более узкие специализации, но не везде подходят отдельные автоматизатор и ручник, т. к. это 2 разных человека, для небольшой команды это обычно нерентабельно.
Очень похоже на то, как работают фулстек-разработчики: либо для экономии ресурса берут одного разработчика, который может делать и фронт и бэк, либо вся команда состоит из таких же фулстеков.
Насколько я знаю, это позволяет конструктивно закрывать потребности в некоторых командах, да и самим фулстекам так работать часто нравится - не все обязательно хотят быть чистыми бэкендерами или писать только фронт. То есть это вин-вин и для работника, и для компании/команды.
Имел в виду всё-таки continuous delivery (подробнее раз, подробнее два), хотя там пожалуй легко было понять не так. Идея в том, что классно иметь релиз сервиса по клику в любое время дня и ночи, или полностью автоматический релиз на каждый коммит.
Если кому-то у меня в команде станет всё равно, что попадает в прод, это будет значить, что я как тимлид не справился со своими прямыми обязанностями. Я пожалуй сгорю от стыда, в первую очередь перед собой.
В общем, это очень ненормальная ситуация для команды нашего типа, очень много вещей должно пойти не так, чтобы кто-то начал так относиться.
Да, пожалуй. Наш показал, что мы обойтись можем, но в долгосрок хорошо бы иметь хотя бы небольшой ресурс своего fullstack QA, хотя бы 0.25 ставки. И для команды, и для проекта это будет оптимально в долгосрок.
Наша жизнь без QA помогла нам лучше, конкретнее понять нашу потребность и получить много нового опыта. Мы теперь уже не те, что раньше. По-другому смотрим на обеспечение качества, участвуя всей командой. Больше понимаем в этом самом качестве после такой продолжительной фокусировки на нём. Лучше понимаем, зачем нам QA, чего мы ждём от человека в этой роли.
Так что на мой взгляд мы сделали несколько шагов вперёд, и очень классно, что теперь это часть нашего опыта.
Тут такая штука. Не ошибается тот, кто ничего не делает. Если пробовать что-то менять, то всегда есть риск допустить ошибки, что-то ухудшить или даже сломать.
Можно жить по принципу "работает - не трогай", но в долгосрок это превращает команду и проект в болото и легаси, если не реагировать на постоянные изменения внешней среды. Из такого болота потом сложно вылезти, и конкурентность сильно падает, изменения становятся долгими и дорогими.
Некоторые крупные компании следуют принципу "move fast and break things". Да, это несёт риски, и клиентам конечно не нравится, когда качество страдает, но и альтернатива в виде проигрыша конкурентам и закрытия бизнеса не радует. Как всегда, где-то посередине стоит искать баланс, подходящий для вашей команды.
Согласен про стратегию, тоже считаю это большой ценностью. Ищу сейчас QA, который так же будет смотреть на свою работу.
Да, очень тянулись руки поиграть с сетями, взял DALLE-2 :)
В Gradle можно погрузиться, достичь просветления и творить чудеса.
Вот только остальная команда потом офигевает с написанных портянок, где всё вперемешку и творится какая-то магия, которую никто кроме автора не понимает. А чтобы что-то поменять, надо посидеть и сначала разобраться, что там за хрень вообще происходит.
По моему опыту нестрогость подхода в сочетании с кучей возможностей делает Gradle похожим скорее на Javascript в его плохих проявлениях. Maven же даёт чёткую структуру и правила, и не позволяет писать внутри себя скрипты (без откровенных костылей), всё описывается декларативно. Конфиги Maven может поддерживать и изменять любой программист в команде, там не образуется легаси.
Это не говоря о том, что очень тормознуто работает подсветка синтаксиса и выпадающие подсказки по коду, особенно если писать билд файл на котлине. Несколько десятков секунд для выпадающей подсказки - так удобно работать не получится.
У Maven конечно свои минусы в виде многословности, часто странной документации. Плюс Gradle классно интегрируется с IDE для сборки проектов.
Ниже показал, что запрос автора оно спокойно выполняет. Предлагаю вам получше присмотреться к ChatGPT - это практически революция. Она действительно делает вещи, которые прямо сегодня кажутся невероятными.
И хоть "мозгов" у неё ещё не столько же как у нас с вами, но это как в анекдоте:
Идёт мужик по улице, видит сидит дед и с собакой в шахматы играет. Мужик офигевая говорит:
- Какая у вас умная собака!
- Да какая умная, - отвечает дед, - проигрывает 3 : 1!
Побуду вашей персональной чат-консолью и таки попрошу :)
(Придирка, что на выходе не приложение, а по большей части инструкция, не принимается - это не генератор проектов, а ассистент.)
Мне зарплата в 2500$ уже позволяла снимать жильё на airbnb на несколько дней, на пару недель, на месяц. За 1000$ снимал большую квартиру в центре Стамбула. Вроде бы многим в IT такое доступно, а если вы с партнером работаете удаленно оба, то всё ещё проще.
Сейчас цены на аренду в популярных у россиян странах выросли а разы, а раньше можно было в прошлом году снимать в Тбилиси за 300$ почти в центре. То же самое и про соседние страны.
Когда спадёт ажиотаж на рынке, снова будет дешевле. Но даже сейчас вы за 1000$ снимете очень много где.
Не понимаю, зачем обязательно нужно "слишком много зарабатывать", это совсем не космические деньги.
И да, почта всегда работаю из жилого дома - из своей квартиры или со съемного жилья. Изредка - из хостелов или отелей. В коворкинги не хожу, там обычно не так комфортно.
В офисе был 1 день в этом году, и ходить туда каждый день совсем не хочется.
Камон, как у вас всё сложно.
Работал из других городов России, из Турции, Армении, Грузии. В сумме полгода где-то. Всё получалось почему-то, на работе все довольны.
Это не говоря о том, что уже 2.5 года работаю удалённо.
И даже в непростое время последних месяцев не было проблемой получать деньги из РФ.
Вы, простите, теоретик или практик? Пишете с опыта, или вам просто страшно и непонятно всё это?
Тем, кому такая тема близка, советую просто пробовать. Лучше начать с другого города в вашей стране, а потом пробовать зарубежные поездки.
Статья для статьи?
Как человек, который с этим всем работает, могу сказать, что смысл из статьи вычленить очень сложно, и если он в ней и был когда-то (вероятно в каком-то оригинале), то теперь по большинству покинул её.
Прошу прощения, если я неправ или обижаю автора, но как будто бы написал человек, который не понимает о чём пишет. Попробуйте дать прочитать 1-2 знакомым, фидбэк от них легко позволит сделать текст лучше.
Если у вас есть тимлид, техлид, продакт менеджер, аналитик, то задача всех этих людей — взять на себя часть экспертизы и ответственности. Каждый из них должен быть экспертом в своей более узкой области, а разработчик — в своей.
Тимлид пытается ставить понятные задачи с нужной информацией и достижимым результатом, аналитик — дать информацию о бизнес-процессах и фичах, продакт — об ориентации продукта и том, как фичу полезнее сделать для бизнеса, техлид — обсудить векторы решения задачи.
Всё это помогает команде разработчиков сделать свою работу хорошо.
Так вот, синьор разработчик частично может потянуть все эти роли.
Но, во-первых, только частично. Нельзя быть всем и сразу, и делать это лучше, чем все вышеперечисленные люди вместе взятые.
А во-вторых, если все эти люди присутствуют в компании, то делать эту работу за них — это сделать только хуже для компании. Принимать свои собственные решения в обход аналитика, тимлида и прочих — это значит сделать хуже. Тут думаю понятно почему.
Конечно, если в команде нет кого-то из вышеперечисленных людей (а то и всех), то синьор может справляться сам. Но в средних и больших продуктах это скорее всего тупиковый путь развития, не масштабируется.
Если серьёзно, то психолог в штате — звучит классно, я б попробовал. Только очень хочется верить, что это не как школьные психологи, которые вроде бы и есть, но не сильно помогают.
В любом случае, текст выше — это просто компиляция моего опыта, который мне показался может быть немного ценным для кого-то. А ваш фидбэк в комментах ценен для меня.
Когда долго варишься в какой-то области, начинает казаться, что все знают то, что знаешь ты, что всё очевидно. Но как показывает практика, это не так. Кто-то ещё не дошёл до чего-то, что понятно мне. А кто-то имеет опыт, противоположный моему. И он может прийти в статью и своим комментарием открыть и для меня что-то новое.
Считайте, что это такой обоюдный обмен опытом, мнениями и знаниями. С работой психолога это всё имеет мало общего.