Советы начинающим программистам

В этой небольшой статье я хочу поделиться советами, которые я бы дал самому себе 10+ лет назад, когда начинал свой карьерный путь. Для кого-то все это может показаться очевидным, но я слоупок и до меня доходило долго.

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

Когда продумываешь и программируешь алгоритм ты описываешь действия, которые бы сделал человек для достижения результата, а машина их лишь повторяет. И когда на чем-то застреваешь подумай, а что бы сделал человек, ты в частности. Не смотря на то, что это прям основа программирования, я часто об этом забывал

За годы работы в разных коллективах я вынес для себя одну простую истину: люди, с которыми ты работаешь — это драгоценность. Почему? Потому что они помогают тебе расти. Когда мое мнение не совпадало со мнением коллеги и я был уверен, что я прав, я начинал быстро раздражаться. Это очень неправильный подход. Намного лучше сохранять спокойствие и искать аргументы. Если ты сможешь квалифицированно аргументировать свою позицию, это поможет тебе повысить свою квалификацию и получить уважение со стороны коллег, а это важно. Особенно хорошо, если поиск аргументов покажется сложным. Если же выяснится, что ты оказался неправ, так даже лучше, ибо ты вынесешь для себя ценный урок и тоже сможешь повысить свою квалификацию. Не можешь же те быть вечно правым в конце концов)) Коллеги могут иметь иное видение и это очень хорошо. Учись у них. Они — самые лучше учителя.

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

Когда решаешь задачу, помни, что ты решаешь вполне конкретную бизнес задачу, а не просто программируешь шарообразного коня в вакууме. Представь себя на месте конечного пользователя и владельца или менеджера продукта и ты поймешь что ты делаешь и зачем.

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