Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.
«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.
Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему. Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность.
Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.
Перед вами – перевод свободной онлайн-книги Майкла Нильсена «Neural Networks and Deep Learning», распространяемой под лицензией 
На Хабре уже было несколько публикаций о том, как айтишники строят себе дома и что из этого получается. 
