Прошу прощения, не вымышленное. Но слово бочонок лишь подтверждает правило, только смысл немного меняется, в данном случае оно означает не детёныша бочки, а маленькую бочку (исходя из нашего знания о том, что бочка — неодушевлённый предмет (и тут я понял что был не прав, парой коментов выше о том, что для бочонок родитель боч, родителем с таким же успехом является и бочка).
Возможно, разница между тем, является ли это детёнышем или является ли это маленьким предметом определяется исходя из вероятностей употребления данных окончаний к одушевлённым и неодушевлённым предметам. Для любого незнакомого мне существительного с окончанием «ёнок», мой внутренний классификатор говорит что это, скорее, детёныш, нежели маленький предмет. Примеры: хабрёнок, пырнёнок, вилёнок, пыщонок, ололёнок.
1) Во фразе «и катит бочонка» — ощущение есть, но это уже вымышленное слово, которое скорее всего и будет обозночать детёныша. Сочетания «катит бочонка» в русском вроде нет.
2) Конечно же правил намного больше, и подсознательно мы знаем их все. Так же мы знаем и исключения, но, даже такое исключение не сильны выбивается из общей картины. В слове «цыплёнок» окончание вполне соответствует, да и слово «курицёнок» или «куричёнок» звучит весьма правдоподобно.
3) Ответил в ветке выше.
Но тут срабатывает правило, по которому фильтруются фразы «Дети и пятеро играли во дворе», по которому собирательные числительные выглядят странно, когда идут в перечеслении.
Большая часть пунктов достаточно спорна и зависит от проекта.
Проводит декомпозицию задачи и проектирует ее решение
Далеко не все задачи требуют проектирования. Иногда нужно просто взять и захотфиксить баг. Или решить какую-то research задачку, для которой код пишется один раз.
Адекватно оценивает затраты на выполнение
Такое возможно если все задачи однотипные. А если задача новая (которую ты и, возможно, никто в твоей организации ещё не решал) и отчасти включают в себя research, отчасти разработку прототипов и эксперементирование)? И даже банальные задачи, которые заказчику кажутся простыми могут натолкнуться на непредвиденные препятствия, вроде необходимости рефакторить систему, потому что дальнейшее накопление технического долга слишком дорого.
Планирует свою работу и составляет график
Тоже самое что и предыдущий пункт. По графику может работать только сферический программист в идеальном вакууме. На практике всегда что-то пойдёт не по плану. Это не значит что планировать не нужно совсем. Но если задавать строгий график то ты в него не уложишься с вероятностью ~99%.
Соблюдает принятые стандарты
Всё равно что «Соблюдать синтаксис языка». Если не соблюдаешь синтаксис — пошлёт компилятор. Не соблюдаешь стандарты — пошлёт code-review.
Обеспечивает требуемое качество, минимизируя затраты и риски
Пожалуй, единственный важный пункт. Умение находить золотую середину между стоимостью (временем) разработки конкретной фичи и профитом, который она даст (качеством, требованиям заказчика, etc.). Очень мало программистов могут в этом месте принять объективное решение. Часть скажет что задача сложная и её делать дорого, хотя на самом деле им просто влом разбираться в (новой технологии / чужом коде / etc.). Часть наоборот — скажет что лёгкая и будет потом ковыряться, хотя оно того не стоит. Часть для лёгкой задачи выберет не самое тривиальное решение или наоборот (вместо использования технологии X навелосипедить там где не надо / вместо небольшого трёхстрочного велосипеда заиспользовать технологию X потому что она крутая и интерестно с ней разобраться).
Выполняет тестирование и отладку кода
Комитить код, не протестировав его не разу — как минимум странно. А заниматься всесторонним ручным тестированием своего кода, если ты не тестер — не рационально. Лучше юнит-тестов написать.
Анализирует найденные дефекты и отклонения от графика
Если под дефектами подразумеваются баги, а под анализом — их фиксинг — тогда ещё один очевидный пункт. Отклонения от графика возникают не на пустом месте, а являются следствием принятий решений, описываемых в пункте 5. При возникновении непредвиденных сложностей всегда есть два пути — не пилить эту фичу или увеличить сроки.
Нет, не винительным падежом, а именно самим словом, а точнее окончанием «ёнок». Во фразе «и катит бочонок» ощущения что это детёныш нет. Такое ощущение могло бы возникнуть, если бы было известно слово «боч», но так как мы знаем что его нет, а есть «бочка», => бочонок — не детёныш. Для слова «бочка» — детёныш «бочконёнок».
По внешнему виду не возможно, а по контексту можно. Например: «Капуки и семеры козлят бочконёнка». Во фразе «волк и семеро козлят» часть рече идентифицируется так же по контексту. «семеро» не похоже на существительное (разве что это населённый пункт).
Уменее эффективно мыслить не является критичным для выживания. Сейчас выживают и размножаются кто угодно, даже зависимости между эффективностью мозга и количеством потомства нет. Откуда взяться эволюции?
Вы серьёзно считаете что достаточно в нужном месте взорвать трубу и снаряд самостоятельно изменит траекторию и полетит в нужном для террористов направлении?
Ответ «я это делать принципиально не буду» и «потому что это бесполезная трата времени» может быть дан разработчиком в двух случаях:
— он не хочет работать
— он понимает что эта задача на самом деле не нужна заказчику / эта задача будет стоить слишком дорого
В первом случае — не вижу смысла держать таких разработчиков (вдруг завтра баг в продакшене а он откажется его фиксить «из принципа»).
Во втором — разработчик должен уметь объяснить заказчику почему он так считает.
Здесь подразумевается всё же full-stack разработчик а не человек-оркестр. Разница в том, что он не верстальщик и уж точно не дизайнер. Такой человек может к примеру, утром написать патч к nginx, вечером захотфиксить пару багов в алгоритмах backend-а, а на следующий день запилить прикольный фронтенд на bootstrap + ajax для какой-нибудь внутренней утилиты.
Под ошибкой я и подразумевал второе. Ну и различные косяки обычно тоже отлавливаются. Если в команде принято коментить и на ревью придёт изменение без изменений коментов — это примерно первый случай.
Возможно, разница между тем, является ли это детёнышем или является ли это маленьким предметом определяется исходя из вероятностей употребления данных окончаний к одушевлённым и неодушевлённым предметам. Для любого незнакомого мне существительного с окончанием «ёнок», мой внутренний классификатор говорит что это, скорее, детёныш, нежели маленький предмет. Примеры: хабрёнок, пырнёнок, вилёнок, пыщонок, ололёнок.
2) Конечно же правил намного больше, и подсознательно мы знаем их все. Так же мы знаем и исключения, но, даже такое исключение не сильны выбивается из общей картины. В слове «цыплёнок» окончание вполне соответствует, да и слово «курицёнок» или «куричёнок» звучит весьма правдоподобно.
3) Ответил в ветке выше.
Далеко не все задачи требуют проектирования. Иногда нужно просто взять и захотфиксить баг. Или решить какую-то research задачку, для которой код пишется один раз.
Такое возможно если все задачи однотипные. А если задача новая (которую ты и, возможно, никто в твоей организации ещё не решал) и отчасти включают в себя research, отчасти разработку прототипов и эксперементирование)? И даже банальные задачи, которые заказчику кажутся простыми могут натолкнуться на непредвиденные препятствия, вроде необходимости рефакторить систему, потому что дальнейшее накопление технического долга слишком дорого.
Тоже самое что и предыдущий пункт. По графику может работать только сферический программист в идеальном вакууме. На практике всегда что-то пойдёт не по плану. Это не значит что планировать не нужно совсем. Но если задавать строгий график то ты в него не уложишься с вероятностью ~99%.
Всё равно что «Соблюдать синтаксис языка». Если не соблюдаешь синтаксис — пошлёт компилятор. Не соблюдаешь стандарты — пошлёт code-review.
Пожалуй, единственный важный пункт. Умение находить золотую середину между стоимостью (временем) разработки конкретной фичи и профитом, который она даст (качеством, требованиям заказчика, etc.). Очень мало программистов могут в этом месте принять объективное решение. Часть скажет что задача сложная и её делать дорого, хотя на самом деле им просто влом разбираться в (новой технологии / чужом коде / etc.). Часть наоборот — скажет что лёгкая и будет потом ковыряться, хотя оно того не стоит. Часть для лёгкой задачи выберет не самое тривиальное решение или наоборот (вместо использования технологии X навелосипедить там где не надо / вместо небольшого трёхстрочного велосипеда заиспользовать технологию X потому что она крутая и интерестно с ней разобраться).
Комитить код, не протестировав его не разу — как минимум странно. А заниматься всесторонним ручным тестированием своего кода, если ты не тестер — не рационально. Лучше юнит-тестов написать.
Если под дефектами подразумеваются баги, а под анализом — их фиксинг — тогда ещё один очевидный пункт. Отклонения от графика возникают не на пустом месте, а являются следствием принятий решений, описываемых в пункте 5. При возникновении непредвиденных сложностей всегда есть два пути — не пилить эту фичу или увеличить сроки.
По внешнему виду не возможно, а по контексту можно. Например: «Капуки и семеры козлят бочконёнка». Во фразе «волк и семеро козлят» часть рече идентифицируется так же по контексту. «семеро» не похоже на существительное (разве что это населённый пункт).
— он не хочет работать
— он понимает что эта задача на самом деле не нужна заказчику / эта задача будет стоить слишком дорого
В первом случае — не вижу смысла держать таких разработчиков (вдруг завтра баг в продакшене а он откажется его фиксить «из принципа»).
Во втором — разработчик должен уметь объяснить заказчику почему он так считает.