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

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

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

В моём случае вся акселерация состояла из пяти звонков длительностью 15 минут по четвергам. Я просто рассказывал, что сделал, и (что важно) отправлял скриншот карточки в Трелло того, что я должен сделать за неделю. И это просто магия какая-то, потому что моя производительность повысилась в разы! Казалось бы.

Я не знаю, как обстоят дела с акселерацией в разных регионах, Ростов-на-Дону всё-таки достаточно крупный IT-центр России. Но главное — если вы найдёте себе силу, которая будет вас пинать, чтобы вы что-то делали, то проект станет развиваться быстрее. Это если вы такой, как я. Возможно, вы и так суперэффективный, не прокрастинируете и можете программировать шесть часов в день. Но тогда вы сверхчеловек вообще. Аккуратней с этим, чтобы не выгореть в двадцать лет.

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

Конечно, вам нужно делать задачи в порядке важности, который вы определили на первом тестировании. Но у меня так не получилось — я делал карточки из списка «классные фичи», а список «ОЧЕНЬ ВАЖНО!!!» остался почти тем же. Потому что сложные и важные задачи обычно делать сложнее. :—)

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

Обожаю Пайчарм за внимание к супермелочам.

Например, если вынести методы класса наружу (как обычные функции), то он автоматически заменит одну пустую строку между методами на две согласно PEP8. И наоборот.

HTML и CSS — это, чуваки, жуткий депрекейтед.

И самое обидное, что аналогов-то нет. Не напишешь новую концепцию рисования веб-сайтов так, чтобы любой браузер на неё мог легко перейти. ХТМЛ будет существовать ещё долго.

А нам (точнее, вам, фронтендерам :—) придётся с ним мучаться. Ты пишешь vertical-align — и, скорее всего, ничего не произойдёт, потому что ой знаете это свойство работает только для элементов типа Жопа. Вертикал-элайн должен делать то, что подразумевается — двигать блок наверх, и ниипёт. Язык должен стать более декларативным. float не должен ломать половину других свойств при применении. width: 1px вообще не должен существовать.

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

Единственное, что спасает CSS, — это флексбоксы. На флексбоксах можно сделать всё что угодно, зная при этом десять команд.

А всё остальное надо к чертям выкинуть и переписать.

Косяк в приложении Додо. Там база устроена так, что «сырники с малиновым вареньем» — это на самом деле просто сырники, а выбрать сгущёнку или варенье ты должен уже внизу (последний пункт заказа на скрине).

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

Обновляю зависимости в проекте. Решил просто поставить везде последние версии, не вычитывая ченжлоги.

Поставил билдиться и решил отойти от компа — на случай, если он взорвётся к чёртям.

Я же тут поднимаюсь до мидла, да? Вот мой прогресс за месяц:

1. Кажется, я наконец-то научился работать в команде. Так получилось, что раньше я всегда работал один, а если над моим кодом работал кто-то ещё, это превращалось для меня в мучения.

Я очень сильно привязываюсь к коду, который пишу сам с нуля. Если я написал микросервис, дал наружу сигнатуры API, то не надо было писать мне «а почему ты здесь написал вот так, если можно было вот так: ...». Объяснение, почему я сделал так, как сделал, отнимало у меня невероятно много нервов. Самое страшное было, когда кто-то коммитил в мой код. Ты что, охуел трогать мой священный микросервис?

Конечно, это неправильно, и я это понимал, но ничего с собой сделать не мог.

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

1.1. Научился работать с гитом в команде. Раньше у меня было две (в лучшем случае) ветки, и не было непредсказуемых ситуаций. Теперь веток миллиард, гитфлоу, надо уметь чинить свои косяки некостыльно, и мне пришлось побольше почитать про гит и разобраться в штуках, которые я не знал.

2. Научился работать восемь часов в день.

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

3. Ну и, конечно, технические штуки, которые я объединяю в один пункт. Научился работать с REST-либами, немного тестирования, прокачался в CI, в Докере, просто начал делать полезные штуки типа лейблов для мёрдж-реквестов. Тут особо ничего и не скажешь — научился и научился. Хотя это вообще самое главное.

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

А ещё в конце концов ты можешь оказаться неправ — у меня было много раз, что я говорил (или уже собирался говорить) «Не, это невозможно», а потом ещё немного сидел и оказывалось, что возможно.

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

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

У меня они такие:

— писать документацию. Или инструкции, или README, или вообще какой-нибудь текст, который потом будут читать люди. Обожаю писать текст (по четырём каналам в телеграме можно было понять, да) и оформлять его в Ноушене или гуглдоке;
— улучшать таски: дописывать в описание выводы из комментов, ставить лейблы, добавлять дедлайны (часто — для себя), сортировать их в списке;
— делать удобные штуки в кодинговской инфраструктуре: добавлять майлстоуны, ишью и лейблы в гитлабе, настраивать их приоритет, мучать всех, чтобы они потом эти лейблы расставляли;—)
— заметили, как я красиво запихнул точку с запятой, которая обозначает конец элемента списка, в смайлик?
— писать комментарии и докстринги, расставлять в них пробелы и большие буквы (в этом плане я перфекционист, и, думаю, здесь это не плохо);
— читать все тексты в продукте и отмечать опечатки и пунктуационные ошибки.

Я думаю, это хорошо.

Вчера очень продуктивно поработал. За день:

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

Планирую дальше заниматься тем же.

Геймеры любят нажимать R после того, как выстрелили один раз.

Программисты любят писать git pull после того, как двадцать секунд назад написали git pull.

Чем больше я разрабатываю, тем больше ценю первоисточник.

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

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

А ещё иногда я прямо иду читать исходный код либы — никогда бы не подумал, что я буду тратить на это время. Но только так у меня получилось узнать, как в точности работает авторизация в нашем проекте. Сейчас я знаю эту часть досконально — поэтому я починил все баги, связанные с авторизацией, и всегда могу ответить на вопрос «что именно пошло не так». В доках часто пишут, что делать, а не как это работает.

Конечно, иногда выгодней тыкнуть на первую строку поиска и попасть на StackOverflow — когда вопрос тривиальный, а ответ на него — однозначный. Потому что программист не должен помнить, как фильтруются списки в JS (особенно если он — то есть я — бэкендер), а должен уметь находить ответ на этот вопрос за десять секунд.