Фиксируй все детали

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

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

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

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

Оптимальный режим работы

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

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

Я же сделал для себя выбор. И советую сделать выбор каждому. Чем раньше вы определитесь с комфортным для вас режимом работы, тем проще вам будет потом.

А нужно ли расти дальше?

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

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

Другая причина это когда у человека просто нет времени на саморазвитие. Его хватает только на 8 часов работы и то не всегда. Таких видно. Они постоянно куда-то опаздывают, просят помощи, не думают о завтра. Они могут быть неплохими работниками, но на перспективу они не принесут пользы.

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

Так же есть такие, которым хорошо и сейчас и они не думают о том, что потом будет что-то не так. Такие уверены, что сейчас уже хорошо и так будет всегда. Странные люди. Наверно у них уже всё есть или будет в наследство или ещё где-то. Может так и будет. С такими надо быть аккуратнее.

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

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

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

Не застывай на одном месте

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

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

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

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

Работа с тайм-трекером

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

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

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

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

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

Годно или модно?

В этой заметке уйдём немного в крайности и поговорим о том как можно работать в срезе того как ваша работа воспринимается другими.

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

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

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

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

Дорогу осилит идущий

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

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

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

Можно попытаться взглянуть на ситуацию со стороны, попробовать оценить свои перспективы и прикинуть варианты, а по итогу провести анализ и попробовать определить, что для тебя лучше. Главное не застыть в ожидании чего-то и продолжать искать варианты.

Всегда есть что-то новое, что-то интересное, что-то действительно стоящее. Главное не останавливаться. Нужно искать и продолжать развиваться дальше. Это мой совет. Кто ищет, то всегда найдёт.

Положиться можно только на проверенных

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

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

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

Пол года взращивания и наставления

В заметке "Ты тот, с кем ты работаешь" я писал, что напишу результат работы со своими сотрудниками по вопросу повышения качества работы. Прошло пол года и можно сделать некоторые выводы. На самом деле выводы неутешительные.

За пол года ничего не изменилось. Результат остался тот же самый, а иногда стал даже хуже. При всех моих стараниях прогресса нет. Так в чем же дело? Думаю тут несколько причин.

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

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

Ещё могу выделить невежество. Такое чувство, что люди живут одним днём и просто не собираются оставаться в профессии после.

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

Декомпозиция не только в работе

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

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

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

Теория хорошо, а практика лучше

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

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

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

Спешка нам не нужна

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

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

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

Стой на своём

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

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

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

Как хранить полезную информацию

Для разработчика важно иметь удобный и быстрый доступ к полезной информации, которая помогает решать задачи и ускоряет работу. Записки — это классический способ фиксировать идеи, решения и полезные советы. Они могут быть как в бумажном блокноте, так и в цифровом виде. Главное преимущество записок — возможность быстро записать мысль или кодовый фрагмент, не отвлекаясь на оформление. Однако минус в том, что при большом объеме информации их сложно систематизировать и искать нужные данные.

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

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

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

ИИ или не ии

Применение искусственного интеллекта (ИИ) в программировании имеет значительные преимущества. ИИ способен автоматизировать рутинные задачи, такие как генерация кода, поиск ошибок и оптимизация производительности, что ускоряет разработку и снижает нагрузку на программистов. Кроме того, инструменты на основе ИИ, как Copilot или ChatGPT, помогают быстрее осваивать новые технологии, предлагая готовые решения и примеры кода. Это особенно полезно для начинающих разработчиков, которые могут учиться на реальных примерах.

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

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

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

Яркая индивидуальность - плюс или минус

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

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

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

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

В итоге, быть выдающимся разработчиком — это преимущество, но оно требует стратегического подхода. Важно не только развивать навыки, но и учиться управлять своим имиджем, выстраивать профессиональные связи и создавать "план Б" на случай конфликтов на работе. Если подготовиться заранее, можно минимизировать риски и превратить свою индивидуальность в главный актив, а не в источник проблем.

Собеседование не просто опрос

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

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

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

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

Технологично или логично?

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

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

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

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

Никто не лучше тебя

Недавно смотрел видео выступление одного популярного (в своих кругах) разработчика. Для меня он выделяется тем, что позиционирует себя как эксперт в php, symfony (и т.д.), снимает много видео, делает курсы, ведёт блог и в таком духе. И вот когда я смотрел его выступление на форуме, то ощущал себя ниже уровня, чем он. Отчасти это такая внутренняя предустановка.

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

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

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

Бездумный код от GPT

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

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

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