Vit.shnik

На Пикабу
141 рейтинг 1 подписчик 0 подписок 3 поста 0 в горячем
11

Почему у вас не получается программировать. Часть 2

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

Содержание
Важная ошибка новичков.
Работа по алгоритму.
Как выглядит типичная работа программиста.
Почему так получилось?
А как тогда разрабы вообще работают?
Очень поверхностно — что теперь делать новичкам?

Важная ошибка новичков
Реально важная штука, которую начинающие как правило не осознают — в программировании нет полностью повторяющихся, шаблонных задач. Вообще.
А теперь надо объяснять, о чем я.

Работа по алгоритму
Объяснить проще на примере. И чтобы далеко не ходить, возьмем простой и всем знакомый. Как в очень упрощенном виде выглядит работа кассира?
Поздорвался -> пакет нужен? -> пропикал -> карта или наличка? -> досвидания.

Это алгоритм. Кассир один раз его запомнил, а затем повторяет для каждого следующего покупателя. И на следующий день так же. Эту работу можно условно назвать шаблонной, т.к. там есть алгоритм, шаблон. (Да, я в курсе, что кассиры делают еще кучу другой работы, но для примера достаточно)
В реальности алгоритм обычно сложнее. Там есть ответвления, условия. Да и просто неожиданности и человеческий фактор. Если наличка, то так. Если карта, то по-другому. А если пьяный покупатель дебоширит, то время импровизаций.
Но это все-таки алгоритм. И большая часть покупателей полностью впишется в шаблон: заберет покупки, пробурчит «спасибо» и отчалит, следующий.
Алгоритм может быть еще навороченнее и больше, с бОльшим количеством условий и «импровизаций». Например в работе бухгалтера. При этом в норме работа бухгалтера все-таки +/- повторяется - каждый месяц, квартал или хотя бы год.

И именно к такой работе привыкли многие люди. Они ожидают примерно такого расклада. А иногда даже не представляют, как может быть по-другому.
Мы еще готовы ожидать всякого внезапного от работы с людьми. Но от работы с кодом новички часто ждут четкости, точности и лютой стандартизированности. А зря.

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

При этом:
С смс ты раньше вообще никогда не работал(при опыте в несколько лет).
Статистику эту видишь в первый раз (но хотя бы сохранение в эксель раньше делал, три года назад, на другой работе, в совершенно другом проекте, где все по-другому).
Что там могло отвалилось в оплате, понятия не имеешь.
О существовании у вас телеграмм бота вообще не знал.

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

Еще штрих к картине: Со всеми этими вещами(статистика, смс и тп) ты можешь вообще не пересечься следующие год-два. Либо вообще не пересечься больше никогда, ни на одной работе. А даже если на следующей работе у тебя и будет телеграмм-бот, то от предыдущего он может отличаться как дельфин от жирафа. Ну хотя бы оба млекопитающие.
В реальности же программист вообще выкидывает нафиг из головы все подробности, как только закрывает задачу. При таком объеме проходящей через тебя инфы это здоровая защита) Даже если тебе через месяц прилетит задача на исправление бага в твоем же коде, ты не сразу въедешь. Каждый раз как в первый)
И вся эта движуха — при работе в одной компании, на одном проекте, на стабильной работе. Постоянно. Каждый день/неделю/месяц что-то новое. И никаких подробных объяснений.

Почему так получилось?
Надеюсь, теперь более-менее понятно, что я имею в виду, когда говорю «нет шаблонных задач». Теперь надо рассказать, почему так вообще вышло.

Здесь на самом деле все просто. Любая шаблонная работа в программировании автоматизируется моментально. Самими разрабами. За это и платят)
Если нужно создать 50 очень похожих телеграмм ботов, разраб не будет это делать руками. Он один раз напишет код, который позволит автоматически нагенерить хоть 50, хоть 500 ботов. В крайнем случае пишется код, который позволит менеджеру в пару кликов эти боты создавать. (Вы может видели конструкторы тг ботов. Вот, это именно оно)
Если нужно прикрутить сохранение из веба в эксель к 17-ти отчетам, оно не создается под каждый отчет отдельно. Один раз пишется софт, умеющий выгружать файлы. И потом просто подключается ко всем отчетам. А разраб скачет дальше, работать с какой-нибудь отправкой емейлов.
На более базовом уровне это вообще выглядит вот так: Если программист в трех местах воткнул в программу одинаковый код, строчек так на 15, к нему сразу возникают вопросы. Потому что в норме весь повторяющийся код сразу выносится в отдельный «кусок» (метод, функцию, класс, модуль, файл, библиотеку, фреймворк, что угодно) и потом просто используется везде, где нужно.

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

