Я изучал программирование дома и был блестящим выпускником буткемпа (то есть по меркам этого буткемпа, который, конечно, не так хорош, как лучшие буткемпы в США*), я довольно легко нашел работу, учитывая, насколько тяжело, по моему мнению, это должно было быть. . Интервью прошло очень хорошо.
Теперь я работаю в технологической компании, у которой в основном есть одно основное программное обеспечение, которое она пишет для других очень крупных компаний, и это ставит несколько проблем: 1) мне сложно понять, что все делает (они писали/обновляли это программное обеспечение для лет), 2) я вижу код, написанный непривычным для меня образом, и, наконец, 3) я не понимаю весь код с первого взгляда, иногда совсем не понимаю. Моей основной задачей на следующие 6 месяцев будет написание модульных тестов, а затем интеграционных тестов, потому что «вам нужно привыкнуть к нашему программному обеспечению», что, я думаю, имеет смысл, хотя мое интервью не имело к этому никакого отношения. Большинство людей очень милые и дружелюбные, и в этой компании царит хорошая атмосфера.
Моя проблема в том, что мне приходится писать тесты для методов, которые я не понимаю большую часть времени, я не всегда понимаю, какие параметры они должны принимать, что они возвращают, я не знаю, что я должен издеваться над чтобы сделать мой метод пригодным для модульного тестирования, и я не всегда понимаю инструкции, которые мне дают. По прошествии двух недель я могу с уверенностью сказать, что я явно не создавал ценности для этой компании, и другие разработчики, которые помогали мне, могли бы выполнять мою работу вместо того, чтобы проводить со мной время.
Я очень расстроен, потому что я очень хочу учиться, однако, не просмотром видео на Pluralsight/чтением статей я не стану лучше справляться с тем, что бросает мне вызов (или я ошибаюсь?), поэтому я даже не могу практиковаться дома. . Я думаю, что смущаюсь всякий раз, когда задаю вопрос, поэтому часто застреваю, глядя на экран и пытаясь понять смысл того, что читаю. Я чувствую себя самозванцем в окружении людей, которые «понимают это», и, честно говоря, моя уверенность сильно пострадала (я превратился из возможно лучшего в своем классе в определенно худшего в компании). В плохие моменты я иногда ловлю себя на мысли, что заняться разработкой программного обеспечения было хорошей идеей, и не стал ли я жертвой заблуждения о невозвратных затратах (например, «Я потратил слишком много времени на изучение этого, чтобы уйти сейчас»).
Мои вопросы:
Это нормально?
Что я могу сделать лучше?
Как я мог донести это (или часть этого) до руководства и коллег, не прослыв мошенником?
Редактировать:
Я проработал там всего 2 недели, это моя 3-я работа. Предыдущие места работы длились 7 месяцев и 1,5 года.
*Я не был ясным и не хотел показаться высокомерным; Я не думаю, что этот буткемп исключительный, поэтому быть блестящим в нем, вероятно, мало что значит на рынке труда, в отличие от лучших буткемпов в США. Этот буткемп базируется в Европе, и я бы сказал, что он средний. Более того, я считаю, что огромной причиной моего успеха было то, что я изучал программирование в течение 1 года, и люди рядом со мной понятия не имели, что такое «переменная», поэтому у меня было огромное преимущество, и в целом это было гораздо менее ошеломляюще, чем для моих сокурсников.
По прошествии двух недель я могу с уверенностью сказать, что я явно не создавал ценности для этой компании, и другие разработчики, которые помогали мне, могли бы выполнять мою работу вместо того, чтобы проводить со мной время.
Вы не будете создавать «чистую положительную» ценность для компании намного дольше (даже когда я нанимаю старших разработчиков, я предполагаю, что они не будут приносить чистую положительную прибыль в течение 6 месяцев).
Все, что вы упомянули в своем вопросе, на самом деле является хорошим знаком - похоже, они делают интересное и нетривиальное программное обеспечение, а это означает, что у вас есть много возможностей учиться, и это означает, что они вкладывают в вас - давая вам время и пространство, чтобы набрать скорость.
Написание модульных и интеграционных тестов — довольно распространенный способ адаптации новых младших сотрудников. Вы изучите IDE, систему управления исходным кодом, процесс сборки и все различные формальные и неформальные рабочие процессы разработки программного обеспечения, сосредоточив внимание на относительно небольших кусках работы. Вы также узнаете много нового о бизнес-функциях, предоставляемых их программным обеспечением.
1 - Это нормально?
Да. Вы не самозванец, и нет причин думать, что идти в эту область было плохой идеей. На самом деле, судя по тому, что они наняли вас и хотят инвестировать в вас, кажется, что это была хорошая идея. Самое главное — избавиться от наивного убеждения, что только потому, что вы были «возможно, лучшим» в своем учебном лагере, это означало, что вы были готовы пойти в магазин разработчиков с первого же дня и начать приносить пользу. Учебный лагерь дал вам базовые основы программирования — для того, чтобы стать профессиональным разработчиком, нужно многое, многое, многое другое, чему вы можете научиться только на работе.
2 - Что я могу сделать лучше?
Я думаю, что есть два «приложения» к этому. Во-первых, это то, что вы можете сделать самостоятельно. Потратьте свое время на изучение языка, на котором вы программируете, — тонкости, расширенные функции и т. д. Даже если ваш учебный лагерь был на том же языке, над которым вы сейчас программирую на одном и том же основном языке более 10 лет и каждый день узнаю что-то новое). Если какие-либо другие инструменты, которые они используют, общедоступны/бесплатны (IDE, инструмент управления исходным кодом), попрактикуйтесь и с ними. Кроме того, потратьте время на изучение основ компьютерных наук (алгоритмы, структуры данных). Даже если вы не используете эти знания сразу, они всегда пригодятся.
Второй, хотя и не связанный непосредственно с проводимым вами тестированием, может быть выполнен как часть этой работы. То есть развить способность «анализировать» фрагмент кода. Возьмите самый простой тест, который вы можете найти, протестировав простейший фрагмент кода, и попытайтесь разработать поток управления для этого фрагмента кода. Пропустите его через отладчик, останавливаясь на каждой строке, и посмотрите, что он на самом деле делает. Немного измените тест и посмотрите, как он будет вести себя по-другому. Попробуйте придумать тест, который будет проверять другую ветвь if (и т. д.). Используйте свой инструмент управления исходным кодом IDE и просмотрите самую последнюю фиксацию, которая изменила этот код. Посмотрите, можете ли вы понять, что сделало это изменение (особенно полезно, если вы можете вернуться к заявке, в которой задокументировано это изменение). Перейдите к чуть более сложному тесту и повторите. Теперь возьмите кусок кода, который они хотят, чтобы вы протестировали, и проведите этот анализ заранее. Используйте это, чтобы написать свой первый тест.
Если вам нужна помощь, попросите автора теста или кода, который вы ищете, предоставить вам обзор.
3 - Как я мог сообщить это (или часть этого) руководству и коллегам, чтобы не показаться мошенником?
Никто не рождается со знанием кода. Поэтому все ваши коллеги и руководители начинали с того же места, что и вы. Пока они не придурки (а вы уже сказали, что это не так), они знают и ожидают, что вы попросите их о помощи.
Конечно, вам нужно будет найти правильный баланс между тем, чтобы задавать слишком много вопросов и не обращаться за помощью слишком рано. Я часто говорил своим джуниорам: «Не тратьте 3 часа на то, чтобы понять, с чем я могу вам помочь за 5 минут». И наоборот, не тратьте мои 5 минут, если вы не потратили некоторое время, пытаясь понять это самостоятельно.
Если вы еще не запланировали встречу, попросите своего руководителя о еженедельной 30-минутной встрече. Чтобы процитировать другой ответ, который я написал здесь:
работа вашего менеджера [состоит] в том, чтобы сделать все возможное, чтобы предоставить вам возможности для достижения успеха - это может произойти только в том случае, если вы двое регулярно и часто разговариваете, и если во время этих разговоров вы открыто и честно говорите о том, в чем у вас возникают трудности, где вам нужна поддержка, где вы застряли, и где вы узнаете, что он/она ожидает от вас.
Одна из самых важных вещей, которые нужно задать, это «с чего мне начать» и «к кому мне обратиться за помощью».
Удачи!
One of the most important things to ask is "where should I start" and "who should I bother for help".Я проработал там всего 2 недели
Вы должны дать ему намного больше, чем просто 2 недели.
Принимайте меры постепенно. Вы почти наверняка обнаружите, что каждая неделя более комфортна, чем предыдущая.
Воспользуйтесь приятной и дружелюбной культурой. Просите о помощи, когда она вам нужна.
И не будьте так строги к себе. Если вы изучали программирование самостоятельно, а затем блестяще выступили на буткемпе, то, скорее всего, у вас все будет хорошо, если вы проявите немного больше терпения и усердной работы.
Добро пожаловать в джунгли. :)
Да. Это нормально. Ты младший. Ожидается, что вы не будете иметь ни малейшего представления, и именно поэтому они заставляют вас делать то, что вы делаете.
Задавать вопросы. Получите понимание. Спросите, что вы можете прочитать в свободное время, чтобы помочь вам развить понимание. Будьте готовы много работать, даже если проведете несколько часов вне работы. Я был бы обеспокоен младшим разработчиком, который НЕ задавал вопросов. Готов поспорить, что любой из ваших коллег старшего возраста начинал так же, как и вы.
Задавайте вопросы и учитесь. Со временем вам не придется задавать вопросы. Он просто щелкнет, и вы получите его.
Как все говорят, две недели — это ничто. Вам потребуется гораздо больше времени, чтобы набрать скорость. И ваш руководитель и коллеги ожидают этого.
Я хотел бы взять одно предложение, чтобы прокомментировать:
Моя проблема в том, что мне приходится писать тесты для методов, которые я не понимаю большую часть времени, я не всегда понимаю, какие параметры они должны принимать, что они возвращают,...
Как я понимаю, это провал документации . Что также ужасно распространено. В идеальном мире должно быть описание всего доступного, но очень часто его нет.
Итак, ваш первый вопрос должен быть, если вы пропустили какую-то документацию. Наиболее вероятный ответ — «нет», но спросить стоит.
Я бы предложил написать эту документацию перед выполнением модульных тестов. Это позволяет задать вопрос: «Правильно ли я понял назначение этой функции?» Сама документация будет ценна для компании, и модульные тесты, скорее всего, проверят то, что они должны тестировать.
Может быть трудно набраться смелости, чтобы прервать занятого коллегу вопросом, который, вероятно, будет тривиальным. Как и должно быть, прерывания отстой.
Вместо этого вы должны запланировать встречу. Таким образом, это только одно прерывание вместо многих. Если у вас есть вопрос, который блокирует вашу работу, отложите его и найдите другую задачу.
Готовьтесь к встрече. Имейте список вопросов, точные ссылки на любые соответствующие источники или документы и так далее.
Поначалу вам понадобится много таких встреч, но по мере того, как вы будете лучше знакомиться со всем, дела пойдут лучше.
1 - Это нормально?
Да. Сидеть там, смущенно глядя на чужой код и спрашивая себя, что вы делаете, — это нормально на всех уровнях, даже после десятилетий опыта. Что меняется, так это то, как вы справляетесь с этим.
2 - Что я могу сделать лучше?
Держись! Не сдавайся. Две недели - это не повод для беспокойства. Когда-то я был тимлидом/ведущим разработчиком такого приложения, как ваше, и новым людям требовалось более двух месяцев , чтобы стать более продуктивными, иногда на это уходили годы. Людям может потребоваться неделя или больше, чтобы только инициализировать свою среду разработки, получить возможность скомпилировать исходный код для устаревших приложений и еще несколько недель, чтобы заставить их работать на своем ноутбуке. И так далее.
3 - Как я мог сообщить это (или часть этого) руководству и коллегам, чтобы не показаться мошенником?
Вы не говорите о том, что чувствуете себя мошенником; вы объективно говорите о поставленной задаче. Попробуйте проработать возможные решения, а если не можете решить сами, то спросите у своего начальника или ведущего разработчика. Если это означает, что вы должны спрашивать своего коллегу весь день, каждый день, пусть будет так. Если (и когда) ваш коллега дает вам ощущение, что это слишком много, спросите у своего начальника, у кого еще спросить, есть ли у него другие источники информации, или согласен ли он с тем, что вы тратите много времени на то, чтобы спотыкаться в темный.
Будьте прозрачными; убедитесь, что ваши «заинтересованные стороны» знают, что вы делаете. (Это искусство сделать это таким образом, чтобы не действовать всем на нервы - может быть, это тема для другого вопроса; один из способов - поддерживать одностраничник, который вы поддерживаете в актуальном состоянии, и просто рассылать его раз в неделю или раз в два. неделю или что-то в этом роде. Также действительно зависит от вашей корпоративной культуры.)
Это улица с двусторонним движением. Бросить новичка в недокументированный исходный код — хорошее упражнение, чтобы заставить «соки течь», но, в конце концов, никто не ожидал, что здесь произойдет волшебство.
Если у вас есть конкретные технические вопросы, лучше задайте их на одной из более технических бирж стека.
talk objectively about the task at handэто лучший совет, повторять себе, что вы не понимаете, непродуктивно в худшем случае. Единственный способ понять инопланетный код (обожаю эту фразу) — это обсудить его, и как только вы решите, что поняли его, обратитесь к автору, объясните, что, по вашему мнению, он делает или как он работает, и выслушайте его отзывы. Не бойтесь использовать бумагу для рисования диаграмм, которые понимаете только вы, пытаясь что-то решить.Я работал над некоторыми массивными и древними кодовыми базами (3D CAD на C++, некоторые из которых были автоматически сгенерированы из FORTRAN), и в основном я был разработчиком более 35 лет. Все негативное, что я скажу ниже, исходит из чувств и ситуаций, в которых я был!
Как уже говорили другие, вы не одиноки. У меня такой же совет, как и у Стига, но с некоторыми важными нюансами.
Во-первых, для вашей самооценки и, возможно, для вашей работы важно показать, что вы не просто сидите и смотрите на код, чувствуя себя потерянным.
Есть три вещи, которые вы можете написать, чтобы показать, что вы делаете:
Не критикуйте их существующую практику документирования. Это область, которая часто очень противоречива. У людей могут быть свои твердые убеждения, и они могут быть отвергнуты. Вы будете удивлены , насколько глубокими могут быть чувства, связанные с практикой документирования (и написанием тестов).
Не спрашивайте у кого-то совета и не игнорируйте его. Если кто-то дает вам совет, а вы не понимаете, как его применить, подумайте об этом и, по крайней мере, напишите несколько заметок о том, как вы пытались его применить.
Не пытайтесь понять все. Просто не надо . Это, вероятно, самая большая слабость ограниченного кода, с которым люди сталкиваются в образовании (не только на учебных курсах). Очень мало мест, где вас учат программировать, не ожидая, что вы все поймете. Это просто невозможно в больших программах. Отпустите эту потребность понять.
Я думаю, что смущаюсь всякий раз, когда задаю вопрос, поэтому часто застреваю, глядя на экран и пытаясь понять смысл того, что читаю.
Я думаю, это единственное место, где вы ошибаетесь. Новым людям нужно задавать много вопросов, это простой способ для опытных парней решить, что вам нужно знать дальше.
Когда вы обнаружите, что смотрите на экран, напишите электронное письмо (или сообщение в лени, или что-то еще). Отнеситесь к этому как к вопросу о переполнении стека; опишите проблему и то, что вы сделали, и покажите, что вы приложили к ней усилия. В половине случаев это может предложить что-то, что вы не пробовали, или тему, которую вы можете исследовать, и вам не нужно будет отправлять электронное письмо. Если нет, отправьте его и перейдите к другой проблеме, пока ждете ответа.
Электронная почта позволяет другим людям отвечать, когда им удобно, но попросите их позвонить вам, когда вам будет удобно подойти к их рабочему столу, а затем пойти и поговорить с ними. Так вы получите больше информации и построите важные отношения.
Распространяйте свои вопросы, а не занимайте время одного человека, и просите людей показать вам, как они будут решать проблему, а не просто «дать ответ». Вы также должны спросить людей, сколько времени им понадобилось, чтобы изучить систему, и насколько они ее знают. Это должно убедить вас, что у вас все в порядке.
Кроме того, когда вы найдете плохо документированную функцию и потратите некоторое время на ее изучение, вам следует записать то, что вы узнали. Это могут быть комментарии в коде, официальная документация, командная вики или неофициальная заметка (в порядке предпочтения). Тогда вы добавляете ценность и помогаете следующему парню. Вы также можете вести заметки об областях, которые просрочены для рефакторинга, и любых найденных ошибках.
2 - Что я могу сделать лучше?
Я полностью согласен с другими ответами, 2 недели в принципе ничего, так что перестаньте беспокоиться об этом. Но есть одна вещь, которую вы можете и должны улучшить:
Я думаю, что смущаюсь всякий раз, когда задаю вопрос, поэтому часто застреваю, глядя на экран и пытаясь понять смысл того, что читаю.
ЭТО то, над чем вам нужно работать. Есть некоторые вещи, которые вы можете понять самостоятельно, и, как правило, лучше, если вы это сделаете, если это возможно, конечно. Но есть и другие вещи, например, исторические причины некоторых поворотов кода, которые вы никак не можете понять. Вы должны спрашивать об этих вещах, не тратя дни на то, чтобы смотреть на них.
Я не говорю, что вы порхаете по офису, как комар, жужжащий всех на своем пути. Когда вы столкнетесь с такой проблемой, запишите ее. Попросите кого-нибудь (обычно вашего менеджера) сказать вам, кто является экспертом в том или ином вопросе. Затем попытайтесь найти время, когда вы не будете их прерывать (например, назначите настоящую встречу?), и обсудите с ними свой список соответствующих вопросов. Их не будет раздражать постоянный поток вопросов, но у вас все равно будет шанс освоиться.
Нео
ГалактическийКовбой
МаркДжЛ
Слотарио
Азранта
АлександрМ