Обратить внимание на непонятное.

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

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

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

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

От ТЗ до сдачи меньше двух месяцев. Работаем хорошо и быстро, заказывайте разработку

https://vk.com/@-124059206-sokratili-vremya-na-podgotovku-smety-s-1-nedeli-do-1-minuty

Важность базы

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

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

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

Самописное решение для ecommerce это конечно ад по началу, но на дистанции дает немало приятных возможностей для автоматизации и кастомизации. Местами пришлось повозиться, но получилось очень неплохо

Конструктор, интеграции, тг бот и электронные сертификаты в кейсе
https://vk.com/@studio_alt-ne-vsya-tovarka-na-marketpleisah-internet-magazin-utro

А еще ребята делают крутые полотенца и однотонное белье

Первый факап

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

Спустя годы, я обучил и поработал с громадным числом таких же новичков и по опыту — похожего момента не избежать никому. Чего только не видел: десятки способов убить сервак при настройке там чего-то (rm -rf / на проде не видал, но chown -R user:user / был), десятки способов потерять данные (применение старого бэкапа вместо снятия текущего на прод базу как вам), десятки способов положить сайт (включая как заддосить самим себе бэкенд), и сотни менее критичных плохо сделанных задач. И вот после первых проблем и определяются будущие профи, а нежные снежинки отсеиваются. Ну а так как избежать фиаско не удастся никому, попробую дать совет как себя вести есликогда оно произойдет. Принципы эти помогали работать и двигаться дальше, что на старте пути, что со временем, когда факапы становились сложнее, проявлялись на большей дистанции и меньше зависели от внимательности и наличия бэкапов: плохие решения в выборе технологии или архитектуры, катастрофически недостаточные оценки задач, неверные приоритеты, найм не тех людей.

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

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

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

Учимся на ошибках
В итоге даже самые дикие проблемы разрешаются. Важно сделать для себя разбор: что случилось, почему, что сделать чтоб этого избежать, чего не хватало, что делать на будущее? Ответив на эти вопросы себе, оформляем постмортем для клиента формата: проблема была в Х, причиной стала ошибка, чтоб этого больше не произошло мы сделаем Y, а также Z для страховки на случай подобного.
Конечно, неизбежность фейлов не значит, что не стоит их избегать заранее. Наоборот, опыт ошибок научит делать все, чтоб когда они случились — то не стали катастрофой.

Хороший программист

Услышал недавно в оживленном обсуждении опус, мол в России хороших программистов нету. И хоть обсуждать столь очевидно неверное заявление нет никакого смысла, однако оно натолкнуло на мысль, а как определять термин "хороший программист". Проще и правильнее судить по факту сделанного, успешным проектам не загнувшимся от техдолга и нагрузок, но успех проектов зависит не только от отдельно взятого кодера. Потому задумался, кто для меня "хороший программист" и попытался составить набор критериев, таких, чтобы можно было при найме понять, что программист — хороший, а новичкам узнать на что обратить внимание:

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

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

- Неплохо, человек пишет хороший код. Хватает ли этого? В коммерческой разработке нет. От этого кода зависят другие части проекта, и у любой задачи в реальном мире будет срок и бюджет. Потому хороший разработчик умеет в оценки задач и коммуникацию. Понятно, что ясновидящих не бывает, и всегда 100% давать верные сроки — навык уже не хороших, а исключительных разработчиков, но сообщать о том, что ситуация поменялась и ранее названные сроки нереалистичны — доступно каждому, хотя на деле далеко не каждый это делает. Потому навык отслеживать затрачиваемые ресурсы, и как можно заранее сообщать о том, что прогноз был неверен, и надо смещать объем/срок настолько-то — выделит вас среди ребят "будет, когда будет". Коммерческая разработка это командная игра, и кроме коммуникации по статусам и срокам, нужно уметь и критику принять, и о помощи попросить вовремя. Лучшие по результатам разработчики с которыми я работал всегда задавали в разы больше вопросов и делились проблемами с которыми сталкиваются, чем остальные.

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

