Почему у вас не получается программировать. Часть 2
Вокруг ИТ продолжает курсировать зашкаливающее количество мифов, а рынок труда превратился в конкретный цирк. Наверное, единственный способ хоть чуть-чуть сгладить безумие — это продолжать помогать новичкам преодолеть порог входа. А то они совсем уже дичь творить начали)) Короче, спустя 2 года - держите вторую часть заметки.
Я искренне советую новичкам вчитаться. Пусть даже за один раз переварить не получится. Вполне возможно, сэкономите время, нервы и деньги на учебу.
Содержание
Важная ошибка новичков.
Работа по алгоритму.
Как выглядит типичная работа программиста.
Почему так получилось?
А как тогда разрабы вообще работают?
Очень поверхностно — что теперь делать новичкам?
Важная ошибка новичков
Реально важная штука, которую начинающие как правило не осознают — в программировании нет полностью повторяющихся, шаблонных задач. Вообще.
А теперь надо объяснять, о чем я.
Работа по алгоритму
Объяснить проще на примере. И чтобы далеко не ходить, возьмем простой и всем знакомый. Как в очень упрощенном виде выглядит работа кассира?
Поздорвался -> пакет нужен? -> пропикал -> карта или наличка? -> досвидания.
Это алгоритм. Кассир один раз его запомнил, а затем повторяет для каждого следующего покупателя. И на следующий день так же. Эту работу можно условно назвать шаблонной, т.к. там есть алгоритм, шаблон. (Да, я в курсе, что кассиры делают еще кучу другой работы, но для примера достаточно)
В реальности алгоритм обычно сложнее. Там есть ответвления, условия. Да и просто неожиданности и человеческий фактор. Если наличка, то так. Если карта, то по-другому. А если пьяный покупатель дебоширит, то время импровизаций.
Но это все-таки алгоритм. И большая часть покупателей полностью впишется в шаблон: заберет покупки, пробурчит «спасибо» и отчалит, следующий.
Алгоритм может быть еще навороченнее и больше, с бОльшим количеством условий и «импровизаций». Например в работе бухгалтера. При этом в норме работа бухгалтера все-таки +/- повторяется - каждый месяц, квартал или хотя бы год.
И именно к такой работе привыкли многие люди. Они ожидают примерно такого расклада. А иногда даже не представляют, как может быть по-другому.
Мы еще готовы ожидать всякого внезапного от работы с людьми. Но от работы с кодом новички часто ждут четкости, точности и лютой стандартизированности. А зря.
Как выглядит типичная работа программиста?
Сегодня ты создаешь автоматическую отправку смс. Через неделю добавляешь к какой-то статистике возможность сохранить ее в эксель. Затем чинишь отвалившуюся оплату. А потом добавляешь новую фичу в ваш древний телеграм-бот.
И все эти задачи больше не повторятся, они одноразовые. Но будут другие, опять о чем-то новом.
При этом:
С смс ты раньше вообще никогда не работал(при опыте в несколько лет).
Статистику эту видишь в первый раз (но хотя бы сохранение в эксель раньше делал, три года назад, на другой работе, в совершенно другом проекте, где все по-другому).
Что там могло отвалилось в оплате, понятия не имеешь.
О существовании у вас телеграмм бота вообще не знал.
И естественно, никто тебе не покажет, как делать эту работу. Ни учителя в вузе, ни преподы на курсе, ни коллеги, ни начальник. Никто не сможет выдать тебе никакого полноценного алгоритма действий.
Здесь важный момент. Коллеги не будут рассказывать, не потому что ты уже должен знать. И даже не потому что злые. А потому что ты должен сам разобраться.
Еще штрих к картине: Со всеми этими вещами(статистика, смс и тп) ты можешь вообще не пересечься следующие год-два. Либо вообще не пересечься больше никогда, ни на одной работе. А даже если на следующей работе у тебя и будет телеграмм-бот, то от предыдущего он может отличаться как дельфин от жирафа. Ну хотя бы оба млекопитающие.
В реальности же программист вообще выкидывает нафиг из головы все подробности, как только закрывает задачу. При таком объеме проходящей через тебя инфы это здоровая защита) Даже если тебе через месяц прилетит задача на исправление бага в твоем же коде, ты не сразу въедешь. Каждый раз как в первый)
И вся эта движуха — при работе в одной компании, на одном проекте, на стабильной работе. Постоянно. Каждый день/неделю/месяц что-то новое. И никаких подробных объяснений.
Почему так получилось?
Надеюсь, теперь более-менее понятно, что я имею в виду, когда говорю «нет шаблонных задач». Теперь надо рассказать, почему так вообще вышло.
Здесь на самом деле все просто. Любая шаблонная работа в программировании автоматизируется моментально. Самими разрабами. За это и платят)
Если нужно создать 50 очень похожих телеграмм ботов, разраб не будет это делать руками. Он один раз напишет код, который позволит автоматически нагенерить хоть 50, хоть 500 ботов. В крайнем случае пишется код, который позволит менеджеру в пару кликов эти боты создавать. (Вы может видели конструкторы тг ботов. Вот, это именно оно)
Если нужно прикрутить сохранение из веба в эксель к 17-ти отчетам, оно не создается под каждый отчет отдельно. Один раз пишется софт, умеющий выгружать файлы. И потом просто подключается ко всем отчетам. А разраб скачет дальше, работать с какой-нибудь отправкой емейлов.
На более базовом уровне это вообще выглядит вот так: Если программист в трех местах воткнул в программу одинаковый код, строчек так на 15, к нему сразу возникают вопросы. Потому что в норме весь повторяющийся код сразу выносится в отдельный «кусок» (метод, функцию, класс, модуль, файл, библиотеку, фреймворк, что угодно) и потом просто используется везде, где нужно.
А тк задачи моментально автоматизируются, то они и не повторяются. А раз нет повторений, то каждая задача делается в первый и единственный раз. А значит, нет и никаких инструкций.
Поэтому не бывает такой работы в программировании, куда бы ты пришел, а тебе говорят: «нам нужно 15 одинаковых телеграмм-ботов в месяц». Ты говоришь «круто! Нас как раз на курсе учили». Потом коллеги объясняют тебе детали, всё показывают. И следующие два года ты пишешь только ботов.
Поэтому курсы типа «мы научим вас писать тг бот и парсер» часто бесполезны полностью.
А как тогда разрабы вообще работают?
Ок, но как жить совсем без нормальных инструкций? Когда даже на учебе их получить нереально.
Вкратце — программист и есть тот чел, который инструкции пишет. Только не для людей, а для компа. Банально, но на удивление не всем очевидно — любая инструкция не истина в последней инстанции. Она кем-то когда-то была создана. Ну вот и создаем.
Поэтому работа программиста заключается в том, чтобы решение изобрести. Это не означает изобрести что-то совершенно прорывное, новое или велосипед. Но для каждой конкретной задачи конкретное решение создается впервые. И только один раз. Потому что дальше оно работает «само», тк автоматизировано. А новая задача будет уже отличаться. Могут быть задачи на так называемую доработку. Но они тоже означают «придумать, изобрести, как добавить сюда новые фичи».
Программист почти никогда не знает заранее и точно, как он будет выполнять свою работу. Если опытный — то примерно конечно представляет. Но в любой момент может вывалиться любая неожиданная дичь даже в самой банальной задаче. Потому что конкретно эта задача делается в первый раз.
Поэтому, кстати, разрабы частенько называют сроки в стиле «от двух часов до двух недель». Или говорят, что могут назвать примерные сроки только после того, как часа два(дня два) поработают над задачей. А потом эти сроки регулярно продалбывают, потому что дичь все-таки вывалилась. Особенно, если код древний.
И именно поэтому коллеги не дадут тебе инструкций. Потому что готовой у них нет, а придумать для тебя алгоритм действий — это значит буквально сделать за тебя всю работу. Нафига тогда тут ты?)
Конечно, у программистов тоже есть рутина и свои шаблоны. Но это обычно на уровне «лучшие практики», «архитектурные паттерны». В лучшем случае туториал, из которого для твоей задачи сработает процентов 70.
Это и близко не про «нажимаешь сюда, потом сюда. Здесь делаешь так, а здесь вот так. Эту задачу надо решать вот так, а эту вот эдак». Короче, понимание рутины заметно отличается от бытового. И понимание шаблонов тоже)
Очень поверхностно — что теперь делать?
Совсем кратко — учиться изобретать. Так себе совет, конечно. Но пошаговый план дать не могу, тк... ну вы поняли) Научиться изобретать можно только на практике, изобретая что-нибудь. Не повторяя за другими, а делая что-то простое, но своё.
Умение изобретать, кстати, включает в себя умение не изобретать велосипеды) Нужно учиться использовать готовые инструменты. И понимать, когда лучше готовый инструмент, а когда писать своё. Но опять же — решать это вы должны сами, тк это вы пишите инструкцию.
Нужно учиться именно создавать свои, новые решения. Не учиться решать задачи какого-то типа. Потому что типовых не будет.
Без этих навыков не стоит идти даже на стажера.
База, конечно, нужна. Для этого подойдут первые уроки любого бесплатного курса. Зубрить не надо, но простые понятия можно в голову залить заранее. Про архитектуру можно почитать, но в самом начале вы всё равно ничего не поймете. Это уже следующий этап. Без него можно остаться говнокодером, но спешить закапываться в архитектуру тоже не надо.
А дальше один из самых действенных способов — придумать себе простой проект и начать его делать. Только не тот, который можно буква в букву скопировать из туториала.
Если вы сделали по туториалу калькулятор и у вас всё с первого раза запустилось — вы ничему не научились. Это не имеет отношения к реальной работе.
А вообще, лучше самостоятельно определять, что и в каком порядке учить. Т.к. умение это делать — тоже часть навыка создавать собственные инструкции. Так что тренируйтесь)
Про то, как учиться работать без инструкций и не пугаться, я наверное когда-нибудь еще напишу. Но на сегодня хватит)
Если возникли вопросы — это хорошо, спрашивайте в комментах
