Pull to refresh

Comments 8

Блин, ну хватит уже


-Как быть хорошим программистом?
-Изучай программирование и программируй.
Бывает, что самое простое решение — самое правильное. Возможно, что описанное Вами это оно самое и есть.
Но сейчас, конкретно к программированию, у меня такой уверенности нету. Хотя может когда-то у меня и изменится мнение. Но пока убедительных доводов не слышу.
Так тогда можно написать про любую профессию:
— Как быть хорошим актёром?
— Изучай актерское мастерство и играй роли в театре.

Ну и т.д.
— Как быть хорошим %профи%?
— Изучай %профи% мастерство и %работай_работу%.


Всё-таки в жизни всё немного сложнее.
Сомнительной полезности статья, как по мне. Уж извините. Попробую пояснить.

В современном мире под фразой «я не знаю» подразумевается вовсе не то, что мне нечего читать/смотреть/слушать, а совсем даже противоположное: книг, видеокурсов, подкастов становится слишком много, направления каждой из них всё больше и больше отрываются друг от друга (15 лет назад перекатиться с Java на JavaScript можно было легко и просто, сейчас же это фактически две разные вселенные). Информация быстро устаревает, поэтому многие из обучающих материалов составляются на скорую руку, что ещё больше снижает их качество: непоследовательное изложение, нерабочие примеры, слишком простые/сложные задачи.

На изучение архитектуры одной только Windows требуется многие месяцы (перечитываем знаменитый текст про «фатальный недостаток»). А есть ещё Linux, где архитектура дистрибутива зачастую полностью меняется раз в несколько лет, Android, iOS…

Языки сейчас развиваются быстрее, чем большинство программистов успевает их осваивать. Мы до сих пор работаем на Java 8, хотя последняя версия уже месяц как 13. Едва успевая за новшествами Java EE (который внезапно уже Jakarta EE), Spring, Kotlin и прочего, я всё полнее осознаю, что перспектива параллельного знакомства с .NET становится всё более туманной.

Изучение алгоритмов, структур, дискретки часто имеет ту же проблему, что и изучение тригонометрии в средней школе: детей начинают пичкать решениями с помощью косинусов ещё до того, как они доросли до осознания самой проблемы, которую эти косинусы призваны решить. Как результат, большинство людей так до самой смерти и не понимают, зачем же они это изучали. К чему я это? А к тому, что за 8 лет промышленной разработки мне так ни разу и не потребовалась структура сложнее HashSet и алгоритма сложнее библиотечного quickSort.

Презентации, коммуникации, тестовые задания? Откуда взять на всё это время и силы, если, придя на стажировку или работу джуниором, вы с высокой долей вероятности получите пачку нудных, однообразных и рутинных (но от этого не менее важных для результата проекта) задач вроде тестирования, документирования, ковыряния кода в поисках мелких багов. После чего за что-то своё браться уже совсем не хочется. В молодые годы ещё куда ни шло, а с возрастом это становится всё труднее.

А ещё же семья, дети, какие-то альтернативные увлечения…
Спасибо за развернутый и аргументированный комментарий.

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

Про презентации, коммуникации — опять же нет необходимости это пытаться освоить сразу. А если джуниор или даже уже неджуниор, согласен выполнять и дальше пачку нудной, но нужной работы. Если ему это действительно нравится, то может ему это и не надо.
Но если необходимо будет разрабатывать что-то более масштабное и серьезное, то придется взаимодействовать больше, чем с одним разработчиком. Придется описывать архитектуру, схемы взаимодействия сервисов или еще каких-то компонент. А этого без умения хорошо коммуницировать, умения описывать, представлять не получится.

Не соглашусь по поводу тестирования. Тестировать должны люди, далекие от программирования (разработки), иначе такое тестирование будет «предвзято»
Если это относится к пункту «Тестируй свой код сам», то он не означает, что в разработке не должно быть этапа тестирования, который проводят тестировщики. Тут с Вами согласен.
Подкорректировал комментарий к этому пункту в тексте. Про другое там хотел сказать. А именно о том, что разработчик должен передавать код на тестирование имея уверенность, что в текущих условиях он сделал всё необходимое, чтобы тестировщик отловил как можно меньше багов.
чтобы тестировщик отловил как можно меньше багов

Задача тестировщика — отлавить как можно больше багов
Sign up to leave a comment.