0.1 + 0.2 != 0.3

За годы работы с начинающими кодерами мне приходилось давать мини-разъяснения на некоторые темы удивительно регулярно. И думаю будет не лишним постепенно собрать эти отрывки сюда для будующих случаев.

Итак начнем с простого: арифметика чисел с плавающей точкой. В теории мемасы о том, что js странный и смотрите ха-ха-ха 0.1+0.2 выдает 0.30000000000000004 видали многие. Однако на деле из новичков учитывают этот факт — единицы. И еще меньше знает, что такая особенность далеко не только у js. Попробуйте python — получите тоже самое. Попробуйте php — может показаться, что все ок, но он вас обманывает.

echo 0.1+0.2;

выдаст вам 0.3, но попробуйте

var_dump(0.1+0.2 == 0.3);

или

echo json_encode(0.1+0.2);

и ошибка вскроется. Если что ошибка далеко не только на сложении 0.1 и 0.2, она будет почти при любых вычислениях с дробными типами данных

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

Решение тут простое, точнее даже два. Для начала убедитесь, что вам действительно нужны числа с плавающей точкой. Например во всех случаях когда речь о деньгах — скорее всего их можно вполне хранить в int считая не число рублей, а число копеек. Тоесть, нужно хранить не цену 100.00 рублей, а целочисленное 10000 копеек. И ставите точку там где нужно только при итоговом выводе результатов. Ну, а если вам все же позарез надо хранить и считать во float — то во всех языках есть готовые инструменты для точных вычислений с ними. Обратите внимание на BigNumber в случае js или на функции bcmath в случае php

ChatGPT и программирование

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

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

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

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

Опять классика вопросов для обсуждения с начинающими кодерами - локальное время и таймстампы

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

Итак первое с чем надо разобраться, наш самый главный друг в вопросах времени, вносящий необходимое постоянство — unix timestamp. Таймстамп — количество секунд прошедших с момента времени, когда 1 января 1970 года часы в Гринвиче показали 00:00. Не с того момента когда часы в вашем регионе показали полночь, а когда они показали полночь именно в Гринвиче. А так как этот момент был одновременно для всего земного шара, то и таймстамп в один момент времени по всей Земле — одинаковый. Тоесть если человек в Москве у которого часы показывают 8 часов, и человек во Владивостоке у которого в этот же момент часы показывают 15 получат текущий таймстамп — то они получат одинаковые числа, несмотря на разное время "на стене".

Получить таймстамп можно в любом ЯП:

new Date().getTime()

в js — он правда вернет кол-во миллисекунд, тоесть в 1000 раз больше значение, чем например

time()

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

"Время на стене" же постоянно у всех разное. Причем на это влияют не только более менее понятные географические часовые пояса, но еще и местные законы и договоренности людей. Где-то есть переход на летнее время, где-то нету. Где-то люди договорились, что их время будет по другому часовому поясу, а потом могут передоговориться и вернуть назад (привет Новосибирск). Короче полная неразбериха. В общем случае ко времени на стене указывают его смещение относительно Гринвича, например UTC+3 — тоесть мол время на 3 часа больше, чем в этот же момент в Гринвиче. Но обозначенные выше ситуации создают кучу примеров когда у человека в течение времени смещение может сменяться — что крайне неудобно. Пытаться переводить время записанное со смещением во время в других местах иногда даже неразрешимая задача. Например если в регионе есть переход на летнее время, то когда часы переводят назад (например с 3 на 2), возникает ситуация когда к примеру время 2:30 наступает дважды. Хранением всех этих нюансов таймзон и переводов времени занимается tz database поддерживаемая и наполняемая волонтерами и поставляемая в операционные системы. Но это особо и не важно, сохранять локальное время в любом случае не стоит, ведь есть путь намного проще.

