Я не мог в это поверить - для прикола, без разбора открывал разные самоучители и документацию по разным языкам программирования и видел одно и тоже, единую логическую структуру.
Программирование это не сложно, скорее прикольно, если использовать современные подходы и методики. Больше нет надобности в толстенных книгах, изучению библиотек и вникать в ломающие мозг математические приемы.
Программирование стало практичным. Лекции по программированию попросту не имеют смысл, а значит знать много тоже не так важно - достаточно уметь быстро найти в Интернете то, что необходимо.
Когда-то давно я несколько лет я брал студенческие заказы по созданию баз данных в MS Access и сделал их более 30. Так вот, все эти задания никак не соотносились с тем, что мне приходилось делать на основной работе в должности программиста баз данных - 0% совпадений!
Теперь ценится умение немедленно взять и начать писать код. А там в процессе разберемся и подкорректируем.
Принцип программирования №1. Никто ничего не знает
Я серьезно:
- Заказчик всегда не понимает, что хочет - есть лишь набор ощущений и эмоций.
- Постановщик не понимает, как это изложить в требованиях.
- Программист не улавливает смысл, потому не представляет какой путь решения выбрать.
- Тестировщик не представляет как должна выглядеть идеальная система без багов.
- Продукт-менеджер не понимает:
чем занимался программист столько времени, если ничего не работает?сколько в действительности требуется времени и человеко-часов на данных проект?
Программисту в IT живется проще всего, потому что он находится в середине цепочки ответственности. Даже если он работает на позиции Сеньора, то всё равно упирается во множество принятых другими людьми решений: железо, сроки, стек инструментов, нормативные акты, профессиональные и личностные ограничения коллег, корпоративный стиль разработки и пр. На прочих позициях - Джуна и Мидла - работать еще проще.
Какое поведение должен избрать программист 70 левэла? Взять инициативу в свои руки:
- Не нужно уточнять у заказчика все нюансы финального решения. Если речь о фронтэнде - просто сделайте 2-3 варианта интерфейсов и оставьте последнее решение за ним. В бэкэнде еще проще - вы просто делаете тот вариант, на которых способны и уверяете, что сделано самым эффективным способом.
- От постановщика можно часть несделанного просто утаить - скорее всего никто этого не заметит. Начинайте с принципиальный моментов, главной функциональности. Не нужно тратить уйму времени на какую-то хитро описанную штуку в редком сценарии работы системы - оставьте это на потом (вполне может быть, что реализовывать даже не придется).
- Тестировщику напоминайте, что предлагаемые им сценарии не встречающиеся в реальности и что полученная особенность работы на самом деле удобна, а вовсе не вредна - предложите оставить как есть и если уж заказчик настоит, то позже изменить. Не бойтесь торговаться, как на рынке по каждому замечанию. Я вот искренне считаю, что лучшее тестирование проводит конечный пользователь - реальные баги выявляются быстро и их повторяемость указывает на невыдуманность. Если ошибки исправлены оперативно, то пользователи даже испытывают удовольствие, что поучаствовали в улучшении системы.
- Продукт-менеджеру или начальнику называйте срок умноженный на коэффициент 2,5, только говорите слово "реалистичный", чтобы он понял, что вы уже умножили. Я видел такой исход проектов десяток раз: делается расчет по часам по каждой мелочи, часы раскидываются по всем участникам, получаем 1 месяц разработки. В итоге реализация готова через 3 месяца. Как так выходит? Дело глубоко в психологии и паршивой реальности :D Сотрудники болеют, застревают в пробках, теряют мотивацию, отпрашиваются по личным делам, ничего не соображают, тупят и битый час болтают за кофе вместо того, чтобы работать. И кстати: никто не программирует по 8 часов в день. В последнюю ночь перед сдачей проекта - да, но обычный ответственный сотрудник по 4-5 часов, в пределе - 6 часов в день. Короче говоря, вы всегда можете с умным видом называть любые сроки и двигать их - это происходит в IT постоянно.
Принцип программирования №2. Есть всего несколько типов задач и наоборот - никакие две задачи не будут полностью идентичны
Где-то в 90-х осталось заблуждение, что если накопить достаточно большую библиотеку типовых решений, то больше ничего не придется писать с нуля - будешь только выбирать решение из списка выдавать заказчику.
К сожалению, эту чудесную идею постиг полный провал. Библиотеки накапливали тысячи задач в одной и той же области, даже в одной компании и всё равно приходилось что-то писать под каждую прилетевшую задачу.
Прямо как в криптографии - пара переставленных местами цифр меняют финальный ответ до неузнаваемости. Универсальных решений нет. Балом правят казуальные решения под каждую сиюминутную потребность.
Начинаю ли я судорожно придумывать с нуля путь решения для вновь полученной задачи. Вовсе нет. После 15 лет опыта мозг даже не включается - руки сами принимаются решать задачу, а я могу обдумывать список покупок в магазине или план на предстоящие выходные.
Как же так выходит? Ведь я пишу код с нуля, не копирую уже решенную ранее задачу, а создаю новое решение, но умственных усилий для этого почти не требуется.
Потому что: способов обратной связи от системы; способов выходного формата данных; способов хранения или передачи информации; способов построить интерфейс или организовать управляемую настройку всего перечисленного - всего несколько. Пройдя лишь по разу через каждый сценарий и нащупав в каждом из них альтернативные пути решения ты уже будешь идти по знакомому маршруту, через год тебе даже станет скучно.
Принцип программирования №3. Умение программировать не зависит от отдельного языка
Какой бы язык вы не выбрали вы встретите одни и те же паттерны - присвоения, циклы, условия, вызов функции, объединение кода в модули, соединение строк и рекурсии.
Весь код - это текст, который можно набирать в любом редакторе, затем компилировать, исполнять, деплоить и распространять, а исходник кода - надежно сохранять.
Даже математика не так важна для программиста: нужно лишь чувствовать логику, обладать фантазией и абстрактным мышлением. Остальное приложится)
Программирование это многогранный, но вполне понятный мир. Погрузившись лишь раз в который, более уже не придется испытывать дискомфорт.
Не бойтесь собственных страхов касательно ремесла программиста - они существуют только у вас в голове и вряд ли реализуются, когда вы таки попробуете себя в деле.
Выпуск №15, Санкт-Петербург, дата написания 05.06.2023
