Вы так говорите, как будто при водопаде не бывает тех долга. Гибкие методологии — всего лишь инструмент, как интеграл. Вы ведь не будете жаловаться на интеграл из-за того, что у вас расчеты не сходятся?
В описываемых вами ситуациях ничего плохого нет, это рабочие моменты.
А вот если, например, разработчик в разгаре тяжелого внедрения начинает рассказывать, что ему неинтересно фиксить баги и он хочет уйти — субъективно это воспринимается как "кидок". В этом случае ожидания руководителя такие — мы доводим дело до конца и расходимся.
Если не секрет — что за компания-то? Чем занимается? Сколько людей работает?
Вы встатье затронули только разработчиков
Я сам разработчик, и считаю себя в праве говорить только от лица разработчиков.
По моему личному опыту работы в нескольких компаниях от расцвета до момента когда всё начинало идти через одно место всегда происходили одни и те же события
Интересно, как это выглядело со стороны руководства.
Рискну предположить — сначала никто ничего не контролирует и сотрудники делают что хотят. Иногда это даже приносит компании успех. По мере роста компания вынуждена выстраивать какие-то процессы, появляется контроль и управляемость. Вчерашние супермены, которые принимали все решения сами, теперь подчиняются назначенному менеджеру («эффективному»). Естественно это им не нравится и происходит частичная или полная смена состава. К сожалению, этот путь практически неизбежен для компании, которая растет. Руководство может смягчить этот процесс, как-то договориться с теми, кто начинал. Но совсем избежать этого тяжело. Это болезнь роста, через нее надо пройти.
Противоречий нет. Репутация — не гарантия. Вопрос — а брали ли вы людей с плохой репутацией? А сейчас возьмете?
Все про всех — это конечно гипербола. Но про большинство — можно получить информацию, достаточную для принятия решения.
Да, в маленьких городах это сложнее, но тут на помощь приходит удаленка.
Правила капитализма никто не отменял. Но пока отрасль растет и есть недостаток в людях — зарплаты будут расти сами собой. Особенно при наличии глобального рынка разработчиков.
Есть куча пограничных ситуаций. Но гораздо чаще приходят люди, про которых все известно. Репутация есть репутация. Но если вы не злодей, чего вам бояться? :)
Не совсем. Востребованность — это возможность без проблем найти работу.
А работнику часто хочется не этого, а банальных денег, увы.
Обычно, человек, который может без проблем найти работу, знает сколько он стоит и может аргументировать это. Поэтому, на мой взгляд, востребованность конвертируется в деньги.
Во-первых, кто вам сказал, что руководитель всегда адекватный? Во-вторых, вы мыслите рационально и идеализировано. В жизни часто бывает человеческий фактор. Т.е. руководитель в целом вменяемый, но есть какая-то придурь и т.д.
Никто не говорил, я верю, что адекватные вытеснят неадекватных. Тяжело быть неадекватным, если твои сотрудники в любой момент могут встать и уйти в соседний офис.
И как альтернатива, придите и скажите, что вы увольняетесь
Да, этот способ работает, но часто воспринимается как шантаж. Со всеми вытекающими.
В моем реальном мире я не могу себе позволить набирать новых разработчиков на каждый проект — у проектов есть сроки, а найм — дело непредсказуемое. Кроме того, проекты сложные и если делать их каждый раз новой командой — будет или качество не очень, или денег компания не заработает.
приходите вы к Скотту Ханселману
Я уверен, что Скотт на заре своей карьеры хоть что-то да поддерживал из того. что разрабатывал. Да и сейчас, если что-нибудь пишет в продакшен, не откажется пофиксить за собой. Профессиональная этика, все такое.
Нормальные компании делают так, что все занимаются тем, что им нравится (и отсюда идут все эти KPI, карьерные цели, пути развития и т.п — просто хотят совместно выяснить, кто что хочет делать). А это нужно для того, чтобы люди были эффективны на 100%. Никто не будет эффективен, если занимается какой-то фигней, которая ему не нравится.
Было бы здорово, если бы это было возможно. К сожалению, это как идея коммунизма — на практике не очень работает. Всегда найдется дело, которым заниматься не очень хочется, но надо.
И если вам не трудно — приведите примеры «нормальных» компаний, где сотрудники занимаются только тем, что им нравится, и ничем другим.
И еще раз, если вы внимательно читали статью — она как раз про то, как найти компромисс между тем, что нужно и тем, что хочется.
Ваш комментарий — отличная иллюстрация для данной статьи.
Лол? Так и нанимайте тех, кто не хочет (не будет) узнавать новое. Проговаривайте это и в вакансии, и на интерью, тогда проблем не будет
Видимо до конца прочитать не получилось, а ведь специально написал:
Думайте не только об успехе проекта, но и о развитии своих людей. Проектов много, пусть разработчики растут с каждым новым проектом. Займитесь регулярным обучением своих людей.
Посмеялся. Может, у руководителя еще и пол надо помыть, картошку вскопать? Нанимайте людей для решения ваших обычных задач, а не для интересных.
Думаю мой посыл прошел мимо вас. Здесь идет речь о том, что в приоритете руководителя не развлечение разработчиков, а решение реальной задачи. А для этого иногда необходимо сосредоточено и невесело дебажить свой код, который в продакшене работает не так как надо.
Про помыть пол и вскопать картошку — жирно.
Вот и переведите на имеющиеся проекты тех, кто готов их поддерживать. А на новые — тех, кто хочет пилить новые. Разве так сложно?
Поясню. Я утверждаю, что поддерживать проекты — полезно для карьеры разработчика. Кроме того, есть еще и понятие эффективности, и ваше решение — крайне неэффективно.
То же самое: при найме сразу проговаривайте, что у вас не только разработка, а еще и выполнение планов, выдача релизов и т.д.
Любому, кто не школьник, это и так понятно. Но это не значит, что всем это нравится.
Микроменеджер? Давайте, до свидания.
Банальный промежуточный контроль. Классика управления. Уверен, что вы в курсе.
Соглашусь, что такое имеет место. Однако, я считаю, что это — пережиток прошлого. Те, кто так делает, рано или поздно покинут рынок — их вытеснят компании, где платят в соответствии с эффективностью.
Другой вопрос, что "стоимость" разработчика он сам и работодатель оценивает по-разному. Об этом, собственно, и статья.
Вы недооцениваете замкнутость сообщества разработчиков. За каждым из нас тянется шлейф побед и поражений. Современные коммуникации даже усугубляют это.
Аргументом в пользу вашей точки зрения является постоянно растущий недостаток разработчиков. Но работает это слегка криво. "Хорошие" компании все равно имеют возможность выбирать, а в "плохие" и неразборчивые вы и сами не захотите.
Спасибо. Я про себя понял, что тоже хотел бы не просто брать то, что есть, а понимать путь этого с самого начала. То есть начинать реально со старого, с классики.
Цель разработчика — быть более востребованным на рынке труда.
— это и есть деньги.
А насчет руководителя вы скорее всего ошибаетесь. Адекватный руководитель заинтересован платить ровно столько, сколько нужно чтобы человек эффективно работал. Ни больше, ни меньше. Зарабатывая на труде разработчиков, логично желать, чтобы они спокойно работали и приносили прибыль.
Принцип Лисков тут не при чем, нарушается принцип инкапсуляции. Детали мутабельной абстракции протекают в иммутабельную. В Котлине это нормально сделано, проблема в том, что Котлин без Java пока еще не может, нужен interop.
Именно так. Варианта 2:
1. Человек решает задачу и мы обсуждаем это решение.
2. Человек сообщает, что быстро не может решить задачу, и мы принимаем решение на основе пунктов 1 и 2. То есть даже в такой ситуации сохраняется шанс не пропустить хорошего человека.
В вашем случае интервьюверы явно поступили некорректно.
Лично я вообще не вижу смысла спрашивать на собеседовании именно детали API.
Но вот например, чем Set отличается от List, вы наверняка бы ответили.
Вы так говорите, как будто при водопаде не бывает тех долга. Гибкие методологии — всего лишь инструмент, как интеграл. Вы ведь не будете жаловаться на интеграл из-за того, что у вас расчеты не сходятся?
В описываемых вами ситуациях ничего плохого нет, это рабочие моменты.
А вот если, например, разработчик в разгаре тяжелого внедрения начинает рассказывать, что ему неинтересно фиксить баги и он хочет уйти — субъективно это воспринимается как "кидок". В этом случае ожидания руководителя такие — мы доводим дело до конца и расходимся.
Если не секрет — что за компания-то? Чем занимается? Сколько людей работает?
Я сам разработчик, и считаю себя в праве говорить только от лица разработчиков.
Интересно, как это выглядело со стороны руководства.
Рискну предположить — сначала никто ничего не контролирует и сотрудники делают что хотят. Иногда это даже приносит компании успех. По мере роста компания вынуждена выстраивать какие-то процессы, появляется контроль и управляемость. Вчерашние супермены, которые принимали все решения сами, теперь подчиняются назначенному менеджеру («эффективному»). Естественно это им не нравится и происходит частичная или полная смена состава. К сожалению, этот путь практически неизбежен для компании, которая растет. Руководство может смягчить этот процесс, как-то договориться с теми, кто начинал. Но совсем избежать этого тяжело. Это болезнь роста, через нее надо пройти.
Все про всех — это конечно гипербола. Но про большинство — можно получить информацию, достаточную для принятия решения.
Правила капитализма никто не отменял. Но пока отрасль растет и есть недостаток в людях — зарплаты будут расти сами собой. Особенно при наличии глобального рынка разработчиков.
Никто не говорил, я верю, что адекватные вытеснят неадекватных. Тяжело быть неадекватным, если твои сотрудники в любой момент могут встать и уйти в соседний офис.
Да, этот способ работает, но часто воспринимается как шантаж. Со всеми вытекающими.
Я уверен, что Скотт на заре своей карьеры хоть что-то да поддерживал из того. что разрабатывал. Да и сейчас, если что-нибудь пишет в продакшен, не откажется пофиксить за собой. Профессиональная этика, все такое.
Было бы здорово, если бы это было возможно. К сожалению, это как идея коммунизма — на практике не очень работает. Всегда найдется дело, которым заниматься не очень хочется, но надо.
И если вам не трудно — приведите примеры «нормальных» компаний, где сотрудники занимаются только тем, что им нравится, и ничем другим.
И еще раз, если вы внимательно читали статью — она как раз про то, как найти компромисс между тем, что нужно и тем, что хочется.
Видимо до конца прочитать не получилось, а ведь специально написал:
Думаю мой посыл прошел мимо вас. Здесь идет речь о том, что в приоритете руководителя не развлечение разработчиков, а решение реальной задачи. А для этого иногда необходимо сосредоточено и невесело дебажить свой код, который в продакшене работает не так как надо.
Про помыть пол и вскопать картошку — жирно.
Поясню. Я утверждаю, что поддерживать проекты — полезно для карьеры разработчика. Кроме того, есть еще и понятие эффективности, и ваше решение — крайне неэффективно.
Любому, кто не школьник, это и так понятно. Но это не значит, что всем это нравится.
Банальный промежуточный контроль. Классика управления. Уверен, что вы в курсе.
А так да, с вашим комментарием вполне согласен.
Соглашусь, что такое имеет место. Однако, я считаю, что это — пережиток прошлого. Те, кто так делает, рано или поздно покинут рынок — их вытеснят компании, где платят в соответствии с эффективностью.
Другой вопрос, что "стоимость" разработчика он сам и работодатель оценивает по-разному. Об этом, собственно, и статья.
Вы недооцениваете замкнутость сообщества разработчиков. За каждым из нас тянется шлейф побед и поражений. Современные коммуникации даже усугубляют это.
Аргументом в пользу вашей точки зрения является постоянно растущий недостаток разработчиков. Но работает это слегка криво. "Хорошие" компании все равно имеют возможность выбирать, а в "плохие" и неразборчивые вы и сами не захотите.
А насчет руководителя вы скорее всего ошибаетесь. Адекватный руководитель заинтересован платить ровно столько, сколько нужно чтобы человек эффективно работал. Ни больше, ни меньше. Зарабатывая на труде разработчиков, логично желать, чтобы они спокойно работали и приносили прибыль.
Принцип Лисков тут не при чем, нарушается принцип инкапсуляции. Детали мутабельной абстракции протекают в иммутабельную. В Котлине это нормально сделано, проблема в том, что Котлин без Java пока еще не может, нужен interop.
1. Человек решает задачу и мы обсуждаем это решение.
2. Человек сообщает, что быстро не может решить задачу, и мы принимаем решение на основе пунктов 1 и 2. То есть даже в такой ситуации сохраняется шанс не пропустить хорошего человека.
Лично я вообще не вижу смысла спрашивать на собеседовании именно детали API.
Но вот например, чем Set отличается от List, вы наверняка бы ответили.