Если это относится к пункту «Тестируй свой код сам», то он не означает, что в разработке не должно быть этапа тестирования, который проводят тестировщики. Тут с Вами согласен.
Подкорректировал комментарий к этому пункту в тексте. Про другое там хотел сказать. А именно о том, что разработчик должен передавать код на тестирование имея уверенность, что в текущих условиях он сделал всё необходимое, чтобы тестировщик отловил как можно меньше багов.
Бывает, что самое простое решение — самое правильное. Возможно, что описанное Вами это оно самое и есть.
Но сейчас, конкретно к программированию, у меня такой уверенности нету. Хотя может когда-то у меня и изменится мнение. Но пока убедительных доводов не слышу.
Так тогда можно написать про любую профессию:
— Как быть хорошим актёром?
— Изучай актерское мастерство и играй роли в театре.
Ну и т.д.
— Как быть хорошим %профи%?
— Изучай %профи% мастерство и %работай_работу%.
Спасибо за развернутый и аргументированный комментарий.
Про изучение архитектуры, языков, алгоритмов. Согласен с Вами по поводу того, что всё это сейчас быстро развивается и имеет большие масштабы, чтобы освоить всё и сразу. Но я и не призываю изучать все это досконально и сразу или даже по запланированному расписанию.
А понять основные принципы, заложенную философию, чтобы иметь представление о работе основных ОС, ЯП нужно. Их не так уж и много. На пальцах одной руки пересчитать можно. И не обязательно перечитывать толмут какой-нибудь, чтобы эти основы понять. Есть достаточно источников, в которых есть нужная «выжимка». Тут главное найти такие источники.
Про презентации, коммуникации — опять же нет необходимости это пытаться освоить сразу. А если джуниор или даже уже неджуниор, согласен выполнять и дальше пачку нудной, но нужной работы. Если ему это действительно нравится, то может ему это и не надо.
Но если необходимо будет разрабатывать что-то более масштабное и серьезное, то придется взаимодействовать больше, чем с одним разработчиком. Придется описывать архитектуру, схемы взаимодействия сервисов или еще каких-то компонент. А этого без умения хорошо коммуницировать, умения описывать, представлять не получится.
Подкорректировал комментарий к этому пункту в тексте. Про другое там хотел сказать. А именно о том, что разработчик должен передавать код на тестирование имея уверенность, что в текущих условиях он сделал всё необходимое, чтобы тестировщик отловил как можно меньше багов.
Но сейчас, конкретно к программированию, у меня такой уверенности нету. Хотя может когда-то у меня и изменится мнение. Но пока убедительных доводов не слышу.
Так тогда можно написать про любую профессию:
Ну и т.д.
Всё-таки в жизни всё немного сложнее.
Про изучение архитектуры, языков, алгоритмов. Согласен с Вами по поводу того, что всё это сейчас быстро развивается и имеет большие масштабы, чтобы освоить всё и сразу. Но я и не призываю изучать все это досконально и сразу или даже по запланированному расписанию.
А понять основные принципы, заложенную философию, чтобы иметь представление о работе основных ОС, ЯП нужно. Их не так уж и много. На пальцах одной руки пересчитать можно. И не обязательно перечитывать толмут какой-нибудь, чтобы эти основы понять. Есть достаточно источников, в которых есть нужная «выжимка». Тут главное найти такие источники.
Про презентации, коммуникации — опять же нет необходимости это пытаться освоить сразу. А если джуниор или даже уже неджуниор, согласен выполнять и дальше пачку нудной, но нужной работы. Если ему это действительно нравится, то может ему это и не надо.
Но если необходимо будет разрабатывать что-то более масштабное и серьезное, то придется взаимодействовать больше, чем с одним разработчиком. Придется описывать архитектуру, схемы взаимодействия сервисов или еще каких-то компонент. А этого без умения хорошо коммуницировать, умения описывать, представлять не получится.