Эта статья участвовала в "Проект «Звезда раскопок»«Выиграйте креативные подарочные наборы и бросьте вызов творческим поощрениям.
Здравствуйте, я криворукий.
Недавно я взял с собой стажера. На самом деле, недавно прошло целых три месяца, и он уже проходит процесс нормализации.
Я до сих пор помню, что, когда он приехал, чтобы сблизиться с ним, через день после того, как мы закончили говорить о делах, я поговорил с ним.
Тогда я сказал: "В нашей группе не нужно быть осторожным. Когда мы общаемся в мирное время, нет отношений между начальством и подчиненными. Открой свое сердце и не ищи лишних забот". Наша атмосфера очень открыта, и мы много общаемся. На самом деле, не смотрите, сколько мне лет, я не так уж и стар, мне 94 года. Кстати, ты в каком году?
Он ответил: 2000.
Этот момент действительно поразил меня.
Потому что я был удивлен, обнаружив, что пост-00-е также медленно вошли на рабочее место.
После того, как они переняли эстафету "поколения битников" от наших пост-90-х, скоро передадут эстафету пост-10-кам.
Время летает!
обратная связь и размышления
После того, как он присоединился к команде, у него появилась хорошая возможность, когда он получил новое требование в то время, Чтобы выполнить это требование, я должен построить микросервис с нуля.
Я позволил ему участвовать со стадии разработки проекта и, наконец, проследил за запуском проекта. Прочувствовал весь процесс запуска проекта.
Для него это была возможность.
Для меня это на самом деле вызов, потому что общего времени на этот проект не хватает, а еще больше напрягает, когда его отводят на стадию разработки. Для того, чтобы обеспечить прогресс, на тот момент двух других коллег из проектной группы срочно перевели делать это вместе со мной, так что с человеческими ресурсами по-прежнему было очень туго. Ход выполнения задачи необходимо продвигать в единицах дней.
Лидер спросил меня: как ты хочешь устроить этого стажера?
Я сказал: пусть он разрабатывает этот проект вместе с нами, я ему поставлю задачи, а ресурсы на разработку отчитаюсь за половину человеческих усилий.
На самом деле, когда я сказал «половина» личного состава, у меня в сердце стучали барабаны. Поскольку он не пришел на мое собеседование, он присоединился к команде проекта примерно на неделю, и я даже не видел написанного им кода, поэтому не знаю, на каком уровне он технических способностей.
Но, судя по конечному результату, на самом деле расшифровка, которую он передал в проекте, намного превосходит половину человеческих усилий.
Другими словами: общая производительность превзошла ожидания.
Например.
Я разделяю ему задачу, и после выяснения предыстории требований даю ему реализовать код.
Пока он пишет, он обнаруживает, что где-то есть детали, которые не учитываются в требованиях.
Поэтому он быстро даст мне обратную связь и в то же время предложит свое решение и спросит, можно ли его реализовать таким образом.
Обратная связь по проблемам с решениями.
Это кажется простым и естественным делом, но я считаю, что чем новее вы на рабочем месте, тем лучше.
А старые оладьи, включая меня, на самом деле во многих случаях недостаточно хороши. Я буду тянуть время, буду замазывать, я почувствую, что это на самом деле не большая проблема, я найду решение, которое считаю само собой разумеющимся, и изменю его...
Но я думаю, что за этой простой вещью стоит несколько уровней логики.
Первый уровень логики: я сам нашел проблему.
Если вы можете найти проблему, то, по крайней мере, у вас есть определенная степень понимания предыстории кода, который вы написали.
Только на основе понимания потребностей мы можем самостоятельно найти проблемы в лендинге.
В общем, это может сделать каждый.
Второй уровень логики: если проблема будет обнаружена, вы дадите обратную связь?
Нет обратной связи на самом деле с точки зрения разделения обязанностей.Даже если есть проблема,основная ответственность лежит не на мне.Я не учел эту проблему,когда выдвигал требование.
Количество отзывов увеличилось, и, наконец, проблема была решена, что увеличило мою рабочую нагрузку.
На этом уровне некоторые студенты после ожесточенной идеологической борьбы решат: уже слишком поздно, так что давайте пока. Нет обратной связи, это не большая проблема.
Насыпь в тысячу миль была разрушена в муравейнике.
В проекте много мелких проблем, и будут большие проблемы.
Если это действительно небольшая проблема, даже если вы нажмете TODO и отметите это там? Чтобы потом себя не забыть.
На самом деле в большинстве случаев такие проблемы можно обнаружить и в процессе тестирования.
Но если вы можете его предсказать, то почему его следует откладывать до тех пор, пока не будет открыт тестовый сеанс?
Другими словами, после ожесточенной идеологической борьбы я решил: я знаю, как изменить это место, мне нужно только изменить его напрямую, и я не буду обсуждать это с другими, а отзыв давать лень.
Это на самом деле табу, легко закопать дыру.
Например, вы не знаете, где взять значение поля, а требования четко не сформулированы. Но вы можете взять его откуда-то сами или передать из апстрима.
Так что вы решаете получить его самостоятельно, не заморачиваясь вверх по течению.
Потому что есть два источника, пусть два источника должны быть сильно равны при написании кода, но с развитием системы могут быть разные ситуации, и когда такая ситуация возникает, вот яма.
Возможно, к тому времени вы сами забыли, что это значение — это то, за чем вы идете куда-то, а не передается от апстрима.
Когда это действительно пойдет не так, проверьте код: кто написал этот код? Почему бы не пропустить вверх по течению?
Потом сердито смотришь на историю коммитов и начинаешь молчать.
Третий уровень логики: предлагайте свои собственные решения для обратной связи.
На мой взгляд, активная обратная связь — это то, что нужно делать.
Что касается того, может ли это принести решение, трудно сказать.
Потому что иногда из-за отсутствия контроля над общей ситуацией они действительно могут только находить проблемы, но не могут их решить.
Таким образом, это не является обязательным для новых сотрудников или стажеров, но это лучшее, что можно сделать.
Например, этот стажер, каждый раз, когда он приходил ко мне за обратной связью, он говорил план, который он имел в виду, и спрашивал, может ли он сделать то же самое.
На самом деле, во многих случаях решение, которое он дает, не очень хорошее.Например, он хочет выполнить обработку на основе определенного возвращаемого значения, но я думаю, что лучшее решение должно быть сделано на основе определенного состояния данных или добавить базу данных. поле для него.Этот вопрос.
Это больше соответствует логике программирования.
Дело не в том, что план, который он дал, не является непригодным, есть варианты получше.
Однако это отражает его собственное дальнейшее мышление.
Из реальной ситуации он также предложил много хороших планов реализации, которые я принял.
Хорошо иметь возможность предложить решение и показать, что у вас более глубокое мышление.
Мышление и обратная связь, независимо от стадии, важны.
Я сам иногда недостаточно хорошо справляюсь, но я часто напоминаю себе и спрашиваю себя.
Другой пример
Вот еще один небольшой пример обратной связи:
После того, как я дал ему задание, я сказал ему, когда сделать это раньше.
В течение этого периода он возьмет на себя инициативу и расскажет мне, какого прогресса я добился. Если он не сможет закончить к ожидаемому времени, он заранее скажет мне, в чем сложность.
Таким образом, он позволит мне вовремя контролировать ход всего проекта и позволит заранее предотвратить риски.
Я также привел коллег, которые работали несколько лет назад, иногда выполнение задания отстает, и это все отзывы от однокурсников-тестировщиков, что делает меня очень пассивным.
Конечно, я также должен иногда проявлять инициативу, чтобы спросить о прогрессе.
Но по моей логике: в большинстве случаев, если вы ничего не сказали и не попросили меня согласовать, то я считаю, что проект продвигается по нормальному ходу.
Я думаю, если задача рискованная, обратная связь за несколько дней, но она слишком важна, это должно быть основным профессиональным качеством.
Что касается того, как определить низкий, средний и высокий риск и какое отношение к нему нужно принять, это другой навык.
В то же время, в течение всего процесса разработки проекта, я фактически постоянно давил на него, в то время как в искушении я также знал, что его способности по-прежнему хороши, и у него есть сильная сила исполнения.
Итак, после того, как этот проект был завершен, в другом проекте, который последовал, я дал ему кучу задач разработки на ключевых узлах, и сказал ему ключевое значение этой задачи разработки во всей цепочке вызовов.
Судя по текущему прогрессу в разработке, то, что он сделал, все еще очень хорошо.
Честно говоря, вначале я поручил ему какую-то «грязную работу», потому что кто-то должен был ее делать.
Как новичок или стажер, даже если у вас есть удивительные навыки, вы можете начать пробовать эти простые задачи только тогда, когда я не знаю, каковы ваши способности.
Если и есть один недостаток, так это то, что код, который он наконец придумал, функционально пригоден для использования.
Однако с точки зрения многоуровневого кода, спецификации кода, последующего расширения и навыков программирования его все еще не хватает.
Я задавал ему эти вопросы с самого начала.
Судя по коду, который он представил сейчас, есть некоторый прогресс, но еще есть много возможностей для улучшения.
Сейчас он может быть еще в стадии нарочитого подражания, и может не понимать, почему финальный фрейм кода именно такой, все равно в проекте так написано.
Поскольку я буду каждый раз сосредотачиваться на просмотре его кода, на самом деле в каждом обзоре будут обнаружены некоторые проблемы со структурой кода.
Например, он может передать объект в интерфейсе на всем пути к уровню dao; например, он может написать новый sql для сопоставления с ним каждый раз, когда он взаимодействует с базой данных, не принимая во внимание возможность повторного использования; например, он много логики в одном и том же методе...
Я думаю, что это неизбежный процесс для студентов, которые только что вошли в рабочее место.От их собственного демо-кода до написания фактического кода инженерного уровня обязательно потребуется процесс адаптации и оттачивания.Это не то, что достигается ночь - это то, что было закалено в повторяющихся практиках разработки.
Осознавать эту проблему, практиковать и преодолевать ее — это рост.
И я обнаружил, что он намеренно имитирует это, видя, что он также оборачивает весь блок кода большим try-catch, чего не было в случае с кодом, который он отправил ранее.
Я сам иногда ленюсь и оборачиваю весь блок кода в большой try-catch. На самом деле код, написанный таким образом, удобен в использовании, но не элегантен и не рекомендуется.
Исключения должны ловиться именно там, где они должны быть пойманы, весь метод обернут, что является хитрым решением, а это означает, что ваш анализ исключений написанного вами кода не совсем на месте, и вы пытаетесь докопаться до сути. это в грубой форме.
Это не хорошо, не хорошо.
Так что после того, как я обнаружил эту проблему, я тоже вовремя с ним пообщался, и заодно выдвинул более высокие требования к себе.
Не ленитесь кодировать. Некоторые вредные привычки нельзя передать.
Так я начал потихоньку понимать, что это не только процесс привлечения новых людей, но и хорошая возможность быть дисциплинированным.
О верно.
Я узнал только тогда, когда пошел на его встречу в защиту регуляризации, что часть наставника все еще собирает голоса.
Поэтому я наспех записал несколько моментов в заметку мобильного телефона:
передача
В моей карьере каждая команда и «наставник» в каждой команде, которую я встречал, были очень добры ко мне, и они делали все возможное, чтобы поделиться со мной хорошими вещами, которыми они овладели.
Так что я также надеюсь передать эту хорошую вещь все время.
Я до сих пор помню, что когда я был стажером, из внешнего интерфейса передавалось поле, и оно должно было попасть в базу данных, что включало преобразование нескольких объектов между несколькими слоями.
Я посадил своего коллегу рядом со мной, и из его наушников время от времени звучала музыка. В нынешнем тревожном настроении малейшая музыка вызывает у меня раздражение.
Поэтому я сказал ему: «Можешь сначала выключить музыку?»
Он услышал разницу во мне, выключил музыку и сказал: У тебя были какие-то сложные проблемы?
В конце концов, он научил меня, как решить эту проблему.
Позже я рассказал ему об этом за едой: я сказал, что я чувствовал, что мне было так плохо в то время. Я часами не успевал над таким простым делом, и в конце концов, ты должен был выйти .
Он сказал: Я не думаю, что ты плохой, но я не боюсь тебя плохо. Боюсь, что твое собственное прихождение, получите его, не спрашивайте меня. Вы не спрашиваете меня, я не знаю, как вам помочь. Есть вещи, которые вы делаете за пределами диапазона возможностей, независимо от того, насколько у вас сложно, трудно увидеть преимущества. Некоторые вещи, это вопрос в пределах твоей способности, и вы не должны делать, то вы должны пойти в их сложные навыки. Тяжелая часть - это то, как вы пошли четко определить эти проблемы. Например, вы говорите это, вы также должны знать, что это ваш и не должен делать, то вы должны пойти, чтобы улучшить свои соответствующие навыки. Вы делаете это, теперь вы снова бегите в эту проблему, оно должно быть быстро решено. Это рост.
Я приводил стажеров и людей, которые работали дольше меня.
Это направление работы не похоже на какое-то старинное мастерство, которое нужно передавать из поколения в поколение и обучать его.
Но в этой отрасли есть и хорошие вещи, которые подытожили предшественники, и их следует передать.
Ну давайте сюда напишем.