Я окончил колледж с затуманенными глазами, в долгах и готов взяться за мир «профессиональной» разработки программного обеспечения.
Я узнал об Agile и в некотором роде не практиковал его во время стажировки. Я писал много кода между уроками, личными проектами и различными рабочими местами. Я даже попробовал свои силы в умеренных дизайнерских предложениях и мышлении в более широком смысле.
Я был уверен, что у меня будет хороший старт в своей первой работе по разработке программного обеспечения, и очень хотел начать. Я был похож на большинство инженеров, только что окончивших школу: я был готов учиться, расти и становиться лучшим инженером, которым я мог быть.
И, как и большинство младших инженеров, я совершал ошибки. В течение первых двух недель я уже написал ошибку, из-за которой один из членов нашей команды работал сверхурочно, чтобы отчет был доставлен вовремя.
Однако большинство ошибок были связаны не с написанными мною ошибками или несвоевременным завершением проекта (и то, и другое произошло). Большинство из них были о моем страхе выглядеть глупо. Многие называют это синдромом самозванца. Я боялся признаться, что не знаю идеи, концепции или что у меня проблемы с запоминанием, как пройти через дерево.
Этот страх привел меня к нескольким ошибкам в начале моей карьеры. Надеюсь, поделившись моими ошибками, вы сможете избежать их в своих.
Я не задавал достаточно вопросов
Я знал это в своей голове, но на самом деле переживание и ощущение отсутствия знаний не заставляло меня задавать вопросы. Вместо этого я решил, что мне не место, и попытался найти все эти идеи, которые услышал, через Google и Stackoverflow (как любой хороший разработчик, верно?).
На собраниях я просто молча кивал и соглашался с тем, что говорили другие в моей команде, надеясь, что они не будут напрямую спрашивать меня.
В коде я просто продолжал читать все больше и больше ужасного кода, который я видел (моя первая роль заключалась в обновлении сложной биллинговой системы), надеясь, что в конечном итоге это объяснит себя. Этого никогда не было. Я часами писал код, который не мог понять, потому что слишком боялся спрашивать определения аббревиатур или терминов, которых я не знал.
Задавать вопросы! Не верьте лжи о том, что вы не способны что-то понять просто потому, что не поняли этого в первый раз, когда вам это объяснили. Помните, что каждый инженер в вашей команде должен был изучить все, что он знает; они также не отказались от своего образования или опыта, зная все это. Возможно, им тоже нужна была помощь, чтобы научиться этому, так что не расстраивайтесь.
Или они такие же, как вы - просто стараются не отставать. Вы были бы удивлены, сколько инженеров просто кивают и молча соглашаются с идеей, не имея ни малейшего представления о том, что это такое.
Вместо того, чтобы стыдиться, научитесь задавать отличные вопросы, направленные на повышение понимания всей команды. Примеры могут быть такими:
- «Вы упомянули кое-что о разделении этой таблицы, чего я не понял. Не могли бы вы рассказать мне об этом еще немного? "
- «Мне сложно понять, как устроен этот проект. У нас есть какие-либо документы, на которые вы могли бы указать мне? »
- «Я пытался узнать немного больше о том, как использовать ansible, но я думаю, что застрял. Не могли бы вы помочь мне кое-что прояснить? "
Я сделал слишком много заявлений
С другой стороны, когда я не задавал вопросов, я делал заявления. Обычно эти заявления были непропорционально громкими или уверенными по сравнению с тем, что я знал.
Я обнаружил, что это случилось со мной примерно через год. На тот момент я получил много знаний, не чувствовал себя новичком и хотел показать то, чему научился на работе. Я думаю, что на самом деле важно помнить: типы совершаемых ошибок со временем будут меняться в любой карьере.
Я был слишком быстр, чтобы отстаивать свое мнение, и был слишком горд, чтобы слушать других.
Я не осознавал, как много я этим занимался, пока не оказался на грани краха. В нашей команде появились новые старшие инженеры, которые посмотрели на то, что мы строили, и быстро начали показывать нам, что мы делаем неправильно. Конечно, до этого в нашей команде должно было быть несколько настоящих старших инженеров, но мы не можем это контролировать.
Именно в этом процессе я понял, что все еще не знаю, что делаю. Мне еще предстояло узнать больше, чем я думал. Я научился слушать, снова задавать вопросы и нормально относиться к незнанию всего.
Вероятно, вы испытаете похожий момент. Время, когда вы понимаете, что многому научились, но по-настоящему смиренно осознаете, что вам есть чему поучиться. Если можете, постарайтесь получить это раньше, чем позже. Чем раньше вы по-настоящему осознаете, что никогда не узнаете всего, тем быстрее вы начнете учиться и расти.
Я перестал писать код, не связанный с проектом
Здесь, я думаю, я потерял больше всего позиций. Вместо того, чтобы продолжать оттачивать старую школу кодирования, я все больше и больше сосредотачивался только на коде, который находился передо мной.
Не поймите меня неправильно, сосредоточение внимания на коде и проектах для моего работодателя было (и остается) жизненно важным для того, чтобы стать успешным инженером. Тем не менее, мне хотелось бы, чтобы я потратил, скажем, два часа в неделю на кодирование для конкретного проекта, либо на разработку с открытым исходным кодом, либо на решение задач кодирования на LeetCode или TopCoder.
Почему? Ну, потому что через некоторое время код большинства проектов имеет тенденцию находить «массу» вокруг нескольких конкретных концепций кодирования. Я работаю в основном над созданием распределенных сервисов с высокой пропускной способностью и малой задержкой, которые обмениваются данными через RESTful API у моего текущего работодателя. В нем есть несколько серьезных проблем, но через некоторое время большинство из них становятся похожими друг на друга. Поэтому я считаю, что решаю большинство из них очень похожими способами.
Но я не работал ни над чем, связанным с графическими движками или даже с простыми текстовыми редакторами (и многими другими). Я не знаю наверняка, что у них другой набор проблем, держу пари, что они есть.
Работа над другим кодом, помимо ваших рабочих проектов, - отличный способ поддержать ваши общие навыки программирования и, возможно, улучшить свое резюме за счет вкладов с открытым исходным кодом. Бьюсь об заклад, если вы будете инвестировать всего несколько часов в неделю, ваши навыки резко возрастут. Если вы думаете, что у вас нет времени, спросите своего руководителя, можете ли вы договориться о том, сколько времени вы можете потратить на это на работе. В конце концов, стать лучшим инженером ценно для вас и для них.
Конечно, я сделал еще много ошибок. Это просто те, которые мне больнее всего.
Первые два сводятся к гордости за то, что либо не выглядят глупо, либо хотят выглядеть лучше перед другими. Не попадитесь в эти ловушки! Когда вы сосредоточены на том, что думают о вас другие, помните: Возможно, им все равно, как вы думаете.
Последний - просто олдскул. Я забыл попрактиковаться в навыках, которые в первую очередь привели меня к моей первой должности в области разработки программного обеспечения, которая заключалась в преданности делу программирования. С тех пор как я стал старшим инженером, я пишу больше кода, не связанного с проектом, чем когда-либо, и это помогло мне написать лучший код для моих рабочих проектов (и писать его быстрее!).
Надеюсь, это поможет вам сориентироваться, начиная свою карьеру программиста! Если у вас есть другие ошибки, которыми вы хотели бы поделиться или задать вопросы, оставьте их в комментариях. Я не идеален (ясно из этого поста), но я хотел бы попытаться помочь, если смогу.
Удачного кодирования!
