Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
спасибо, закинул своим коллегам)
В этом алгоритме не хватает очень важного шага:
«Если мне ничего не помогло за полчаса, я должен обратиться за помощью».
Иначе можно всю жизнь прожить, предполагая, что «вокруг работают разумные люди и глупости писать не станут». В оригинале, на который негласно ссылается автор своим заголовком, учили проверять гипотезы.
«Если мне ничего не помогло за полчаса, я должен обратиться за помощью».
Иначе можно всю жизнь прожить, предполагая, что «вокруг работают разумные люди и глупости писать не станут». В оригинале, на который негласно ссылается автор своим заголовком, учили проверять гипотезы.
markitosha Коротко и по делу, спасибо. В повседневной практике сталкиваюсь с такого рода поведением младших сотрудников. С самыми простыми задачами всё достаточно прозрачно, а вот какое относительно оптимальное время на разбор более объемной задачи по алгоритму выше? С какой периодичностью вы интересуетесь статусом задачи?
спасибо!
В начале выполнения больших задач я прошу сотрудника 2 раза в день делать отчеты по задаче в устном или письменном виде: на каком этапе задача, что попробовал, почему выбрал то или иное решение, что будет делать дальше и тд. За полдня он вполне успевает что-то сделать и не успевает уйти совсем не в ту сторону. Каждый отчет обсуждаем и корректируем направление решения. По мере роста сотрудника переходим на менее подробные рассказы и только один раз в день
В начале выполнения больших задач я прошу сотрудника 2 раза в день делать отчеты по задаче в устном или письменном виде: на каком этапе задача, что попробовал, почему выбрал то или иное решение, что будет делать дальше и тд. За полдня он вполне успевает что-то сделать и не успевает уйти совсем не в ту сторону. Каждый отчет обсуждаем и корректируем направление решения. По мере роста сотрудника переходим на менее подробные рассказы и только один раз в день
Пропущен «Вопрос 0: а где, собственно, возникает проблема?» Постоянно наблюдаю это. Начиная со студентов каких-нибудь компьютерных наук: вот он делает задание, которое первый раз видит, в среде, которую первый раз видит, на языке, который первый раз видит. Как бы надо это делать? Написать «hello world», проверить, что компилится, проветить, что запускается, проверить, что действительно выводит надпись «hello world». Далее мелкими шагами двигаться в сторону задания, которое требуется выполнить, на каждом шаге проверяя, что всё ещё компилится, всё ещё запускается, всё ещё делает то, что ты ожидаешь. Чем больше опыт — тем крупнее шаги можно себе позволить. В пределе, когда уже совсем-совсем обалдел знаниями, наверное, можно будет позволить себе написать сразу целиком всю портянку, и она скомпилится, запустится и сделает всё как надо. Наш студент, однако, не идёт инкрементальным путём и сразу пишет портянку, после чего, разумеется, не может понять, чего это она не компилится. Пытаешься помочь — и, разумеется, тоже не можешь понять, как подступиться к этому дикому поделию студенческой мысли, в которое вместо знаний вложены дикие представления данного студента о программировании. Ладно студенты — на stackoverflow реальные разработчики вываливают простыни в стиле «я вот тут читаю через порт данные с прибора, конвертирую и отправляю по сети, а там происходит обработка, почему у меня вот в этом коде при сложении двух положительных чисел иногда вдруг получаются отрицательные?» (пример утрирован совсем не так сильно, как хотелось бы!) Далее простыня кода, там всё — и чтение через порт с прибора, и отправление по сети, и т. д., и т. п. SSCCE (в процессе составления которого, вероятно, ты сам и поймёшь суть, и найдёшь решение своей проблемы)? Не, не слышали. Изолировать проблему, прежде чем устанавливать её суть? Ну зачем это, мир же сложен во всём его многообразии, давайте сразу комплексно подходить…
Полностью разделяю вашу боль. Планирую делать цикл статей на тему рационального мышления и посвятить этому вопросу отдельную статью (а может даже две: декомпозиция задач и искусство дебага)
Тут описана проблема отсутствие фундаментальных знаний. По идее прежде, чем писать код, нужно изучить IDE, язык программирования, алгоритмы и т.д. Тогда все пойдет намного быстрее и понятнее.
советы конечно полезные и не только для джуниоров, у джуниоров обычно другая проблема это не понимание того что одну и туже задачу можно решить кучей способов, обычно в голову приходит 1-2 очень простых способа и всё вспоминая себя я не понимал почему архитектор забирал себе на первый взгляд простые таски на додумывание, по мне херак-херак и продакшен чё там думать, теперь же с 10+ годами опыта работы в разных проэктах разной сложности наоборот не всегда понятно почему же джуниоры и не только не видят проблемы в придложенном решении вроде же очевидно что если так сделать то следующий разработчик который на этот код посмотрит будет переделывать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Junior и методы рационального мышления