Category: Начинающим программистам

Программерия - это алхимия

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

Как стать программистом? Что учить программисту?

Наша профессия одна из сложнейших и каждая программа по своему уникальна. Кроме самого программирования как такового нужно обязательно знать множество других смежных вещей которые помогают конструировать ПО. Мы ещё плохо понимаем как правильно разрабатывать программы и каждый раз мы пытаемся предугадать её будущее изменение и много экспериментируем переосмысливая свой опыт. Всё это очень похоже на Алхимию.
И подобно как из Алхимии родилась Химия, также из Программирования рождается новая наука Программерия. Что это, и как она помогает современному программисту читайте в моей статье Программерия, или что нужно знать программисту.

Похожие статьи

Итак, вы решили стать программистом
Что нужно знать каждому программисту по версии Google! (eng)
Программирование — занятие не для каждого
Писать код уже не достаточно: обязанности современных back-end разработчиков
Как стать программистом?
Путь программиста: через что придется пройти джуниору, чтобы стать синиором
Путь программиста
Карта программиста
Что должен знать html-верстальщик?
Почему разработчик — не инженер

Хороший институт не даёт хорошего образования

Где лучше учат, в Стенфорде или в академии ШАГ а может и вовсе на дешёвых курсах?

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

Как определить что вы учите примерно правильно и примерно оптимально, по крайней мере для определённой категории людей? Очень просто — если вам платят значит вы в правильном направлении. Если вам платят значит ваши студенты всё таки имеют больше шансов на устройство. Если они устраиваются значит они могут справляться с работой.
Рынок, рынок всё решает.

По мотивам обсуждения на форуме Стремительный рост КА ШАГ

Скринкаст: Пишем калькулятор на Java, JavaFX, Groovy, Spock, Kotlin

Несколько вечеров за которые я написал калькулятор на Джаве с тестами на Груви а потом переписал на Котлин. Интересно будет только для Stong Junior’ов

Это не туториал! В обычных туториалах всё хорошо и сразу получается, но как только начинающий программист сталкивается с ошибкой то не знает как дальше двигаться. Здесь все по настоящему — часть я знаю, часть изучаю сразу же. На ваших глазах появляются и фиксятся баги, гуглится и копипастится с СтекОверфлоу. Это может быть вам полезно для того чтобы ощутить эвристики которые помогают мне.
Скучно, занудно — но именно так примерно мы и программируем целыми днями. Если вы думаете связать свою жизнь с этим ремеслом, можете прочувствовать себя в моей шкуре 😉

Исходный код:
https://github.com/stokito/javafx-calculator

P.S. Да, я знаю звук отвратительный, винда неудачно обнволялась и с драйвером звука какая-то ерунда.

[Linkset] «Stringly typed» Antipatern: Avoid string where other types are more appropriate

[Linkset] Несколько статей про карьеру в IT

Ох, как же тяжело быть программистом

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

Программируй так, как если бы человек, который будет поддерживать твой код, будет брутальным психопатом и будет знать, где ты живёшь. © Martin Golding

evil_programer
А всё потому что написанная однажды твоя программа будет ещё переписываться много раз. И скорее всего не тобою…
И я начал чётко следовать этому правилу и стараться писать код хорошо.
Время шло и я узнал следующую правду жизни:

Как бы ты не старался, тебе потом будет стыдно за этот код и даже будет хотеться переписать.

Чёрт побери, и ведь правда! Всем программистам стыдно.
Смотришь на свой код трёхмесячной давности и думаешь: «Блин, ну как я так мог кодить?»
Как я программировал три года назад

Как же с этим жить? Но вот на одной конференции я узнал спасение:

Плохой программист пишет в день 200 строчек кода а хороший программист удаляет в день 200 строчек

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

И вот я переколбасил код думая что я сделал «рефакторинг», ну ничего что без тестов, но работать должно. И вместо написания своего CSV парсера нашёл в интернете и подключил к проэкту какой-то чужой, который ещё и Excel файлы шарит парсить, и в БД сразу записывать и кофе варить и ракеты запускать.
Я удалил не 200 а 400 строк! Йуху! Какой же я крутой 🙂

И в припрыжку понёс показывать это всё архитектору на ревью.
А он глянул и сразу дал мне по шапке: «А это что за библиотека? А ты уверен что в ней нет багов? А класс этот ты зачем поменял? А ты тесты написал? А ты уверен что после твоего рефакторинга оно будет работать как прежде?».
И рассказал мне программисткий анекдот:
Работает - не трогай

И ты так и продолжаешь работать на проекте постоянно дописывая костыли и накапливая технический долг.
И вот наступает такой момент когда прибегает к тебе проджект менеджер и говорит «там заказчику нужно срочно поменять стратегию начисления скидок к рождественским продажам. За сколько можешь сделать?».

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

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

Любой код без автотестов сразу становится legacy: никому непонятный, хрупкий и почти неизменяемый, и все уже через неделю забудут что он делает и как. И совершенно неважно, насколько хорошо он написан, объектно-ориентирован или инкапсулирован. С помощью тестов мы можем быстро и под полным контролем изменить поведение нашего кода. А без них мы на самом деле не знаем, становится ли наш код лучше или хуже
© Майкл Физерс, Эффективная работа с унаследованным кодом

