Недавно я принял новое предложение о смене работы. Это мои уроки, которые я усвоил, будучи одним из первых сотрудников стартапа.

Влияние на бизнес важно:

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

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

Видимость:

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

Будь проворным и двигайся быстро:

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

Сделано лучше, чем идеально:

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

Преждевременная оптимизация — корень всех зол — Сэр Тони Хоар, популяризированный Дональдом Кнутом

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

Коммуникация является ключевым:

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

Попробуйте задокументировать все возможное:

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

Ответственность за запрос:

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

Это, безусловно, улучшит понимание системы и приведет к лучшему образованию и самосовершенствованию.

Заключение

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