Фишка в том, что если нам нужно сохранить какой то момент времени (время создания записи в бд, или момент времени в который надо выполнить задачу) — используйте timestamp. Для него вам не надо спрашивать из какого часового пояса к вам обращается клиент. При том таймстамп когда вы его отдадите на фронтенд, каждый клиент может 100% перевести в его локальное время, простейшей функцией

new Date(1710178886146)

к примеру для js. Так бэк будет не заморачиваться и отдавать всем клиентам инфу в одном и том же формате, а фронтенды сами отобразят результат в своем локальном времени.

Немного об оценке задач

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

Все методы оценок начинаются с одних и тех же 3 принципов, потому в любом случае, приняты ли у вас сторипойнты, или часы, важные основы тут остаются одинаковыми. Итак:
1) Любая большая и непонятная задача дробится на подзадачи. Которые в идеале, понятные, обозримые в пределах пары рабочих дней, или типовые/встречавшиеся ранее. Сказать обычно легче, чем сделать, но тем не менее стоит попытаться. Попытайтесь для начала разбить задачи общего описания на чеклист "какие вещи должны работать, чтоб задача была выполнена". Тоесть не "интеграция с 1с", а "отправка созданных заказов в 1с", "импорт товаров из архива от 1с", "импорт клиентов из 1с". У каждой задачи поприкиньте как бы вы ее проверяли, если кейсов для базовой проверки всего пара-тройка штук — значит подпункт получился достаточ детальным, если же проверка будет состоять из кучи разных по логике и структуре вещей - стоит еще подробить.

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

3) И самое главное, навык оценки задач в первую очередь зависит от опыта и насмотренности. Но только при условии "сверки с реальностью". Естественно, никто из новичков не может нормально оценивать задачи. По сути у всех первые оценки ничем не отличаются от генератора случайных чисел — и это нормально. Но если их не сверять с реальностью — то навык и не растет. Часто бывают случаи, когда новичок говорит "3 дня на задачу", через три дня задача не сделана, но его никто не пинает (ну потому что ктож поверит в оценки новичка), через день он ее как-то сдает, и еще 3 дня вносит правки и доработки. Это абсолютная норма. Но когда ему выдают следующую почти один в один задачу, и он не моргув глазом отвечает "3 дня" — вот это уже проблема. Поэтому отслеживайте правильность своих оценок, если дали оценку в 3 дня, и на третий день понятно уже, что явно не успеете — сообщите об этом, и себе пометьте что оценка была неадекватна. И по итогу задачи, вместе со всеми тестами, правками и доработками отмерьте реальное время ее выполнения (тоесть в примере это 7 дней, а не 4) — это будет ваш ориентир на следующую подобную. Понятно, что пока вы новичок, скорее всего вы успеете во второй раз сделать задачу побыстрее. Но ровно это вам и необходимо: если ваше фактическое выполнение равно 70% от вашей оценки, все в порядке. И только если еще быстрее — тогда уже пора понять, что вы выросли и уменьшать запасы.

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

Задачки по программированию

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

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

Поэтому если вы начинаете свой путь в программировании, важно понимать, что да, в коммерческой разработке важны немного другие вещи нежели в спортивном кодинге. И важно писать и собственные пет-проекты похожие на проекты реального мира (на 99% состоящие из скучных запросов к бд и сторонним апи). Но безусловно полезно, в качестве фитнеса для мозга, и набития руки зарегаться на codewars и leetcode и допроходить хотя бы до medium уровня

Требуются разработчики

Открыты пара мест для начинающих (и не только) веб-разработчиков.

Что делаем:
В основном кастомная веб/мобильная разработка. Некоробочные решения на фреймворках, в основном пишем на laravel + react/vue. Немного реже node.js, совсем изредка python, но при желании изучить дополнительные технологии — найдем где с пользой применить знания. Разрабатываем решения для екоммерца, финтеха, веб-сервисы для стартапов, системы учета и аналитики, интеграции, автоматизации процессов.

