о влиянии опыта и знаний в программировании. не является руководством к действию, а только набор мыслей, которые могут быть полезны начинающему/среднему программисту

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

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

отсюда выходит фактор того, что программисты в целом ближе к узким специалистам по конкретным технологиям. отсюда и проблема найти "толкового" программиста, где за толковостью по мнению работодателя стоит набор знаний по конкретным технологиям, но поскольку наборов этих бесконечное количество, то и найти соответствующего нужному набору тяжело.

как же учиться программисту и быть хорошим в этом деле?

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

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

это рождает массу проблем - например, боязнь трогать код, боязнь улучшать/расширять, появление привычки к херовым решениям, неповоротливость кода рождает отсутствие прогресса и желания улучшать программу, и прочие проблемы. но главное - сам факт наличия слепого пятна. это главный корень проблемы - непонимание инструмента/применённой технологии/синтаксиса. когда это 1-2 момента это не страшно, когда их сотни в программе это плохо.

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

как уже указано, количество технологий и вариантов знаний колоссальное, всего знать невозможно, как же с этим быть?

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

какой совет на тему слепых пятен?

видишь/чувствуешь спепое пятно - записал конкретный код, имя технологии, имя конкретного файла/ситуации себе в 2do лист, в отдельный список. время от времени этим списком нужно заниматься. доставать конкретные вопросы и изучать их вдоль и поперёк. также время от времени во время поездок домой, я могу в поездке сидеть и разбирать конкретную фишку.

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

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

есть аналогия с образом жизни. парень 1 - после работы вваливается на диван, под пиво смотрит телевизор. парень 2 - после работы читает литературу, идёт на прогулку. что изменит 1 день разницы? ничего. месяц? также ничего. но гарантированно то, что мелкие шажки к успеху у парня 2 приведут через несколько лет к разнице, которая заметна как внешне, так и в уровне жизни/квалификации/деньгах/в карьере.

вывод - заниматься по чуть-чуть, но постоянно это путь, который рано или позно приведёт к успеху

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

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

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

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

на тему важности иметь 2do листы, списков задач, инструкций думаю не имеет смысла писать, это само собой разумеющееся, как и их постоянное сопровождение.

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

к вопросу опыта - многое из применённого ранее забывается, так или иначе объёмы знаний просто конские и помнить применённое 10 лет назад в идеальном виде нельзя. но такой "длинный" опыт помогает однозначно в ориентировании на тему как решать конкретную задачу. наличие общих знаний "вот это делается при помощи этого, это примерно так, тут применяю это" позволяет достаточно быстро приступить к решению задачи.

из полезного в копилку программиста - писать по нотации, не писать длинные функции, длинные строки, по возможности избегать большой вложенности - соответственно распределять по коду, такая привычка невероятно сильно помогает при чтении своего кода через некоторое время, плюс упрощает разработку и сопровождение, поскольку всё это позволяет легче понять, чем занимается конкретный код. чтобы написать сложный и нечитаемый код, много ума не надо. где-то вычитывал фразу на подобие "надо заботиться о том мудаке, который будет сопровождать этот код после тебя через года, потому что этот мудак ты сам".

более лёгкие и понятные решения практически всегда выигрывают сложные и нечитабельные.

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

также проблемно то, что есть авторы, которые философскими рассуждениями убивают полезность книги. например, Страуструп в одной из книг по плюсам отводит гигантские стены текста на рассуждения а почему в си вот так, а в плюсах вот так. хорошо помню, что взявшись за эту книгу года 4 назад, прочитав 200 страниц книги, я понял простую вещь - автор ещё ничего не сказал о том, как надо писать, с чего начинать, о базовых знаниях. в итоге книгу отложил. несомненно, там закопаны некие полезные знания, но следует подбирать рациональные пути обучения. читать сотни страниц и получить песчинку знаний - нерационально.

также стоит отметить, что не стоит кидаться на гиганские проекты со сложным кодом. лучше начинать с проектов простых, на их базе делать средние и на базе средних делать крутые/большие проекты. в общих чертах - следующий успех нужно делать на основе предыдущего. к чему-то большому надо придти вовремя с нужной дистанцией и знаниями. Дуров как-то писал, что при написании вконтакте, у него в базе была работа над форумом спбгу и это было очень важно. и действительно, некая скриптовая база, некая база работы с html, приёмы работы с проблемными местами, настройка/сопровождение сайта, работа с публикой. казалось бы тот сайт это ещё 1 из 9021482947832 сайтов, однако это были крайне важными базовыми знаниями. поэтому не нужно стесняться делать задания попроще и затем дорасти до стоящих заданий. даже малые проекты - опыт, а это очень важно в программировании.

одно из последних к этой теме. нужно изначально привыкать делать задачу максимально самостоятельно, самообучаться, не бояться нового. приобретать навыки, чтобы стать самостоятельным специалистом. как показывает практика, в коллективах программистов есть те, кто тащит тематику, а есть те, кто ждут готовых программных решений, конкретных настроек и консультаций. другими словами, одни тащат задачу, других надо подпинывать. ценность первых намного выше, поскольку если кинуть их в неизвестный проект со своим окружением - они уже привыкли тащить и разберутся быстро, у ведомых будут проблемы - поскольку вряд ли кто-то их втащит и всё объяснит, покажет, да и собственно расслабившись можно обнаружить, как крайне тяжело "собраться" назад и снова тащить совершенно новую тему. лучше быть в тонусе и не бояться нового.

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

не стоит бояться негативного опыта, как ни странно именно негативный опыт самый ценный. и не стоит бояться выкинуть неудавшийся конкретный элемент проекта в мусорку, нужно уметь расставаться с плохим решением, даже если было вкинуто много времени и сил.

возможно, очевидно, но многие вещи в программировании становятся ясны далеко не сразу и даже не с первого десятка итераций. если что-то не получается понять это нормально, просто нужно время.

добавлю: опыт ещё сильно влияет на уверенность и мотивацию. если конкретная технология была применена и она получилась, пускай это и было 5 лет назад и конкретика давно забылась, то сев за подобную задачу, обнаруживаешь, что поскольку раньше подобное решал, имеешь сильную уверенность, что оно точно получится. соответственно быстрее приступаешь к задаче и быстрее решаешь. поэтому также важно иметь широкий стек технологий, один факт того, что когда-то это применил, оказывает крайне положительное воздействие.

простой пример - сохранение данных и чтение потом из хмл. если не делал это раньше, то там масса вопросов - а как это читается, как сохраняется, нет ли сбоев, как открывается файл, какой объект читалки/писалки, какой перебор. и стартовать труднее. однако если это делал раньше и пускай давно, то в памяти сохранится - уже такое делал, ничего сложного. и на фоне мыслей "это получалось, было легко" процесс движется намного быстрее. уверенность в подобном плане сильно завязана на опыт применения конкретной технологии.