Посидел, поглядел в монитор час.
Нет, всё равно непонятно. Как оно, блин, вообще работает? Я убил бы того кто это писал, вот бы узнать где он живёт… и бензопилой… или лучше в кислоте его…
Пойду кофе заварю.
Вернулся, посидел ещё часик.
Скучно. О! Новый имейл.
Потом ещё часик.
А что там в твитере пишут?
Потом ещё часик.
Зайду-ка я на хабру, может чё интересного почитать.
…ещё часик.
Так, ладно. Нифига не понятно, пора домой.
loop of procastination

Следующий день проходит примерно также. И вот заходит к тебе проджект менеджер, а у тебя на весь монитор башорг:
— Нушотам, сделал?
— Та я это… там непонятно..
— Блин, ты же обещал за два дня сделать! А ты башорг читаешь!
— Ну… за два-четыре…
— Да продажи уже начнутся через два дня! Короче у тебя дедлайн до завтра. Иначе уволю нафиг, бездельника.

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

вероятность успеть к дедлайну имеет биномиальное распределение

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

И всё? Вот это вот я три дня ковырялся чтобы одну строчку исправить? Блин, я программист а кода даже как-то и не пишу. И новая истина которая открылась тебе гласит:

Большую часть времени программист читает код, а не пишет.

Блин, это совсем не романтично 😦

Ну вообщем заказчик уже нервничает и ты сдаёшь программу. А твой QA на проекте тоже был занят и не успел протестировать твой код, и он так и торжесвтенно отправился в продакшен.

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

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

А ошибка оказывается происходит когда пользователи цену указывают с центами. И вдруг ты понимаешь — а ведь в США десятичный разделитель не запятая, а точка! И ты вбивал $5,50 и у тебя работало, а американцы вбивают $5.50 и получают ошибку. Но ты об этом ну вообще даже не мог подумать, и отдал не до конца протестированный код и который ну просто обязательно и завалился. Это было неизбежно, потому что есть Закон Мерфи который гласит:

Если что-то сделано так что может поломаться, оно обязательно поломается

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

Всегда твою работу должен тестировать другой человек, специально этому обученный QA, причём сразу же как ты сделал задачу.

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

Нужно бежать за прогрессом чтобы оставаться на месте

Как быть? После работы дома ещё начинаешь себе pet project, так, чисто для души.
Жена недовольна — муж приходит с работы и снова за компьютер и в наушники. Сначала бесится, а потом рожает тебе ребёнка чтобы ей скучно не было. Теперь дома детские визги вообще не посидеть кодить — и начинаешь засиживаться на работе до одиннадцати.
А что делать? Как-то же обучатся нужно.
И постепенно твоя производительность снижается и устанавливается на определённом уровне, и тебе открылась следующая истина:

все работники креативной специальности: маркетологи, художники, музыканты, программисты — никогда не могут работать больше, чем четыре часа в день.
© bobuk

Но вот случается чудо, и заказчику нужно написать новое приложение. У вас есть возможность написать проект самим с ноля! Не какого-то старого монстра фиксить костылями, а начать с чистого листа.
Тут вы сразу же восторженно рисуете UML диаграммы, схему БД и выбираете стект технологий: что там сейчас самое модное? MongoDB, AngularJS, Scala? Ну и конечно же сразу нужно всё писать для Cloud! А теперь попробуем со всем этим взлететь…
а теперь со всем этим взлетим!

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

Как это не прискорбно, но следующее открытие:

Начали в стиле «Хай-тек». Закончили в стиле «Нехай так».
© Dmitriy Efimenko

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

Именно поэтому, вообщем-то, хороших программистов не так много. И именно поэтому им платят относительно неплохо (а на самом деле ещё и сильно недоплачивают).

Но однажды ты почувствуешь спокойствие и Силу Джедая. Как к этому прийти обязательно посмотри этот коротенький и чудный рассказа Андрея Солнцева:

UPD Похожая статья В поисках идеального программиста


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

Нужно ли указывать непрофильное образование в резюме?

Вопрос по поводу резюме. Я сейчас заканчиваю второе высшее, бакалавр, Computer Science… до этого я закончил английскую филологию 😦
И у меня по этому поводу комплекс — я в резюме об этом нигде не указываю. Правильно ли я делаю?
Тебя бы отпугнуло такое резюме Java Junior, где в графе образование значится Иняз и Computer Science?

Ответил так:

  • Первое высшее обязательно указывай. Во первых, это твоё высшее, и это уже довольно круто и почётно. Далеко не каждый может его получить. Та даже не высшее — это твои знания, и их стыдится вообще нельзя.
  • Во вторых специальность крутая — англ филология, значит Инглишь шаришь или как минимум любишь.
  • В третьих — чтобы не было вопросов «а чем ты занимался всё это время?».
  • В четвёртых — есть компании которым именно такой человек может и нужен. Например Gramarly — они делают проверку орфографии для английского и им может нужен человек который поможет сделать структурный анализ текста на соответствие художественному или научно популярному стилю.

Хуже точно не будет, а плюс будет в любом случае.