Заметил? Многие, кто только начал изучать программирование, сразу ныряют в сложные штуки и пытаются прыгнуть выше головы.
Вдохновились историями успеха, открыли IDE, думают: "Ща бахну свой какой-нибудьgram".
Проходит пять минут - в гугл летит первый запрос: "why number is a string?".
А в голове: "Может, всё-таки крипта?".
Я через это проходил.
И чтобы не сгореть на старте, не чувствовать себя потерянным и не бросить все на середине, я собрал 7 советов, которые действительно помогают.
А если хочешь те же советы, но с мемами, щепоткой иронии и айтишной тоской - загляни в видео.
___
Совет №1 - Сначала фундамент, потом фасад
Никто не просит читать весь список по версии "старцев IT", но фундамент под ногами все-таки нужен.
Смотри…
Вот ты решил стать разработчиком. Открыл YouTube, набрал "сделать первое приложение" - и сразу такой: "Ща быстро натискаю код, запилю проект в портфолио и через месяц буду собеседоваться в Ху_ндекс".
Спойлер: не будешь!
Ты идешь не по дороге, а по картонной декорации дороги. С виду - прямолинейно, а под ногами - пустота. Ты можешь сколько угодно тянуть обертки поверх оберток, но как только начнут копать - ты превратишься в вежливого NPC: “Ну…потому что…ну так в гайде было.”
И вот тут весь твой красивый фасад трещит по швам.
Потому что проект это конечно круто, но без понимания, зачем ты сделал именно так, ты не разработчик. Ты просто актер, играющий роль программиста по чужому сценарию.
В общем и целом: Хочешь строить небоскребы - сначала научись копать яму.
___
Совет №2 - Пиши код, который сам себя объяснит
Пиши код так, чтобы через пару дней ты сам понял, что хотел сказать.
Сейчас может казаться, что все просто класс. Но через пару дней? Или недель? Или когда у тебя в проекте уже 30 файлов? Ты сам не вспомнишь, что выполняет функция "doIt()"? Вот тут начинается веселье.
Не надо знать английский на уровне поэта, чтобы писать понятные имена.
Достаточно запомнить 20 существительных и 20 глаголов, чтобы не создавать в проекте “fooBarXyz” и “doSomething123”.
Если в коде даже одна переменная с глупым именем - это как разбитое окно в подъезде. Сначала мелочь. Потом разбитое окно в другом месте. Потом проект начинает разваливаться, и все теряют смысл.
Подробнее о Теории разбитых стекол можно прочитать в telegram.
В итоге - куча костылей, багов и бессмысленных комментариев типа “поправлю потом”.
Итог: заводи себе привычку писать осмысленно и аккуратно с самого начала. Это сэкономит твои нервы и время, а коллегам - глаза.
___
Совет №3 - Запоминай главное
Не пытайся запомнить все подряд. Не нужно становиться живой энциклопедией, это ловушка для мозга. Достаточно знать, что нужное свойство или метод вообще существуют.
Представь, что ты на кухне - ты не помнишь, где лежит каждая специя, но знаешь, что они есть. Когда понадобится - быстро найдешь и добавишь в блюдо.
С кодом так же: не надо ломать голову, пытаясь запомнить все. Главное - помнить, что нужный инструмент рядом, и при первой же проблеме просто найти его в гугле или при помощи ИИ.
Код - умение в нужный момент достать из головы то, что нужно, и не сойти с ума. Так что забудь зубрежку и учись решать задачи, а не пытаться держать все в голове.
___
Совет №4 - Копипаст - не грех
Гуглить - такой же скилл, как и писать код.
Забудь про стыд копипастить. Это не грех, а спасение.
Вот только если в поиске ты напишешь "У меня не работает" - даже самая продвинутая ИИшка пожмет плечами и скажет: "Ну, а что именно то?"
В программировании половина дела - научиться правильно спрашивать, а не слепо жмякать по кнопочкам. Так что не бойся формулировать вопросы четко, гугли с умом, копипасть без паники и спрашивай, когда тупишь. Потому что знать, как и что искать - уже почти как знать сам код.
___
Совет №5 - Сложно? Уточни, что именно
Когда в коде начинается квантовая запутанность, и ты чувствуешь себя так, будто попал внутрь адронного коллайдера - не паникуй. Да, там все сверкает, что-то сталкивается, и вообще страшно. Но давай по-честному: ты ведь знаешь, что там есть протоны и ионы?
Вот! Уже не так все и непонятно. Остается просто уточнить: "а что именно вызывает ступор?", "зачем они сталкиваются?", "почему круг?", "где вообще у этого устройства кнопка "включить"?".
С кодом та же история. Не надо орать "я ничего не понимаю" и бросаться в туман. Сядь и скажи себе: "Так. Вот тут строчка. Вот здесь метод. Вот это вызывает вопрос". Как только ты называешь проблему по имени - она теряет половину своей силы. Остальное - дело техники. Ну и гугла.
___
Совет №6 - Сложные слова и решения ≠ умный код
Если ты называешь переменную "DataProcessorManagerHandler", а сам не помнишь, что она делает - ты просто играешься в программиста и пытаешься замаскировать свое творчество под продуманный код.
А если добавить в код тройной if внутрь замыкания - "потому что так мощнее", - ты не ускоряешь приложение, ты ускоряешь свою боль в будущем.
Настоящая сила - в простоте. Код должен быть понятным, читаемым и предсказуемым.
Хитрость не в том, чтобы спрятать смысл за конструкциями, а в том, чтобы сделать сложное очевидным.
___
Совет №7 - Не женись на первом варианте
В программировании нет святого грааля. Один и тот же результат можно получить десятью разными способами, а также через костыль и через костыль в костыле.
Первое что попадется - не обязательно лучшее. Это просто первое, что ты нагуглил.
Не ленись попробовать по-другому. Напиши код двумя способами, сравни, подумай, а не просто "лишь бы работало".
Оптимальность - это не про магию. Это когда просто, понятно и не разваливается при первом изменении.
Пока ты учишься, у тебя идеальное время экспериментировать. Пользуйся этим. Потом будет прод. А там - только боль и страх.
___
Вот ты и добрался до конца.
Запомни: фундамент это не скучный камень на дороге, это твоя страховка от падений.
А фасад - это уже потом, когда ноги не дрожат.
Комментарии (25)
vzvzvz
19.06.2025 08:48Когда смотрю советы современным начинающим программистам, вспоминаю свое детство. В нем не было крутых современных IDE и графического интерфейса из коробки. Начинать приходилось с простейших задач, так как не было интернета и гугла. Была книжка, реже 2-3.
Порог вхождения мог казаться высоким, но ты знал, что ты хочешь сделать. Было и огромное желание это сделать.
Современные гайды говорят об обратном - многие начинающие не знают, чего они хотят, не смотря на упрощение входа в специальность.
yaSkazalGorbatiy Автор
19.06.2025 08:48Все течет, все изменяется :)
Сомневаться это нормально. ИТ перестало быть для "гиков". Теперь это обычная профессия.
dv0ich
19.06.2025 08:48С другой стороны, тогда IT-знаний было тупо меньше в разы, а то и на порядки.
Сравните С++ в 90-х годах и сейчас. Сравните веб, количество технологий для него))
Сейчас и железо стало довольно сложным, приходится обращать внимание на большее количество нюансов при сборе.
Ну и да, тогда в IT было на порядки меньше людей и можно было чувствовать себя одним из первых (как на диком западе или в открытом космосе, кто как воспринимал), это охренеть как мотивировало и создавало чувство общности. Сейчас человек берётся за IT, уже видя как дохрена людей в этой индустрии, как много в ней топовых специалистов всех сортов, и как жёстко придётся с ними всеми конкурировать. Это знатный такой дебаф к мотивации.
vzvzvz
19.06.2025 08:48О том, что всё это называется IT, я узнал в начале двухтысячных или незадолго до.
Технологий и правда было меньше. Вернее, надстроек над технологиями, большинство из которых уже успело появиться к 1995.
AndrewBond
19.06.2025 08:48Самое классное время в программировании - когда ты программируешь так, как думаешь. Нужно сложить два и два, ты просто складываешь, нужно принять решение - просто пишешь if и тд.
Потом наступает время, когда сначала нужно наделать абстракций, интерфейсов, а твой код тонет в бесконечных вызовах api, фреймворках и тд.yaSkazalGorbatiy Автор
19.06.2025 08:48Жаль в тот момент ты этого не понимаешь :)
AndrewBond
19.06.2025 08:48Это да. Но, у меня недавно второй заход был, когда запустил Cursor. Вот это "с первого раза написать промпт, чтобы оно сделало то, что надо" это было близко к тем самым первым чувствам :)
Emelian
19.06.2025 08:48КАША в голове, КАША в коде — первые шаги к порядку
Любовь к разговорам «вообще», это, пожалуй, наша национальная особенность.
Неужели начинающим программистам нельзя дать более дельных советов? Например:
Нельзя объять необъятное.
Это значит, будьте конкретны в своих желаниях. Допустим, по программированию вы выбрали направление С++ и программирование с использованием пользовательских интерфейсов.
Программирование – иерархично. Сначала проект, потом прототип, потом версии программы.
Главное в разработке – программная логика, для моделирования которой удобно использование древовидной иерархии классов, в связке с менеджером видов (другими словами, дочерних окон), менеджером потоков и менеджером событий.
Выберите интересующий вас класс задач и напишите для него общий прототип.
Например, для себя я выбрал тему: «Управление видами для SDI-приложений, на базе C++ / WTL». Имеется в виду, использование перегружаемых («последовательных») видов (см. мою статью: https://habr.com/ru/articles/848836/ ) либо применение «параллельных» видов, с использованием многопоточности, для встроенного видео (см. скриншот моей неопубликованной программы «МедиаТекст»: http://scholium.webservis.ru/Pics/MediaText.png ). Другие варианты похожих задач пока в разработке. Надеюсь, со временем, рассказать и о них.
Используйте итерационное программирование.
Каждая новая итерация это копия предыдущего проекта плюс реализация какого-нибудь класса. Отдельные классы удобно хранить в отдельных файлах. Для внешних классов (и прочего опенсорсного кода) лучше использовать отдельные каталоги.
Разные итерации одного проекта должны иметь общий доступ к неизменяемому коду, вроде, опенсорса.
Нужно стремиться к тому, чтобы новый программный модуль можно было бы, как легко подключить, так и легко отключить. Соответственно, изменить старый модуль на новый.
Документируйте изменения во всех итерациях.
Это позволит, со временем, обосновать фразу: «Неужели этот код я написал?». И что, именно, делает эта программа?
Различные задачи, используемого класса задач, должны иметь общий прототип, как выбранный дебют в шахматах.
Оформляйте код «красиво». Не ленитесь быть аккуратными и не забывайте о комментариях.
Чтобы про вас не злословили:
«Программист Вася Пупкин и аккуратность – не близнецы-братья. Мы говорим «аккуратность», но не подразумеваем программиста Васю Пупкина! Мы говорим «программист Вася Пупкин», но не подразумеваем аккуратность!»
Как-то так. Это пока полуфабрикат мыслей, иначе я бы написал статью на эту тему…
vvbob
19.06.2025 08:48С кодом так же: не надо ломать голову, пытаясь запомнить все. Главное - помнить, что нужный инструмент рядом, и при первой же проблеме просто найти его в гугле или при помощи ИИ.
Код - умение в нужный момент достать из головы то, что нужно, и не сойти с ума. Так что забудь зубрежку и учись решать задачи, а не пытаться держать все в голове.
Совет N: Но на собесе это не прокатит, поэтому зубри
amazingname
19.06.2025 08:48Вот ещё советы.
Программирование состоит из двух разных навыков. Навык правильно использовать фреймворки и архитектурные решения с ними связанные это один навык. Навык самому на пустом месте написать программу с логикой в несколько тысяч строк и не начать тонуть это другой навык. Первый обязателен, но в итоге потребуются оба.
Пока вы один, не на работе и учитесь, пишите подобные комментарии. Не нужно лицемерия про само описываемый код. Этот навык придет не скоро, если это не тупой crud. Потом в команде пробуйте писать без комментариев.
Начните новую фитчу по старинке с юз-кейзов. Выпишите сценарии, придумайте для них примерную архитектуру и начните писать код для какого то кейза постепенно реализуя и проясняя архитектуру.
Не увлекайтесь сильно ООП, пока нет ощущения зачем оно, чтобы не было карго культов. Пока нет ясного понимания что в конкретном случае нужно ООП, пусть будут функции или просто процедурное программирование с немного god объектами. Потом чтобы это все стало яснее, попробуйте применять ООП. Стало только хуже? Теперь все совсем запутано? Значит рано. Надо ещё учиться
Прежде чем реализовывать что-то напишите комментарий как это будет работать. Когда напишите код, удалите эти комментарии. Не нужно думать кодом. Лучше думать словами.
В момент когда код частично заработал, обязательно пройдитесь каждый шаг дебагером, размышляя о соответствии замыслу. Так можно вовремя понять что что-то нужно улучшить.
Если перестаёте понимать что это будет, останавливайтесь и придумывайте "теорию" и абстракции как это систематизировать. Но придерживаться найденной концепции будет чем дальше тем сложнее. Искусство в том, чтобы придумывать эффективные простые концепции и чувствовать баланс - когда нужно просто делать чтобы работало а когда изобретение ограничивающих концепций окупиться.
Если вы уже начали вайб-кодить, все эти советы никоим образом не теряют актуальности!
MountainGoat
Имхо, на старте важно изучающему дать возможность сделать что-то, выглядящее закончено, полезно. А не все эти надуманные "напишите консольную программу по учёту мешков картошки в подвале".
Поэтому я ученику сходу дам законченную программу с интерфейсом, научу её компилировать, и скажу "свой код вписываешь сюда. Теперь о том, что такое переменная..." Чтобы у него результат был не из 1980х.
yaSkazalGorbatiy Автор
Согласен. Это мотивирует продолжать обучение!
Действую по такому же принципу: сначала собираю с ребятами простое приложение (макет), примерно объясняя что как работает и для чего используется.
Плюсы:
- приложение используется в дальнейшем обучении для составления спринтов (для самого себя, но появляется некое понимание о дейликах, демо и ретро).
- это не просто приложение из стора. Ты собрал его сам (ну или почти сам :) ).
- при изучении проще понимать, где может использоваться та или иная конструкция.
- дает более широкий взгляд на разработку.
Минусы:
- можно заиграться и "вслепую" пытаться делать "что-то свое" на имеющейся основе, пропуская фундаменталку.
dv0ich
Лучше взять какую-нибудь насущную задачу пользователя (ученика) и решить её написанием программы. Например, у него кончается место на диске - пусть напишет утилиту, которая анализирует занятое место, ищет дубликаты, определяет нужность файлов, и т.д.
MountainGoat
Тоже хорошо, я просто туториал писал, поэтому у меня ученик гипотетический.
yaSkazalGorbatiy Автор
Согласен. То, что пригодится самому, писать гораздо приятнее и интереснее.
В "советах" я больше нацелен на людей, которые только изучают фундаменталку.
А приложение - для тех, кто хочет просто понять, нравится ли ему работать с кодом.