Кто нужен:
Ищем разработчиков разного уровня, ты либо уже опытный фуллстэк (предпочтительнее laravel+react), либо было бы интересно им когда-нибудь стать. Рассматриваем студентов и джунов, необходимо будет (если всего списка пока нет, но есть желание освоить - все равно пишите):
- написание api бэкенда. роутинг, mvc архитектура, crud операции, валидация запросов, аутентификация и авторизация
- базовые навыки верстки, простой фронтенд на js (ajax запросы), в идеале знакомство с react/vue
- работа с бд, как использование orm так и написание raw запросов
Тоесть в целом готовы начинать работать и прокачивать людей с уровня "могу написать todo-приложение"

Предлагаем:
- почасовая оплата
- нагрузка от 15 часов в неделю (чем больше можете — тем лучше), возможность совмещать с учебой, возможность подработки в летний период
- помощь опытных разработчиков, возможность профессионального роста и быстрого роста ставки

Отклики и вопросы — пишите @navlis23, по возможности прикладывайте гитхаб с примерами любого кода и описывайте свой опыт в программировании

Арсенал инструментов менеджера

Проблема всех управленческих решений в том, что они не универсальны. В одной ситуации решение будет работать, и тут же в чуть другой нет. Гарантий нет никаких, мы только влияем на вероятность того или иного исхода, и на адекватность каждого решения влияет много переменных. Поэтому важным критерием «мощи» управленца для меня всегда было разнообразие арсенала инструментов и возможных решений к каждой ситуации. Чем больше к одной ситуации человек знает подходов, тем выше вероятность, что он сможет выбрать более подходящий вариант, и не впадет в ступор когда действия «по привычному шаблону» упрутся в тупик

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

Что может помочь, а в идеале все вместе:
1) Ретроспективы. Задним числом мы все умнее всех, и это вполне можно использовать с пользой, а не только раздражаться от очередного умника рассказывающего о том "как же ты не догадался"). Потому после любых факапов, авралов, сдач проектов или этапов полезно подумать самому задним числом и понять, что можно было сделать, чтоб все возможно случилось лучше - обычно постфактум понимание вариантов всегда приходит, и важно обратить на них внимание, чтоб возможно использовать в будущем. Если осознанную ретроспективу не провести - опыт закрепится намного хуже. Важно, впрочем, не заморачиваться слишком сильно, и не ловить дизмораль, даже если найденное решение покажется очень простым. Ведь таким оно кажется только когда уже знаем итог, да и то что оно бы помогло - лишь предположение.

2) Моделирование ситуаций. Никто нам не мешает и просто придумывать самим себе упражнения и гипотетические ситуации. Подумайте до того как это произошло: что будет если кодер пропал перед сдачей фичи, что можно сделать если совсем не укладываемся в оценку, посредством чего можно влиять сроки проекта или что будете делать если прод упал, а все кодеры знакомые с проектом лежат с пищевым отравлением. Это конечно не реальный опыт, но часто помогает и "подстелить соломки" местами и в целом прикинуть, а какие вообще у нас есть инструменты и какие у них возможны ограничения. Каждую из придуманных ситуаций в идеале нужно решать в голове не одним способом, и к любому промежуточному решению добавлять предположение, что оно могло и не сработать - в итоге выходит не самая плохая тренировка навыков.

3) Чужой опыт. Хоть поговорка и говорит, что учиться намного лучше на чужик ошибках, по факту же большинство вещей все равно действительно доходит, только когда сам столкнешься и "проживешь". Однако, действительно сильно проще если до этого нас хотя бы предупредили как оно будет, адаптация пройдет проще, да и варианты возможных решений уже будут известны. Потому не забываем кроме личного опыта обращать внимание на чужие кейсы, выступления, работы. Книжки опять же можно почитать, в качестве рекомендации новичку к примеру: Питера Друкер «Эффективный руководитель»