Каждому инженеру знакомо чувство раздражения, когда сталкиваешься с повторяющейся ошибкой или недостатком в продукте, который используешь ежедневно. Особенно тяжело, когда ты достаточно компетентен и знаешь, что можешь помочь исправить проблему, но не имеешь прямого доступа к исходному коду или не можешь внести свой вклад в проект. Именно такая ситуация случилась с автором истории, который более года испытывал неудобства из-за нестабильной работы поисковой системы на платформе Mintlify. Осознание того, что эта проблема связана с неполадками поиска и кажущийся хаос в результатах, вызвало желание не просто выразить недовольство, а кардинально изменить ситуацию.Автор был основателем компании Trieve, которая обеспечивает поиск для более чем 30 000 документационных сайтов, включая Mintlify.
Казалось бы, с таким опытом и знаниями кажется естественным предложить исправление в виде пулл-реквеста — стандартного способа внести улучшения в большинство современных проектов. Однако, несмотря на этот очевидный путь, пулл-реквест отправить не удалось, и проблема продолжала оставаться нерешённой. Это породило двойственное чувство: с одной стороны, он был сторонним поставщиком сервиса, своеобразным вендором, а не частью команды, с другой — наблюдал, как продукт, который он косвенно поддерживал, страдает из-за технических ошибок.Ключевая техническая сложность заключалась в механизме дебаунса запросов к поиску. При наборе запроса пользователем старые запросы продолжали обрабатываться, даже когда новые уже поступали в систему.
В результате возникали так называемые race conditions — ситуации гонки, когда ответы на более ранние запросы прибывали позже, чем более свежие, и тем самым сохранялись в интерфейсе, создавая несоответствие между вводом пользователя и показанными результатами. Это не только ухудшало пользовательский опыт, но и наносило репутационный урон компании Trieve, учитывая, что именно их технология обеспечивала поиск.В течение долгого времени автор упоминал проблему в общей рабочей коммуникации в Slack, но это не вызвало достаточного интереса у команды Mintlify для её решения. Такой подход часто встречается в индустрии: крупные проекты и компании могут не сразу реагировать на баги, которые кажутся не слишком критичными, в то время как пользователи продолжают сталкиваться с неудобствами. Это ещё больше усилило внутреннее желание автора не просто оставаться пассивным наблюдателем, а взять ситуацию в свои руки.
Переломный момент наступил, когда автор присоединился к команде Mintlify. Получив доступ к коду, он смог реализовать давно продуманное решение с помощью AbortController — API, который позволяет отменять ранее запущенные запросы, если появляется новый. В контексте поиска это означало, что при вводе нового поискового запроса старый автоматически прерывался, исключая появление устаревших результатов и обеспечивая более релевантный и своевременный отклик системы. Это техническое улучшение значительно повысило качество поискового опыта для всех пользователей платформы.Сам процесс исправления багов, особенно в своем роде врожденное чувство ответственности, когда ты делаешь то, что улучшает продукт, приходит с особым удовлетворением.
Автор сравнил себя с известным инженером Джорджем Хотзом, который прославился своим амбициозным желанием улучшать крупные технологические системы, в том числе работы в Twitter. Хотя результат их опыта был разный, общее сходство — страсть к решению технических задач и влияние такого подхода на карьеру — очевидно.История показывает важность подхода инженера-предпринимателя, когда можно не только выявлять проблемы, но и предлагать и реализовывать решения. Такой настрой позволяет не просто работать по заданию, а быть активным творцом продукта. Опыт с Mintlify — прекрасное доказательство того, как прямое вмешательство и стремление исправить недостаток формируют не только профессиональный рост, но и глубже погружают в процессы развития компании.
Особенно важным в этом контексте выступает тема открытого исходного кода. Автор подчеркнул, что, если бы проект Mintlify был открытым, он мог бы уже год назад внести необходимые изменения через пулл-реквесты, избавив тысячи пользователей от ежедневных неудобств. Open source позволяет сообществу не ждать, пока владельцы продукта обратят внимание на проблему, а самостоятельно исправлять и улучшать проект, получая опыт и пользуя всех заинтересованных сторон. Однако нужно понимать, что многие компании выбирают собственнические модели разработки из стратегических и коммерческих соображений, что ограничивает такую возможность.В итоге, автор подчёркивает, что мелкие улучшения — именно те небольшие правки, которые делают продукт лучше шаг за шагом, и формируют его репутацию на долгие годы.
Чувство личной победы от того, что удалось исправить то, что мешало и раздражало, особенно ценится в профессиональной среде IT-инженеров. На примере опыта Mintlify мы видим, как решительность, технический интеллект и наличие возможности влиться в команду приводят к впечатляющим результатам.Вереница технических проблем и барьеров на пути внесения изменений часто могут остановить наиболее мотивированных специалистов, но реальный доступ к исходным кодам и возможность непосредственно влиять на продукт — один из ключевых факторов удовлетворённости и профессионального роста. Именно такие истории вдохновляют и показывают, насколько важна культура постоянного улучшения и готовность брать ответственность на себя.Поэтому, если столкнулись с проблемой, которую не удаётся решить обычным способом, возможно, стоит рассмотреть более радикальные шаги: присоединиться к команде, стать частью процесса и сделать вклад напрямую.
Такой подход не только помогает устранить раздражающие ошибки, но и открывает новые горизонты для развития и планирования карьеры. Истории, подобные этой, подчёркивают ценность настойчивости, технической компетентности и готовности действовать — качеств, которые отличают настоящих профессионалов в сфере технологий.