Поэтому не бывает такой работы в программировании, куда бы ты пришел, а тебе говорят: «нам нужно 15 одинаковых телеграмм-ботов в месяц». Ты говоришь «круто! Нас как раз на курсе учили». Потом коллеги объясняют тебе детали, всё показывают. И следующие два года ты пишешь только ботов.
Поэтому курсы типа «мы научим вас писать тг бот и парсер» часто бесполезны полностью.

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

Поэтому, кстати, разрабы частенько называют сроки в стиле «от двух часов до двух недель». Или говорят, что могут назвать примерные сроки только после того, как часа два(дня два) поработают над задачей. А потом эти сроки регулярно продалбывают, потому что дичь все-таки вывалилась. Особенно, если код древний.
И именно поэтому коллеги не дадут тебе инструкций. Потому что готовой у них нет, а придумать для тебя алгоритм действий — это значит буквально сделать за тебя всю работу. Нафига тогда тут ты?)

Конечно, у программистов тоже есть рутина и свои шаблоны. Но это обычно на уровне «лучшие практики», «архитектурные паттерны». В лучшем случае туториал, из которого для твоей задачи сработает процентов 70.
Это и близко не про «нажимаешь сюда, потом сюда. Здесь делаешь так, а здесь вот так. Эту задачу надо решать вот так, а эту вот эдак». Короче, понимание рутины заметно отличается от бытового. И понимание шаблонов тоже)

Очень поверхностно — что теперь делать?
Совсем кратко — учиться изобретать. Так себе совет, конечно. Но пошаговый план дать не могу, тк... ну вы поняли) Научиться изобретать можно только на практике, изобретая что-нибудь. Не повторяя за другими, а делая что-то простое, но своё.

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

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

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

Показать полностью
26

Реверс-медицининг

Полистал тут ради прикола рандомный учебник для студентов меда. Такая жесткая смесь реверс-инжиниринга и алхимии.
У них там с документацией еще хуже, чем у нас. В ИТ она либо хреновая, либо отсутствующая, но на медицинском она походу выглядит вообще вот так:

«Регистрация нового пользователя.
Юзеросплазии приложения — это состояние приложения, характеризующееся появлением в системе нового юзера.

Юзероплазии приложения могут быть первичными, т.е. самостоятельным явлением и вторичными — т.е. проявлением какого-либо другого заболевания, например болезней маркетинга (акциотикулы, рефералиты, грыжа рекламного банера).

Основными симптомами первичной юзерплазии приложения являются:

- номеразия – появление номера телефона в форме регистрации;
- спазм ограниченных участков логов;
- ощущение «запроса к серверу» - возникает при нажатии на кнопку «зарегистрироваться» и часто сопровождается выраженной номеразией….»

И так 18 томов. И про код ни слова. Исходников нет, вообще, никаких. И доступа к базе нет. Есть только обрывки левого кода на ассемблере и фортране, которые они называют химией и микробиологией.

Врачей зауважал еще больше, а болеть стало еще страшнее

12

Почему у вас не получается программировать

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


Имхо, есть два момента, о которые спотыкаются новички:

1) неумение разбираться с новыми инструментами на ходу.

2) неумение упрощать код, делать красиво и выстраивать архитектуру.


Хорошая новость: оба пункта про умения. Их реально развить, в разумные сроки. Плохая: развивать все-таки придется, и это работа.

Т.е. суть не в знании языков, фреймворков и прочих технологий. Суть в навыках. Когда они есть, инструменты ты освоишь. Зачастую курсы учат именно технологиям, а не навыкам, и поэтому не работают. Точнее, помогают тем, у кого и так получается кодить. И не работают для всех остальных.


