Я прочитал Как вести себя с некомпетентным коллегой? , но у меня ситуация немного другая.
Я стажер 1 (хотя близок к выпуску), работаю в области разработки программного обеспечения. Я работаю в небольшой команде с несколькими людьми над небольшим проектом. Проект не так важен для основной рабочей нагрузки, и поэтому мы не испытываем цейтнота. Несмотря на это, я все еще стараюсь произвести хорошее впечатление как на своих коллег (все они работают полный рабочий день), так и на компанию в целом, которая включает в себя функции финишной обработки (полностью протестированные и внедренные) своевременно.
Моя проблема возникает в том, что один из моих коллег совсем не хороший программист. Несмотря на то, что они очень умны, программирование, кажется, не подходит для них, и они с трудом пишут самый простой код.
Например, когда я объединяю программу с этим человеком, чтобы попытаться помочь ему с функцией, я могу подсказать ему и сказать что-то вроде «теперь нам нужно что-то сделать с каждым элементом в этом массиве», и они не могут понять, что нам нужно создать простой цикл или сформировать базовый синтаксис или даже сгенерировать псевдокод с английского, например
foreach element in array
print element
У этого человека изначально не было опыта программирования, он проработал в компании около года и, похоже, не добился никакого прогресса в освоении концепций, которые должен был бы знать студент первого семестра компьютерных наук, несмотря на то, что посещал онлайн-курсы.
Хотя это и не входит в мои должностные обязанности, я чувствую себя обязанным помогать им и пытаться учить их, когда они в этом нуждаются (что бывает в большинстве случаев), как из-за желания, чтобы наш проект продвигался вперед, так и просто потому, что они действительно милые и мне нравятся помогаю. В конце каждого дня, когда я работал с ними, я чувствую себя истощенным от попыток научить их, а также от выполнения своей работы. Мы очень медленно продвигаемся по их функции (над которой они работают уже около 2 недель, хотя я мог бы сделать это сам за несколько часов), потому что я пытаюсь убедиться, что они понимают все в коде и как на самом деле программировать. когда мы работаем вместе, и они ничего не достигают, когда я не помогаю.
Я рассмотрел несколько вариантов; однако отсутствие у меня опыта означает, что я действительно понятия не имею, как с этим справиться. Должен ли я поговорить с нашим руководителем группы 2 ? Я чувствую, что они должны понимать, что у моего коллеги не все в порядке, и они как бы тянут меня вниз. Должен ли я отказаться помогать им, чтобы выполнить свою работу? или есть какой-то другой курс действий, который мне лучше всего предпринять?
1) У меня осталось около 6-7 недель стажировки. Дата окончания у меня гибкая. Я бы подумал о работе там в будущем (может быть, не сразу после выпуска, но хотел бы оставить дверь открытой).
2) В качестве уточнения, наш руководитель группы — еще один инженер-программист, а не руководство. У всех нас есть один управляющий выше по пищевой цепочке.
«Хотя это и не входит в мои должностные обязанности, я чувствую себя обязанным помогать им» . Это указано в вашей должностной инструкции. Это просто никогда не записывается, но это одна из тех вещей, которые всегда предполагаются, когда вы работаете в команде. Также предполагается, что вы сообщаете своему руководителю, если ваша работа занимает больше времени, чем ожидалось, и позволяете ему принять решение относительно приоритетов.
Вы упомянули, что дедлайна нет, поэтому я бы предложил:
Я рекомендую, что бы вы ни делали, чтобы помочь этому человеку, вы должны быть абсолютно на 100% уверены, что вы более продуктивны и действительно добиваетесь чего-то. Если вы потратили 2 недели, помогая им и добившись очень мало, вам нужно иметь еще 2 недели, когда вы многого достигли сами и имели видимые доказательства этого.
Выполнение вашей работы всегда должно иметь приоритет над помощью им.
Я бы посоветовал пока потерпеть. Старайтесь максимально помогать своим коллегам. Однако, как говорит @Jane. Как уже упоминалось, если вы решите работать в одной и той же команде полный рабочий день, вы можете подумать о том, чтобы решить проблему в это время. А пока продолжайте хорошую работу, которую вы делаете. Было бы хорошо быть профессионалом, а также милым/добрым со всеми в команде (даже в будущем). Удачи.
Хотел бы добавить здесь - несмотря на то, что на вопрос был дан ответ ... много лет назад.
Преподавание никогда не бывает улицей с односторонним движением.
Все умнейшие люди в мире, которые отдают свое время, соглашаются, что они учатся у своих учеников. Навыки и извлеченные уроки различны, но это ценный обмен, если кто-то способен понять, что ему предлагают.
Команда была собрана не случайно. Этот конкретный «неопытный» программист привнес в команду что-то, чего не сделали другие люди - тот факт, что в ваших глазах у них не было последовательности, должен быть флагом того, что они имеют ценность, которую видят менеджеры, а вы нет ... это, вероятно, предметная экспертиза или оценка бизнеса, которая на самом деле является целью вашей программы и причиной существования компании.
Мне понравились советы от других - просто удивлен, что никто больше не поднял ценность программиста не в его способности кодировать, а в его способности применять критическое мышление к бизнес-проблеме с выгодой для себя или быть частью команды, которая может Сделай так ...
РЕДАКТИРОВАТЬ: Просто чтобы быть ясным здесь - навыки программирования! = знание бизнеса в реальном мире и без этих знаний, и оба являются «критическими» навыками, а также «критическими» для успеха бизнеса.
Надеюсь, в остальном ваша стажировка прошла хорошо, и у вас все хорошо!
programming problems
связанные с этим навыки программирования не являются средством сами по себе - их нужно применять с business problems
помощью наборов навыков критического мышления, которые отличаются от логики программирования. Возможно, мой выбор слов был слишком похож, или это просто то, с чем вы лично не согласны?
Джейн С
зажигать огни
Джейн С
Брандин
Эдвин Ламбретс
Вьетни Пхуван
зажигать огни
зажигать огни
зажигать огни