Ради избавления от боли клиента. Это третье лицо, ради удовлетворения потребностей которого работают менеджер и разработчик. Разработчик без менеджера не продаст результат работы своего труда, менеджеру без разработчика нечего будет продавать клиенту.
Возможно, мы говорим о разном. Я вижу, что в ваших комментариях слово менеджер употребляется синонимом "дяди", на которого работает программист. В конечном итоге работают не на дядю, а на клиента, который даёт деньги на зарплату и менеджера и разработчика.
В идеале такой список должен вести руководитель. Но, да, абсолютно нелишним будет записывать его самостоятельно. А на ревью свериться, что "достижения" по вашему мнению и мнению руководителя как минимум сильно пересекаются и курс саморазвития выбран верный (если в компании не налажена культура давать фидбэк сразу после замеченного достижения - что ещё лучше).
Я полностью согласен с написанным. Это логичный и прагматичный подход.
Если всё же начать копать глубже, то мы перейдем в область этики. Часто этот "мягкий лимит" устанавливает сам программист. Типичная ситуация в не-IT компаниях, так как кроме самого разработчика экспертизы в технической части нет. Корректно ли по отношению к работодателю работать с эффективностью 75%? Или игнорировать возможности делать что-то лучше и продуктивнее, когда эта возможность видна невооруженным глазом? Делать меньше, когда тебя не контролируют. И так далее.
Но тема морали слишком необъятна, чтобы ее поднимать )) Поэтому ну ее нафиг.
Я повторюсь, что это не хождение навстречу. Задача разработчика - сделать продукт, соответствующий требованиям от менеджера с минимальными издержками. Вникание в предметную область относится к способам уменьшения издержек. Менеджер ищет способы как дороже продать, программист ищет способы, как дешевле произвести. Предметная область - это межграничная территория, демилитаризованная зона, в каком то смысле. Поход туда != поход навстречу.
Подобные суждения возникают из-за непонимания, как монетизируется конкретный кусок кода, реализованный программистом. Я уже выше в другом треде писал, про полезность мышления о работе не как о создании кода, а как решение чьей-то проблемы, "боли", которая достаточно болит, чтобы заплатить X рублей (или потратить Y часов внутренней разработки в случае внутренней задачи - не суть важно). При таком подходе вопроса "почему эти менеджеры не хотят изучать базы данных" просто не возникло бы. Потому что менеджер - про найти боль и придумать способ лечения, а программист - про сделать лекарство, быстро, качественно и недорого в требуемых в данной ситуации пропорциях.
Постарался донести мысль, возможно, путано. Но как могу :)
А для чего менеджеру лезть в структуру базы данных? Это не его зона ответственности. Задача менеджера ("заказчика") - придумать продукт, который можно продать дороже, чем затраты на его разработку + когда он сделан, таки продать его. Задача разработчика - реализовать продукт, соответствующий требованиям, с минимальными издержками. Все работают в тандеме, пытаясь сократить лишние траты, так как в конечном итоге из разницы будет выплачиваться зарплата как менеджеру, так и разработчику.
Вниканием в предметную область разработчик сокращает издержки на производство конечного продукта - понятная причина делать это. От того, что менеджер вникнет в струтуру базы данных, никому, в том числе и разработчику не будет профита. Поэтому этого не происходит и не будет происходить.
Всё так. Но это не отменяет факта, что при прочих равных выберут разработчика с хардовыми + софтовыми скилами, а не с только хардовыми. Ну или бабла больше дадут. На совсем стартовом этапе логично вкладывать усилия в изучение второго фреймворка. Но когда знаешь уже пять фреймворков и стоит выбор, выучить шестой или подтянуть софтовые скилы - тут выбор очевиден.
Немного оффтопа.
Меня лично всегда демотивировала позиция "разработчик должен разрабатывать" или "таксист должен возить людей с места на место". В конечном итоге, любая работа = помощь кому-то в решении его проблемы. Таксист помогает мне вовремя добраться до аэропорта. Программист помогает N людям в своей компании, автоматизировав некий процесс. Отношение к работе как к "разрабатывать", без эмпатии и прочей социальщины - это банально скучно. Размен денег на время. Не понимаю, короче, такого.
Например, в тексте про Лукьяна и Демьяна. В конце Лукьяна хвалят, потому что он проявил инициативу и разрулил проблему. Но неявно еще и потому, что знал "границы инициативы".
Прежде всего, он ориентируется в ценах. Если бы не сумел сторговаться за 18, а сторговался бы за 24 - стоило бы брать? Возможно, да. Возможно, нет. Это подскажет только опыт работы с проектом "закупки сена". У него он есть и он не хуже своего барина знает, сколько телег сена стоило бы взять по 24, а сколько по 18. Опыт раздвигает границы инициативы.
Но, если бы ему предложили за 30 и не сбивали бы цену, стал бы он брать, не посоветовавшись с более знающим "барином"? Очень верояно, нет, побежал бы уточнять - так как это уже за "границами" и шанс получить по шапке за такую закупку становится достаточно вероятным.
> отсеять говеное ТЗ надо 10 секунд(или меньше)
Нет :) Этого достаточно, чтобы открыть ссылку в гитхабе. У меня проверка тестового занимает миниум 20-30 минут + написание в письме результата, если кандидат не прошёл этот этап, с пояснением проблем (10-15 минут, я пишу достаточно обширные ревью). Даже в примитивном задании надо пройтись по коду, оценить разбиение на классы, как назваются поля, посмотреть на структуру бд, посмотреть на фронт. Уверяю, что качественная проверка тестовых отнимает гораздо больше времени, чем вы предполагаете.
Статистика 50 говно, 50 норм тоже не совсем реалистична. Опишу как я вижу это со своей стороны. Допустим, на вакансию в день отвечают 10 человек. 8 из них — случайно зашедшие, не прочитавшие даже требований к кандидату. 2 оставшихся — потенциально подходят, но очень вероятно отвалятся на этапе более подробного обсуждения вакансии (оклада, условий работы, каких-то нюансов, которые важны кандидату). Итого, остаются 2-3 человека в неделю, которых потенциально можно пригласить на собеседование. Из них надо определить людей, подходящих по уровню, а это к сожалению при устном общении не определяется. Например, кандидат говорит, что «да, конечно, я комментирую код». Но гораздо интереснее не этот факт, а посмотреть на реальном примере, что он напишет в комментариях, в каком объеме, какие формулировки использует и тд. Аналогично и с юнит-тестами. И с проектированием БД. И только после этого, отфильтровав неподходящих, разумно тратить время человека на поездку на личное собеседование. Компаний, которые зазывают к себе кандидатов пачками и пачками и разворачивают лично я не понимаю и не поддерживаю. Потратить час на тестовое (или потратить 2 минуты и понять, что компания не подходит) имхо лучше, чем потратить 4 часа на поездку в офис и собеседование.
Тогда не понимаю вашу фразу «вы просто экономите свои деньги за счет денег соискателей». Мне уже правда стало интересно, как экономятся деньги компании за счет выполнения тестовых (которые к слову проверяют тимлиды или старшие программисты, т.е. люди с довольно высоким рейтом за час).
Вы почему-то уверены, что результатами тестового задания работодатель может воспользоваться. Но обычно это не так. Потому что вы как минимум не знакомы еще со стилем оформления кода в компании. Даже если вдруг некто захочет взять ваше тестовое за основу решения условного внутреннего тикета, код нужно будет рефакторить и затратить массу времени. Это экономически неэффективно :)
Самое разумное на мой взгляд — когда просят выложить код в паблик. Это полезно и кандидату (себя показать, особенно джунам, у которых кода в открытом доступе нет) и компании (избавиться от подозрений про использование кода в так сказать личных целях).
> всё равно будут делать по-своему
За вот это очень цепляется глаз. Продакт — принимает решение о направлении развития и формирует бизнес-требования. Разработчик — реализует их (а хороший разработчик еще и предлагает технические оптимизации, не видные продакту). Если разработчик что-то кодит самовольно, это явный косяк процессов. Можно задуматься, почему так происходит и кто в этом виноват (явно не разработчик, если продакт позволяет ему делать то, что описано выше; тут либо что-то не так с авторитетом продакта, либо нежелание экскалировать ситуацию и привлечь людей выше по должности). В любом случае, такое надо исправлять.
> стакан семечек в метро не сможет продать
Звучит правда немного обидно. Все вроде бы понимают, что продавать семки в метро — не задача разработчика. Как и продакта — разбираться во внутренностях линукса.
Как раз пропущенный раздел «Решения» и было бы интересно почитать.
Моё скромное имхо: если разработчик две недели работал над кодом и получил в результате «не мышонка, не лягушку, а неведому зверушку» — то тут надо дать по шапке тимлиду. В именно его задачи входит мониторинг, кто какую проблему решает и осмысленные ли ресурсы туда вкладываются. Такое должно вылезти на ежедневных митапах, если они внедрены в процесс, т.е. масимум через два дня. А две недели — это полный фейспалм и бесконтрольность.
Еще достаточно полезно, если разделены «технические» и «бизнесовые» задачи и люди, ответственные за их постановку. Технические («перед новой фичей надо бы код такого-то сервиса порефакторить, а то там полный трэш», «оу, тут на днях новый лтс дотнета вышел, надо бы потихоньку обновиться») ставит тимлид, а бизнесовые — продакт.
Если переменная используется в пределах одного метода, то да, разумеется заводить багу отдельную никто не будет. Но если например ошибка в имени класса, который используется в десятках других классов, то даже только ради удобства ревью я бы предпочел это видеть отдельной задачей. А вдруг эту самую библиотеку, в которой делаются правки, кто-то импортит из другого проекта и в следующий импорт код внезапно сломается.
Или, скажем, мы видим очепятку на сайте, вносим никому не сказав правки. В том числе не предупредив людей, отвечающих за контент сайта. В следующий раз они пришлют правки текстов снова с этой очепяткой и другой программист тупо заменит пофиксенные тексты на сайте на пришедшие с оставшейся в них опечаткой.
Общая идея, что с одной стороны бюрократия — зло, но с другой лично у меня заведение типовой задачи в джире + сделать ветку в гитхаб десктоп занимает ну секунд 30 времени. Зато потом всем проще.
Да, ревью кода, где намешаны изменения логики работы и рефакторинг — это ад. Visual Studio с ее предложениями изменения синтаксиса в С# особенно прекрасна. Смотришь мёрж реквест, вникаешь в изменения и тут бац, заменённый синтаксис case на новый модный в двадцати файлах проекта. Посылаешь лучи добра автору кода.
У нас, например, есть четкое правило: заметил говнокод — заводи отдельный таск в джире с типом «рефакторинг» и делай все изменения в его ветке. Если позволяет время спринта, он вносится асапом и выполняется до таска с изменениями логики. Если нет — ну сорян, надо работать с тем, что есть, а рефакторить после (зависит от критичности таска, конечно).
Думаю, тут имелась в виду коммерческая разработка. Все компании на собеседованиях говорят, что «да, конечно, мы юнит-тесты практикуем». На деле тестами покрыт максимум самые мишшн-критикал куски кода, которые, внимание, редко меняются. Так как в них зашита логика базовых бизнес-процессов компании, которые, понятно, не могут резко поменяться. А править нужно ту самую утилиту, написанную два года назад в спешке, что всё это время отлично работала и вдруг сломалась — и такие места обычно имеют ровно 0% code coverage.
ConEmu и Cmder блочатся антивирусами (drweb точно). У меня на корп компьютере вырубить антивирь или перенастроить исключения нельзя. У windows terminal такой проблемы нет, поэтому с ранних версий сижу на нем.
Ради избавления от боли клиента. Это третье лицо, ради удовлетворения потребностей которого работают менеджер и разработчик. Разработчик без менеджера не продаст результат работы своего труда, менеджеру без разработчика нечего будет продавать клиенту.
Возможно, мы говорим о разном. Я вижу, что в ваших комментариях слово менеджер употребляется синонимом "дяди", на которого работает программист. В конечном итоге работают не на дядю, а на клиента, который даёт деньги на зарплату и менеджера и разработчика.
В идеале такой список должен вести руководитель. Но, да, абсолютно нелишним будет записывать его самостоятельно. А на ревью свериться, что "достижения" по вашему мнению и мнению руководителя как минимум сильно пересекаются и курс саморазвития выбран верный (если в компании не налажена культура давать фидбэк сразу после замеченного достижения - что ещё лучше).
Я полностью согласен с написанным. Это логичный и прагматичный подход.
Если всё же начать копать глубже, то мы перейдем в область этики. Часто этот "мягкий лимит" устанавливает сам программист. Типичная ситуация в не-IT компаниях, так как кроме самого разработчика экспертизы в технической части нет. Корректно ли по отношению к работодателю работать с эффективностью 75%? Или игнорировать возможности делать что-то лучше и продуктивнее, когда эта возможность видна невооруженным глазом? Делать меньше, когда тебя не контролируют. И так далее.
Но тема морали слишком необъятна, чтобы ее поднимать )) Поэтому ну ее нафиг.
Тогда прошу прощения. Мой комментарий был написан в парадигме "должен и ничего другого".
Я повторюсь, что это не хождение навстречу. Задача разработчика - сделать продукт, соответствующий требованиям от менеджера с минимальными издержками. Вникание в предметную область относится к способам уменьшения издержек. Менеджер ищет способы как дороже продать, программист ищет способы, как дешевле произвести. Предметная область - это межграничная территория, демилитаризованная зона, в каком то смысле. Поход туда != поход навстречу.
Подобные суждения возникают из-за непонимания, как монетизируется конкретный кусок кода, реализованный программистом. Я уже выше в другом треде писал, про полезность мышления о работе не как о создании кода, а как решение чьей-то проблемы, "боли", которая достаточно болит, чтобы заплатить X рублей (или потратить Y часов внутренней разработки в случае внутренней задачи - не суть важно). При таком подходе вопроса "почему эти менеджеры не хотят изучать базы данных" просто не возникло бы. Потому что менеджер - про найти боль и придумать способ лечения, а программист - про сделать лекарство, быстро, качественно и недорого в требуемых в данной ситуации пропорциях.
Постарался донести мысль, возможно, путано. Но как могу :)
А для чего менеджеру лезть в структуру базы данных? Это не его зона ответственности. Задача менеджера ("заказчика") - придумать продукт, который можно продать дороже, чем затраты на его разработку + когда он сделан, таки продать его. Задача разработчика - реализовать продукт, соответствующий требованиям, с минимальными издержками. Все работают в тандеме, пытаясь сократить лишние траты, так как в конечном итоге из разницы будет выплачиваться зарплата как менеджеру, так и разработчику.
Вниканием в предметную область разработчик сокращает издержки на производство конечного продукта - понятная причина делать это. От того, что менеджер вникнет в струтуру базы данных, никому, в том числе и разработчику не будет профита. Поэтому этого не происходит и не будет происходить.
Всё так. Но это не отменяет факта, что при прочих равных выберут разработчика с хардовыми + софтовыми скилами, а не с только хардовыми. Ну или бабла больше дадут. На совсем стартовом этапе логично вкладывать усилия в изучение второго фреймворка. Но когда знаешь уже пять фреймворков и стоит выбор, выучить шестой или подтянуть софтовые скилы - тут выбор очевиден.
Немного оффтопа.
Меня лично всегда демотивировала позиция "разработчик должен разрабатывать" или "таксист должен возить людей с места на место". В конечном итоге, любая работа = помощь кому-то в решении его проблемы. Таксист помогает мне вовремя добраться до аэропорта. Программист помогает N людям в своей компании, автоматизировав некий процесс. Отношение к работе как к "разрабатывать", без эмпатии и прочей социальщины - это банально скучно. Размен денег на время. Не понимаю, короче, такого.
Например, в тексте про Лукьяна и Демьяна. В конце Лукьяна хвалят, потому что он проявил инициативу и разрулил проблему. Но неявно еще и потому, что знал "границы инициативы".
Прежде всего, он ориентируется в ценах. Если бы не сумел сторговаться за 18, а сторговался бы за 24 - стоило бы брать? Возможно, да. Возможно, нет. Это подскажет только опыт работы с проектом "закупки сена". У него он есть и он не хуже своего барина знает, сколько телег сена стоило бы взять по 24, а сколько по 18. Опыт раздвигает границы инициативы.
Но, если бы ему предложили за 30 и не сбивали бы цену, стал бы он брать, не посоветовавшись с более знающим "барином"? Очень верояно, нет, побежал бы уточнять - так как это уже за "границами" и шанс получить по шапке за такую закупку становится достаточно вероятным.
Я услышал ключевую идею автора так.
Если кратко:
Проявлять инициативу.
Знать границы проявления инициативы.
Нет :) Этого достаточно, чтобы открыть ссылку в гитхабе. У меня проверка тестового занимает миниум 20-30 минут + написание в письме результата, если кандидат не прошёл этот этап, с пояснением проблем (10-15 минут, я пишу достаточно обширные ревью). Даже в примитивном задании надо пройтись по коду, оценить разбиение на классы, как назваются поля, посмотреть на структуру бд, посмотреть на фронт. Уверяю, что качественная проверка тестовых отнимает гораздо больше времени, чем вы предполагаете.
Статистика 50 говно, 50 норм тоже не совсем реалистична. Опишу как я вижу это со своей стороны. Допустим, на вакансию в день отвечают 10 человек. 8 из них — случайно зашедшие, не прочитавшие даже требований к кандидату. 2 оставшихся — потенциально подходят, но очень вероятно отвалятся на этапе более подробного обсуждения вакансии (оклада, условий работы, каких-то нюансов, которые важны кандидату). Итого, остаются 2-3 человека в неделю, которых потенциально можно пригласить на собеседование. Из них надо определить людей, подходящих по уровню, а это к сожалению при устном общении не определяется. Например, кандидат говорит, что «да, конечно, я комментирую код». Но гораздо интереснее не этот факт, а посмотреть на реальном примере, что он напишет в комментариях, в каком объеме, какие формулировки использует и тд. Аналогично и с юнит-тестами. И с проектированием БД. И только после этого, отфильтровав неподходящих, разумно тратить время человека на поездку на личное собеседование. Компаний, которые зазывают к себе кандидатов пачками и пачками и разворачивают лично я не понимаю и не поддерживаю. Потратить час на тестовое (или потратить 2 минуты и понять, что компания не подходит) имхо лучше, чем потратить 4 часа на поездку в офис и собеседование.
Тогда не понимаю вашу фразу «вы просто экономите свои деньги за счет денег соискателей». Мне уже правда стало интересно, как экономятся деньги компании за счет выполнения тестовых (которые к слову проверяют тимлиды или старшие программисты, т.е. люди с довольно высоким рейтом за час).
Самое разумное на мой взгляд — когда просят выложить код в паблик. Это полезно и кандидату (себя показать, особенно джунам, у которых кода в открытом доступе нет) и компании (избавиться от подозрений про использование кода в так сказать личных целях).
За вот это очень цепляется глаз. Продакт — принимает решение о направлении развития и формирует бизнес-требования. Разработчик — реализует их (а хороший разработчик еще и предлагает технические оптимизации, не видные продакту). Если разработчик что-то кодит самовольно, это явный косяк процессов. Можно задуматься, почему так происходит и кто в этом виноват (явно не разработчик, если продакт позволяет ему делать то, что описано выше; тут либо что-то не так с авторитетом продакта, либо нежелание экскалировать ситуацию и привлечь людей выше по должности). В любом случае, такое надо исправлять.
> стакан семечек в метро не сможет продать
Звучит правда немного обидно. Все вроде бы понимают, что продавать семки в метро — не задача разработчика. Как и продакта — разбираться во внутренностях линукса.
Моё скромное имхо: если разработчик две недели работал над кодом и получил в результате «не мышонка, не лягушку, а неведому зверушку» — то тут надо дать по шапке тимлиду. В именно его задачи входит мониторинг, кто какую проблему решает и осмысленные ли ресурсы туда вкладываются. Такое должно вылезти на ежедневных митапах, если они внедрены в процесс, т.е. масимум через два дня. А две недели — это полный фейспалм и бесконтрольность.
Еще достаточно полезно, если разделены «технические» и «бизнесовые» задачи и люди, ответственные за их постановку. Технические («перед новой фичей надо бы код такого-то сервиса порефакторить, а то там полный трэш», «оу, тут на днях новый лтс дотнета вышел, надо бы потихоньку обновиться») ставит тимлид, а бизнесовые — продакт.
Или, скажем, мы видим очепятку на сайте, вносим никому не сказав правки. В том числе не предупредив людей, отвечающих за контент сайта. В следующий раз они пришлют правки текстов снова с этой очепяткой и другой программист тупо заменит пофиксенные тексты на сайте на пришедшие с оставшейся в них опечаткой.
Общая идея, что с одной стороны бюрократия — зло, но с другой лично у меня заведение типовой задачи в джире + сделать ветку в гитхаб десктоп занимает ну секунд 30 времени. Зато потом всем проще.
У нас, например, есть четкое правило: заметил говнокод — заводи отдельный таск в джире с типом «рефакторинг» и делай все изменения в его ветке. Если позволяет время спринта, он вносится асапом и выполняется до таска с изменениями логики. Если нет — ну сорян, надо работать с тем, что есть, а рефакторить после (зависит от критичности таска, конечно).
Жизнь…
Стартует еще пошустрее (субъективно).
Если сравнивать с terminus и cmder, есть какие-то интересные плюшки?