А теперь подробнее по первому пункту. Текста получилось достаточно дофига, поэтому распишу только его. Если второй момент интересен, дайте знать.

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

А точнее, про способ их осваивания.


Сначала опишу, как многие привыкли учиться:

Сперва тебе рассказывают теорию. Потом всучат швейную машинку/станок/программу. Показывают пошагово, как этим пользоваться. Ты повторяешь. Дальше твоя задача год за годом совершенствоваться и становиться мастером, который с закрытыми глазами может фигачить на условной швейной машинке что угодно.

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


Сначала - почему так, потом — что с этим делать.

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


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


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

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


Окей, что с этим делать. В первую очередь: не пытаться все зазубрить и запомнить. Забить на попытки найти «фундаментальный талмуд всего», который тебе объяснит программирование целиком. Нет сейчас таких талмудов. Кто-то справедливо писал, что если в ит ты читаешь книгу, то она устарела на полгода. Если книга в бумаге — на пару лет. Основное наше чтиво — это статьи по самым разным сайтам.

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

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


Второе, что стоит сделать: осознать, что прогеры сейчас работают в режиме машины по перевариванию информации. Тебе упала задача. Ты раскапываешь, какой инструмент тебе нужен для ее решения. Раскапываешь туториал к нему. Бегло осваиваешь. Решаешь задачу. И выбрасываешь это нафиг из головы, потому что завтра будет то же самое. Оперативную память нужно очищать.

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

(я везде пишу просто «инструменты», потому что это может быть что угодно. Фреймворки, библиотеки, бд, системы контроля версий, сервисы очередей и любая другая любимая дичь)


В общем, не нужно боятся этого хаоса, не нужно пытаться его систематизировать, а вот научиться ориентироваться в нем — нужно.

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


Хорошо, но если не пытаться учить фундаментальные талмуды, тогда что делать?

Прокачивать навык осваивания инструментов на лету. Это третье и главное.

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


Теперь совсем вкратце, порядок действий:

- пошел, бегло прогуглил непонятное слово. Прикинул, о чем речь. НЕ нужно на этом этапе читать документацию на 500 страниц на английском. Даже если на форуме тебе снобы скинули на нее ссылку :) НЕ нужно тем более ничего зубрить.

- нашел какой-нибудь туториал. В нем нашел небольшой пример кода. Желательно понимать в нем процентов 50-70. Если вообще не ничего понятно, ищи другой. Если понятно 50-70%, остальное пока игнорируем. Да, игнорируем.

- Сtrl+c, ctrl+v. Запускаешь. Скорее всего, оно крашнется. И поехали: смотришь, с какой ошибкой крашнулось. Гуглишь ошибку. Копируешь найденный код, вставляешь. Запускаешь. Крашнулось с новой ошибкой. Это прогресс. Радуешься, гуглишь новую ошибку. Сtrl+c, ctrl+v. Запускаешь. Выводишь значения переменных. Запускаешь - смотришь, че в них. И так, по одной строчке разбираешь код, пока он не заработает.


Еще раз: да, вот все те программисты с сильно трехзначными зарплатами большую часть времени занимаются примерно вышеописанным. Вот так неромантично.

Конечно это в общих чертах. Надо бы расписать подробнее и на конкретном примере, но текста и так много. Постараюсь попозже нарожать разобранных примеров.


Что еще важно отметить: здесь написано только про первый пункт, про инструменты. Но есть еще минимум один — он про «писать код красиво и правильно». Если освоить только первый, получится говнокодер. Лучше, чем ничего, но все-таки.

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


Сначала мне казалось, что осваивание нового сложнее всего прокачать. Потому что когда спрашиваешь, почему не получается кодить, обычно отвечают: сложно, ничерта не понятно, хаос. Но потом выяснилось, что все гораздо лучше. Ну, как бы 2022 год, все умеют гуглить.


Если подвести итог. Мое однозначное имхо: при изучении программирования концентрироваться нужно не на языках или фреймворках. И даже не на алгоритмах и другой безусловно полезной фундаментальщине. Сначала необходимо вкачать базовые навыки, которые позволят курить языки, фреймворки и алгоритмы. И один из них — быстрое осваивание новых инструментов

Показать полностью
Отличная работа, все прочитано!