Сегодня я продолжу тему разговоров, так как считаю, что коммуникация между людьми - это основная точка опоры проектов. Нет коммуникации - нет проекта. Если только вы не разрабатываете в соло.
Следующая тема называется "Как правильно рассказать".
Пост получился очень большим, поэтому я оформил его в телеграфе =)
Предлагаю продолжить там:
https://telegra.ph/Kak-rasskazat-ob-ehtom-09-17
Следующая тема называется "Как правильно рассказать".
Пост получился очень большим, поэтому я оформил его в телеграфе =)
Предлагаю продолжить там:
https://telegra.ph/Kak-rasskazat-ob-ehtom-09-17
Коль долго не выкладывал постов, то решил немного побаловать вас и добавить один пост сверху на этой неделе =)
Это еще одна тема, которую я рассказываю всем, кто со мной работает в команде.
И эта тема очень часто подрывает пуканы у людей так ярко и сильно, что однажды мы даже ругались из-за нее =)
Тема поста "Фокус. И два дела одновременно".
Часть людей считает, что это нормально - делать работу и параллельно смотреть фильм / подкаст / сериал / слушать музыку, слова которой вы понимаете.
Ну правда, зачем художнику работать в тишине или под музыку без слов? Он вполне может параллельно смотреть передачу Пучкова, пока рисует космические корабли. А иногда даже играть в игры, ведь это пошаговая стратегия - сделал шаг и потом поработал. Сделал второй шаг - поработал.
Но давайте посмотрим на это с другой стороны и проведем эксперимент:
- Попросите придумать какого-нибудь ИИ вам примеры задач на простые сложения 3-хзначных чисел. Штук 50, например.
- Запустите свой любимый сериал, начните параллельно считать задачи в уме и записывайте ответы.
На выходе вы получите либо:
- Ответы на задачи с ошибками.
- Ответы будут правильными, но непонятно, что было в сериале.
- Ответы будут правильными, понятно, что в сериале, но времени ушло х4 раза.
То есть, когда вы делаете два дела одновременно, то мозг начинает распыляться и выполнять некачественно ОБА действия.
Фокус - штука легко сбиваемая. Если человек поймал фокус, то лучше его не дергать или дергать по минимуму, чтобы он мог сделать дело хорошо.
Когда фокус сбивается, то у человека выгружается все из памяти, и возвращение обратно в работу требует большого количества времени.
Человеку сложно восстанавливать свое внимание к деталям, после того, как его просто спросили "Как дела?". В каком-то из исследований я читал, что отвлечение человека от задачи на 5 минут приводит к возвращению в фокус обратно только через 30-40 минут. А параллельные действия и вовсе не дадут вам сфокусироваться нормально на решении задач.
У меня есть куча примеров, когда люди работают над задачами без фокуса. И часто единственное хорошее решение, которое может быть в этом случае - переделать задачу полностью.
Поэтому, если у вас не получается сфокусироваться, вас постоянно что-то отвлекает - для начала попробуйте перестать смотреть сериал параллельно =)
Если вокруг шумно, и разговоры коллег вас отвлекают - сообщите им об этом, попросите их быть тише. Если есть возможность - найдите другое место для работы. Физическое, не компанию.
Если вы не хотите фокуситься на работе из-за нелюбимой работы / начальства / проекта (итд) - зачем вы там работаете? Поменяйте компанию. Если не можете поменять компанию - делайте работу качественно хотя бы для себя. Ведь это опыт, в первую очередь, для вас. Вы иначе тратите свое время, прожигая его.
Еще одна серьезная причина отсутствия фокуса - это отсутствие сна. Если вы сознательно ложитесь спать в 4 ночи, а просыпаетесь в 7 утра и говорите, что вы идеально выспались и способны перевернуть горы, у меня для вас плохие новости.
Я смотрел выступление на Ted Talks, где хост рассказывал, что если человек не спит минимум 7 часов ночью (это важно), то это сильно бьет по его мозгу, а качество его работы начинает падать в нулину. Огромное количество побочек и прочего я даже расписывать не буду.
Есть интересные исследования, которые доказывали, что человек, работающий 3 дня по 15 часов, выполняет качественно задание ровно так же, как отдохнувший и выспавшийся человек работает 8 часов 1 день. То есть, отсутствие сна и постоянная напряженность настолько сильно пагубно влияет на принятие решений и размышления, что работу можно смело выкидывать и переделывать заново.
В общем, не теряйте фокус, высыпайтесь, не отвлекайтесь и стремитесь качественно выполнять свои задачи =)
Это еще одна тема, которую я рассказываю всем, кто со мной работает в команде.
И эта тема очень часто подрывает пуканы у людей так ярко и сильно, что однажды мы даже ругались из-за нее =)
Тема поста "Фокус. И два дела одновременно".
Часть людей считает, что это нормально - делать работу и параллельно смотреть фильм / подкаст / сериал / слушать музыку, слова которой вы понимаете.
Ну правда, зачем художнику работать в тишине или под музыку без слов? Он вполне может параллельно смотреть передачу Пучкова, пока рисует космические корабли. А иногда даже играть в игры, ведь это пошаговая стратегия - сделал шаг и потом поработал. Сделал второй шаг - поработал.
Но давайте посмотрим на это с другой стороны и проведем эксперимент:
- Попросите придумать какого-нибудь ИИ вам примеры задач на простые сложения 3-хзначных чисел. Штук 50, например.
- Запустите свой любимый сериал, начните параллельно считать задачи в уме и записывайте ответы.
На выходе вы получите либо:
- Ответы на задачи с ошибками.
- Ответы будут правильными, но непонятно, что было в сериале.
- Ответы будут правильными, понятно, что в сериале, но времени ушло х4 раза.
То есть, когда вы делаете два дела одновременно, то мозг начинает распыляться и выполнять некачественно ОБА действия.
Фокус - штука легко сбиваемая. Если человек поймал фокус, то лучше его не дергать или дергать по минимуму, чтобы он мог сделать дело хорошо.
Когда фокус сбивается, то у человека выгружается все из памяти, и возвращение обратно в работу требует большого количества времени.
Человеку сложно восстанавливать свое внимание к деталям, после того, как его просто спросили "Как дела?". В каком-то из исследований я читал, что отвлечение человека от задачи на 5 минут приводит к возвращению в фокус обратно только через 30-40 минут. А параллельные действия и вовсе не дадут вам сфокусироваться нормально на решении задач.
У меня есть куча примеров, когда люди работают над задачами без фокуса. И часто единственное хорошее решение, которое может быть в этом случае - переделать задачу полностью.
Поэтому, если у вас не получается сфокусироваться, вас постоянно что-то отвлекает - для начала попробуйте перестать смотреть сериал параллельно =)
Если вокруг шумно, и разговоры коллег вас отвлекают - сообщите им об этом, попросите их быть тише. Если есть возможность - найдите другое место для работы. Физическое, не компанию.
Если вы не хотите фокуситься на работе из-за нелюбимой работы / начальства / проекта (итд) - зачем вы там работаете? Поменяйте компанию. Если не можете поменять компанию - делайте работу качественно хотя бы для себя. Ведь это опыт, в первую очередь, для вас. Вы иначе тратите свое время, прожигая его.
Еще одна серьезная причина отсутствия фокуса - это отсутствие сна. Если вы сознательно ложитесь спать в 4 ночи, а просыпаетесь в 7 утра и говорите, что вы идеально выспались и способны перевернуть горы, у меня для вас плохие новости.
Я смотрел выступление на Ted Talks, где хост рассказывал, что если человек не спит минимум 7 часов ночью (это важно), то это сильно бьет по его мозгу, а качество его работы начинает падать в нулину. Огромное количество побочек и прочего я даже расписывать не буду.
Есть интересные исследования, которые доказывали, что человек, работающий 3 дня по 15 часов, выполняет качественно задание ровно так же, как отдохнувший и выспавшийся человек работает 8 часов 1 день. То есть, отсутствие сна и постоянная напряженность настолько сильно пагубно влияет на принятие решений и размышления, что работу можно смело выкидывать и переделывать заново.
В общем, не теряйте фокус, высыпайтесь, не отвлекайтесь и стремитесь качественно выполнять свои задачи =)
💯9❤4
И завершая тему общения (надеюсь, не надоела еще вам =)).
Говорите. Постоянно уточняйте все вопросы, все недопонимания и так далее.
Разработчик, который больше спрашивает и уточняет, чем пишет код, делает свою работу более эффективной по сравнению с теми, кто пишет много кода и молчит.
Почему?
Потому что создание систем и архитектур - это комплексная работа, в которой огромнейшее число деталей. И если их все не учесть (или хотя бы бОльшую часть), если не вывести все пятна непонимания, то:
- Будет обязательно проброс своих ресурсов слишком далеко.
- Вы обязательно залезете в чужую зону ответственности, и рано или поздно это заметят и попросят вас переделать.
- Вы будете оверинженерить постоянно. Делать плюшки, которые никому не нужны, решения, которые никому не понадобятся.
- Вы будете собирать не систему заказчика, а свою систему.
В некоторых сценариях разработки игр действительно может быть так, что разработчик берет на себя роль геймдизайнера. Например, когда ГД не справляется с описанием, а никого другого в команде нет.
Но лучше не забирать эту работу у ГД на свои плечи, а помочь ГД понять вопросами, что он хочет. Тогда вы вместе будете в плюсе - ГД начнет учиться правильно подавать информацию для вас, и вы научитесь ставить правильно вопросы так, чтобы все стало понятным.
Главное, чтобы вопросы не воспринимались, как угроза =)
Повторюсь. Вопросы и ответы - это ключ к взаимопониманию того, что вы делаете и как вы делаете.
Не тот программист крут, что пишет красивый код. А тот, кто может добиться полного понимания задачи и сделать ровно то, что от него требуется. Кому какое дело, что там под капотом, если вас попросили собрать машину, а вы собрали космический корабль?
Я не говорю сейчас о том, что вы теперь должны писать код на уровне "лишь бы работало". Нет, не надо в крайности уходить =)
Я говорю сейчас о том, что мы, как программисты, которые отвечают за то, будет ли работать вообще продукт или нет, просто обязаны вникать в суть того, как должен работать этот продукт.
Поэтому, котятки-программятки (да и все котятки вообще), общайтесь, задавайте вопросы, не переживайте, что кто-то начнет о вас плохо думать или бить вас за вопросы.
Помните. Это не вы плохие, потому что у вас есть вопросы. Это они плохие, потому что не хотят на них отвечать, и не важно, какая на это у них причина.
Говорите. Постоянно уточняйте все вопросы, все недопонимания и так далее.
Разработчик, который больше спрашивает и уточняет, чем пишет код, делает свою работу более эффективной по сравнению с теми, кто пишет много кода и молчит.
Почему?
Потому что создание систем и архитектур - это комплексная работа, в которой огромнейшее число деталей. И если их все не учесть (или хотя бы бОльшую часть), если не вывести все пятна непонимания, то:
- Будет обязательно проброс своих ресурсов слишком далеко.
- Вы обязательно залезете в чужую зону ответственности, и рано или поздно это заметят и попросят вас переделать.
- Вы будете оверинженерить постоянно. Делать плюшки, которые никому не нужны, решения, которые никому не понадобятся.
- Вы будете собирать не систему заказчика, а свою систему.
В некоторых сценариях разработки игр действительно может быть так, что разработчик берет на себя роль геймдизайнера. Например, когда ГД не справляется с описанием, а никого другого в команде нет.
Но лучше не забирать эту работу у ГД на свои плечи, а помочь ГД понять вопросами, что он хочет. Тогда вы вместе будете в плюсе - ГД начнет учиться правильно подавать информацию для вас, и вы научитесь ставить правильно вопросы так, чтобы все стало понятным.
Главное, чтобы вопросы не воспринимались, как угроза =)
Повторюсь. Вопросы и ответы - это ключ к взаимопониманию того, что вы делаете и как вы делаете.
Не тот программист крут, что пишет красивый код. А тот, кто может добиться полного понимания задачи и сделать ровно то, что от него требуется. Кому какое дело, что там под капотом, если вас попросили собрать машину, а вы собрали космический корабль?
Я не говорю сейчас о том, что вы теперь должны писать код на уровне "лишь бы работало". Нет, не надо в крайности уходить =)
Я говорю сейчас о том, что мы, как программисты, которые отвечают за то, будет ли работать вообще продукт или нет, просто обязаны вникать в суть того, как должен работать этот продукт.
Поэтому, котятки-программятки (да и все котятки вообще), общайтесь, задавайте вопросы, не переживайте, что кто-то начнет о вас плохо думать или бить вас за вопросы.
Помните. Это не вы плохие, потому что у вас есть вопросы. Это они плохие, потому что не хотят на них отвечать, и не важно, какая на это у них причина.
💯4
Время интересных историй =)
Ко мне обратился человек и попросил помощи в обучении программированию. У него были какие-то навыки базовые написания кода на С++, поэтому я попросил его собрать простую игру-виселицу по моему ТЗ. Он ее собрал и добавил кучу своих плюшек. Тогда я попросил его удалить плюшки, чтобы игра соответствовала моему ТЗ. Он поворчал и пошел переделывать.
Через пару дней он вернулся ко мне с тем же самым, но теперь иначе. То есть, он удалил все свои хотелки старые и добавил новые. Но его игра не соответствовала ТЗ.
Я попытался объяснить ему, что сейчас код не важен, но он обиделся и заявил, что программирование - штука сложная, и ему лучше продолжить изучать что-то там свое.
Есть вторая история.
Когда-то там я приступил к работе над одним проектом. Сразу несколько геймдизайнеров уже работали над ним, и была куча документаций о том, как и что работает, но не было прописано то, как именно должен персонаж делать действие Х.
Я спрашивал геймдизайнеров и так, и сяк. Потом делал им всякие инструменты, чтобы они могли поиграться и сказать в итоге, как это действие должно работать. А время шло, а проект надо уже начинать собирать.
В итоге, как бы мне не хотелось, чтобы геймдизайнеры пришли к какому-то представлению о работе фичи, я взял эту часть на себя и подогнал свое решение. Оно не лучшее, но оно работает, и можно двигаться дальше.
А вот и третья история.
Я пришел в середине разработки в один проект, где тут же получил первую и большую задачу - внедрить локализацию в проект. По странному стечению обстоятельств, в проекте полностью отсутствовал какой-либо план по локализации вообще.
В итоге, внедрять локализацию надо было в эпицентре разработки, когда текстов уже создана огромная куча, и они абсолютно в другом месте от проекта - на серверах в таблицах. И надо было сделать так, чтобы локализация не поставлялась вместе с проектом, а была возможность загружать все тексты, звуки и текстуры отдельно (ох уж эти мобильщики).
При этом, надо было учитывать интересы геймдизайнеров и нарративщиков, которые практически наотрез отказывались от работы в редакторе анрила.
А еще надо было учесть кучу всего, что было проигнорировано на старте проекта, и теперь аукалось серьезными ограничениями.
В общем, в целом-то всё понятно. Вот текст, вот команда локазитаторов, вот сервер, куда заливать локализации, вот команды, как выкачивать это с серверов в проект. И можно было бы забуриться на полгода и написать хорошую, крутую систему, которая бы позволила всем быть счастливыми.
Но я пошел другим путём. Я начал распрашивать геймдизов и нарративщиков:
В итоге, вместо того, чтобы садиться и писать систему, я мучал периодически вопросами ребят и рассказывал, как и что работает в анриле, рассказывал, как удобно там хранить тексты и подключать их. А потом адаптировал свои идеи под их ответы.
В какой-то момент в общении выяснилось, что вообще большая часть процессов может быть вырезана, и в итоге задача была выполнена за 2 месяца вместо полгода, плюс оптимизировали процессы для работы с текстом.
Опыт подсказывает мне, что не все готовы задавать вопросы, даже когда им это объясняешь и показываешь на примере, почему это так важно. Не все могут ответить на ваши вопросы, даже если очень захотят. Но и игнорировать вопросы, пытаясь решать задачу в одиночку, может оказаться очень дорого и долго.
Общайтесь. Спрашивайте. Уточняйте. И, самое главное, отвечайте на вопросы с улыбкой =) Помните, если вас спрашивают, значит, есть пятно непонимания.
Ко мне обратился человек и попросил помощи в обучении программированию. У него были какие-то навыки базовые написания кода на С++, поэтому я попросил его собрать простую игру-виселицу по моему ТЗ. Он ее собрал и добавил кучу своих плюшек. Тогда я попросил его удалить плюшки, чтобы игра соответствовала моему ТЗ. Он поворчал и пошел переделывать.
Через пару дней он вернулся ко мне с тем же самым, но теперь иначе. То есть, он удалил все свои хотелки старые и добавил новые. Но его игра не соответствовала ТЗ.
Я попытался объяснить ему, что сейчас код не важен, но он обиделся и заявил, что программирование - штука сложная, и ему лучше продолжить изучать что-то там свое.
Есть вторая история.
Когда-то там я приступил к работе над одним проектом. Сразу несколько геймдизайнеров уже работали над ним, и была куча документаций о том, как и что работает, но не было прописано то, как именно должен персонаж делать действие Х.
Я спрашивал геймдизайнеров и так, и сяк. Потом делал им всякие инструменты, чтобы они могли поиграться и сказать в итоге, как это действие должно работать. А время шло, а проект надо уже начинать собирать.
В итоге, как бы мне не хотелось, чтобы геймдизайнеры пришли к какому-то представлению о работе фичи, я взял эту часть на себя и подогнал свое решение. Оно не лучшее, но оно работает, и можно двигаться дальше.
А вот и третья история.
Я пришел в середине разработки в один проект, где тут же получил первую и большую задачу - внедрить локализацию в проект. По странному стечению обстоятельств, в проекте полностью отсутствовал какой-либо план по локализации вообще.
В итоге, внедрять локализацию надо было в эпицентре разработки, когда текстов уже создана огромная куча, и они абсолютно в другом месте от проекта - на серверах в таблицах. И надо было сделать так, чтобы локализация не поставлялась вместе с проектом, а была возможность загружать все тексты, звуки и текстуры отдельно (ох уж эти мобильщики).
При этом, надо было учитывать интересы геймдизайнеров и нарративщиков, которые практически наотрез отказывались от работы в редакторе анрила.
А еще надо было учесть кучу всего, что было проигнорировано на старте проекта, и теперь аукалось серьезными ограничениями.
В общем, в целом-то всё понятно. Вот текст, вот команда локазитаторов, вот сервер, куда заливать локализации, вот команды, как выкачивать это с серверов в проект. И можно было бы забуриться на полгода и написать хорошую, крутую систему, которая бы позволила всем быть счастливыми.
Но я пошел другим путём. Я начал распрашивать геймдизов и нарративщиков:
- А может быть им не важно, если они будут не в таблицах писать тексты, а сразу в инструменте локализаторов?
- А может, им не важно, что потом с текстом будет?
- Может, им вовсе не нужны старые инструменты, и они готовы просто работать в редакторе?
В итоге, вместо того, чтобы садиться и писать систему, я мучал периодически вопросами ребят и рассказывал, как и что работает в анриле, рассказывал, как удобно там хранить тексты и подключать их. А потом адаптировал свои идеи под их ответы.
В какой-то момент в общении выяснилось, что вообще большая часть процессов может быть вырезана, и в итоге задача была выполнена за 2 месяца вместо полгода, плюс оптимизировали процессы для работы с текстом.
Опыт подсказывает мне, что не все готовы задавать вопросы, даже когда им это объясняешь и показываешь на примере, почему это так важно. Не все могут ответить на ваши вопросы, даже если очень захотят. Но и игнорировать вопросы, пытаясь решать задачу в одиночку, может оказаться очень дорого и долго.
Общайтесь. Спрашивайте. Уточняйте. И, самое главное, отвечайте на вопросы с улыбкой =) Помните, если вас спрашивают, значит, есть пятно непонимания.
💯9
Как всегда - работы много, а посты не получается сделать на 15 слов. Хочется перфекционизма и качественного контента =)
Поэтому слегка задержалси =)
И так. Следующий пост о том, сколько строк кода должен писать программист в день. Прочитать ее по традиции можно в телеграфе по ссылке:
https://telegra.ph/Skolko-strok-koda-ty-pishesh-10-22
Поэтому слегка задержалси =)
И так. Следующий пост о том, сколько строк кода должен писать программист в день. Прочитать ее по традиции можно в телеграфе по ссылке:
https://telegra.ph/Skolko-strok-koda-ty-pishesh-10-22
❤7
И в догонку следующий опросник =)
На какие темы вы бы хотели больше видеть постов:
На какие темы вы бы хотели больше видеть постов:
Anonymous Poll
26%
Больше о работе в целом 🥳
25%
Больше об управлении 🔨
17%
Больше о взаимоотношениях в командах 😛
53%
Больше о программировании 🤩
2%
А можно свое вогнать в комментах? ✨
36%
Интересно всё 😂
❤2
Спасибо всем котяткам, кто не остался в стороне и пожелал задать свои вопросы =) Вопросы оказались очень интересными, и я хотел бы ответить разом на всех из них, но каждый вопрос - это огромная тема для поста.
Поэтому я буду шаг за шагом отвечать на ваши вопросы по мере сложности. Чем проще ответить, тем быстрее получите ответ =)
Начнем с вопроса Марии:
Ответ читаем, как всегда, в телеграфе:
https://telegra.ph/Raspredelyat-dokumentirovat-i-svalit-10-23
Поэтому я буду шаг за шагом отвечать на ваши вопросы по мере сложности. Чем проще ответить, тем быстрее получите ответ =)
Начнем с вопроса Марии:
Грамотное распределение ответственных за части системы. Особенно когда изначальный автор фичи собирается уйти из компании или перевестись в соседний отдел.
Ответ читаем, как всегда, в телеграфе:
https://telegra.ph/Raspredelyat-dokumentirovat-i-svalit-10-23
❤7
И вот я добрался наконец-то до темы, от которой у некоторых бомбит =)
Маргарита задала великолепный, я считаю, вопрос:
После этого поста большинство "сеньоров" и "лидов" меня очень сильно "полюбит" =)
Здесь я расскажу свое видение Д-М-С-Л-тД и немного расскажу о том, как определять, кто есть и на каком уровне.
Пост получится прям супер большой, и среднее время чтения у него около 20-30 минут. Поэтому запасайтесь терпением и временем =)
И снова идем в телеграф читать:
https://telegra.ph/Dzhun-ty-ili-lid-prekrasnyj-10-25
Маргарита задала великолепный, я считаю, вопрос:
Разница между джуном, мидлом и сеньером.
После этого поста большинство "сеньоров" и "лидов" меня очень сильно "полюбит" =)
Здесь я расскажу свое видение Д-М-С-Л-тД и немного расскажу о том, как определять, кто есть и на каком уровне.
Пост получится прям супер большой, и среднее время чтения у него около 20-30 минут. Поэтому запасайтесь терпением и временем =)
И снова идем в телеграф читать:
https://telegra.ph/Dzhun-ty-ili-lid-prekrasnyj-10-25
Telegraph
Джун ты, или лид прекрасный.
Градации в специализациях. Итак. Есть некоторая устоявшаяся классификация уровня программиста: Джун. Мидл. Сеньор. Лид. Технический Директор Проекта. Технический Директор Компании. В целом, эту классификацию можно натянуть на любой другой тип работы - геймдизайнеры…
❤9💯3
Пока сервера Arc Raiders упали, я решил выложить пост об еще одном пункте, который рассказываю всем прибывшим ко мне в команду =)
Читали ли вы книгу "Совершенный Код" Стива Макконнелл? Если да, то сколько раз вы ее уже перечитали? =)
Если нет, то пост о том, чтобы вы срочно бросили всё, разбили свои копилки и побежали покупать эту книгу.
Серьезна. Без шуток.
Эта книга не о том, как работает какая-нибудь библиотека, или что надо писать код только в таком-то подходе. Нет.
Эта книга так же не будет вас учить "быть сеньором и обманывать своих руководителей". Нет.
Эта книга написана программистом со стажем в 20 с большим лет, который собирал лучшие практики и подходы к программированию. Стив не просто выдает их в ней, а приводит статистику, которую собирали различные команды и компании, и показывает, что лучше работает в тех или иных ситуациях, на тех или иных проектах. Например, какие подходы нужно применять при разработке медицинских ПО, космического ПО или игр (а эт наша остановка, на минуточку =) ). Какие лучше использовать практики для оценки объемов работ.
Эта Книга прошла испытание огнем и водой, и на втором издании была очень сильно отредактирована, а потом протестирована временем на прочность и осталась Топ-1 для всех программистов. Особенно, если в вашей команде нет сеньоров.
Книга является лучшей, на мой взгляд, передачей опыта кодинга и управления проектами от сеньоров. Макконнелл собрал самые эффективные практики, описал то, как надо продумывать код, как надо продумывать системы, как надо подходить к решению задач и вообще быть программистом. Именно эта книга для меня стала библией программиста, которую я уже перечитал раза 3 и скоро буду перечитывать 4ый раз (и я не шучу).
Хотите знать как:
- Оценивать риски разработки?
- Подходить к решению задач?
- Делать правильно ревью кода?
- Создавать сложные системы?
- Контролировать разработку огромных приложений и минимизировать риски?
- Объяснять не программисту программистские штуки? (Да, этому посвящен целый раздел)
- Правильно организовать работу программистов?
- Работать в парном программировании?
И еще просто милльён важных тем, которые стоит прочитать всем программистам.
Прочитать книгу - это мое условие для дальнейшего повышения и продвижения программиста в моей команде. Потому что в книге столько знаний и опыта, сколько я никогда не смогу передать никому, поэтому ее читать обязательно.
Стив Макконнелл "Совершенный Код". Читать, если вы хотите быть лучшими.
Читали ли вы книгу "Совершенный Код" Стива Макконнелл? Если да, то сколько раз вы ее уже перечитали? =)
Если нет, то пост о том, чтобы вы срочно бросили всё, разбили свои копилки и побежали покупать эту книгу.
Серьезна. Без шуток.
Эта книга не о том, как работает какая-нибудь библиотека, или что надо писать код только в таком-то подходе. Нет.
Эта книга так же не будет вас учить "быть сеньором и обманывать своих руководителей". Нет.
Эта книга написана программистом со стажем в 20 с большим лет, который собирал лучшие практики и подходы к программированию. Стив не просто выдает их в ней, а приводит статистику, которую собирали различные команды и компании, и показывает, что лучше работает в тех или иных ситуациях, на тех или иных проектах. Например, какие подходы нужно применять при разработке медицинских ПО, космического ПО или игр (а эт наша остановка, на минуточку =) ). Какие лучше использовать практики для оценки объемов работ.
Эта Книга прошла испытание огнем и водой, и на втором издании была очень сильно отредактирована, а потом протестирована временем на прочность и осталась Топ-1 для всех программистов. Особенно, если в вашей команде нет сеньоров.
Книга является лучшей, на мой взгляд, передачей опыта кодинга и управления проектами от сеньоров. Макконнелл собрал самые эффективные практики, описал то, как надо продумывать код, как надо продумывать системы, как надо подходить к решению задач и вообще быть программистом. Именно эта книга для меня стала библией программиста, которую я уже перечитал раза 3 и скоро буду перечитывать 4ый раз (и я не шучу).
Хотите знать как:
- Оценивать риски разработки?
- Подходить к решению задач?
- Делать правильно ревью кода?
- Создавать сложные системы?
- Контролировать разработку огромных приложений и минимизировать риски?
- Объяснять не программисту программистские штуки? (Да, этому посвящен целый раздел)
- Правильно организовать работу программистов?
- Работать в парном программировании?
И еще просто милльён важных тем, которые стоит прочитать всем программистам.
Прочитать книгу - это мое условие для дальнейшего повышения и продвижения программиста в моей команде. Потому что в книге столько знаний и опыта, сколько я никогда не смогу передать никому, поэтому ее читать обязательно.
Стив Макконнелл "Совершенный Код". Читать, если вы хотите быть лучшими.
💯6
Как программист, я очень люблю разбирать чужой код, чтобы иметь представление о том, какие идеи бывают у других людей при создании тех или иных функционалов. Лет 5, наверное, своей карьеры программиста, я пытался разбирать код вот как есть - тыкаешь функцию, читаешь ее, находишь непонятные штуки, разбираешь их, потом идешь дальше.
И все бы ничего. Но. Чем дальше в лес, тем больше нужно памяти в мозгу, чтобы помнить, что за что отвечает и как вызывается. Чем дольше я иду в глубь, тем больше я забываю, зачем вообще я сюда зашел. Что там было в первой функции? А где я сейчас - в 45ой функции?
Если мне надо понять, как что-то работает - мне надо понять каждую строчку кода. Каждую буковку, каждый символ, каждый пробел. Я разбираю от начала и до конца весь функционал. Из-за этого у меня проблемы с разбором кода =)
Я просто не способен унести все знания и понимания, удерживая всё это в голове. Да и, мне кажется, на это не способен никто.
Я очень сильно люблю Miro (все, кто знает, что это, сейчас должны быстро связать 2+2), и я постоянно свои архитектурные решения раскидываю на досках. Логику, классы, структуры, и так далее. Это очень удобно, когда нужно размотать в голове кучу клубочков идей и выложить их в одно место.
В Miro можно видеть все разом и перемещаться между сущностями буквально в 1 клик и пару движений рукой. Даже этот пост написан в Miro.
И однажды, разбирая очередной код, я настолько устал мотать туда-сюда просто исполинскую функцию, что решил ее собрать в Miro в один большой картинку (тут нет опечатки).
И, знаете, это получилось прям супер круто. Я начал подписывать строчки так, как я это видел. Начал вставлять стрелочки от функции к функции. Начал разматывать клубочки логики прямо на доске, и это получилось щикарна. Я перестал удерживать тонну мыслей в своей голове, а стал видеть их прямо на доске и мог вернуться в любой момент в нужную точку, видя при этом всю картину целиком.
Это стало для меня открытием десятилетия =) Я начал разбирать весь код, с которым мне надо работать, таким образом, и вдруг я стал быстрее видеть общую картину того, как и что работает. Я стал лучше понимать архитектуры и идеи программистов без документации, без комментариев и прочего. Это стало моим супер-оружием против супер-героев (да-да, я злодей в этой истории =) ), ведь теперь их крутые фичи, которые ведомы только им, стали для меня легко доступными.
Я не буду пытаться вам расписать сейчас словами, как это я делаю. Я думаю, что увидеть пример вживую лучше всего, поэтому вот вам ссылка на пример (нужна авторизация в Miro):
https://miro.com/welcomeonboard/RGszV2YvTlliWC9aZDdLWXRPMGVRcGdoTnQ1SFFiZ2ZRaWhWS1Btd1RONUlBbklzM1BCQndXY3ZJVUszYlZ0M21idjVqSnhSN1B0akpWOTFYd3BIa1dmVGdBRlk4TUNSUGNDZnNtelhjV2Z1QzgwbmJXOExadVNqTGJ2aWU5RjYhdjE=?share_link_id=650434945321
В этом примере я разбирал когда-то как Enhanced Input работает в Lyra. А для этого мне нужно было понять, как проект вообще запускается и в какой момент втыкает инпуты в подвязку к абилкам.
Вообще, я пользуюсь Miro прям вот для всего. Здесь я пишу посты, здесь я собираю идеи, здесь у меня документация к моим пет-проектам, здесь я планирую планы, расписываю задачи и вообще - это чуть ли не единственный мой сервис для любой работы.
Если мне нужно что-то изучить - я создаю отдельную доску и начинаю в нее накидывать данные, которые я нашел. Таким образом формируется картина изучаемой сущности, и определяется суть идеи этой сущности.
А. Еще есть ClickUp =)
Ну и поделитесь в комментариях, как вы разбираете код, и насколько вам удобно это делать вашим способом =)
И все бы ничего. Но. Чем дальше в лес, тем больше нужно памяти в мозгу, чтобы помнить, что за что отвечает и как вызывается. Чем дольше я иду в глубь, тем больше я забываю, зачем вообще я сюда зашел. Что там было в первой функции? А где я сейчас - в 45ой функции?
Если мне надо понять, как что-то работает - мне надо понять каждую строчку кода. Каждую буковку, каждый символ, каждый пробел. Я разбираю от начала и до конца весь функционал. Из-за этого у меня проблемы с разбором кода =)
Я просто не способен унести все знания и понимания, удерживая всё это в голове. Да и, мне кажется, на это не способен никто.
Я очень сильно люблю Miro (все, кто знает, что это, сейчас должны быстро связать 2+2), и я постоянно свои архитектурные решения раскидываю на досках. Логику, классы, структуры, и так далее. Это очень удобно, когда нужно размотать в голове кучу клубочков идей и выложить их в одно место.
В Miro можно видеть все разом и перемещаться между сущностями буквально в 1 клик и пару движений рукой. Даже этот пост написан в Miro.
И однажды, разбирая очередной код, я настолько устал мотать туда-сюда просто исполинскую функцию, что решил ее собрать в Miro в один большой картинку (тут нет опечатки).
И, знаете, это получилось прям супер круто. Я начал подписывать строчки так, как я это видел. Начал вставлять стрелочки от функции к функции. Начал разматывать клубочки логики прямо на доске, и это получилось щикарна. Я перестал удерживать тонну мыслей в своей голове, а стал видеть их прямо на доске и мог вернуться в любой момент в нужную точку, видя при этом всю картину целиком.
Это стало для меня открытием десятилетия =) Я начал разбирать весь код, с которым мне надо работать, таким образом, и вдруг я стал быстрее видеть общую картину того, как и что работает. Я стал лучше понимать архитектуры и идеи программистов без документации, без комментариев и прочего. Это стало моим супер-оружием против супер-героев (да-да, я злодей в этой истории =) ), ведь теперь их крутые фичи, которые ведомы только им, стали для меня легко доступными.
Я не буду пытаться вам расписать сейчас словами, как это я делаю. Я думаю, что увидеть пример вживую лучше всего, поэтому вот вам ссылка на пример (нужна авторизация в Miro):
https://miro.com/welcomeonboard/RGszV2YvTlliWC9aZDdLWXRPMGVRcGdoTnQ1SFFiZ2ZRaWhWS1Btd1RONUlBbklzM1BCQndXY3ZJVUszYlZ0M21idjVqSnhSN1B0akpWOTFYd3BIa1dmVGdBRlk4TUNSUGNDZnNtelhjV2Z1QzgwbmJXOExadVNqTGJ2aWU5RjYhdjE=?share_link_id=650434945321
В этом примере я разбирал когда-то как Enhanced Input работает в Lyra. А для этого мне нужно было понять, как проект вообще запускается и в какой момент втыкает инпуты в подвязку к абилкам.
Вообще, я пользуюсь Miro прям вот для всего. Здесь я пишу посты, здесь я собираю идеи, здесь у меня документация к моим пет-проектам, здесь я планирую планы, расписываю задачи и вообще - это чуть ли не единственный мой сервис для любой работы.
Если мне нужно что-то изучить - я создаю отдельную доску и начинаю в нее накидывать данные, которые я нашел. Таким образом формируется картина изучаемой сущности, и определяется суть идеи этой сущности.
А. Еще есть ClickUp =)
Ну и поделитесь в комментариях, как вы разбираете код, и насколько вам удобно это делать вашим способом =)
❤11
Сегодня я хотел бы поговорить об эффектах =) Не визуальных и красивых, не о цветовой гамме IDE (хотя к ней тоже однажды придем) или эффектах восприятия.
Нет. Я хотел бы рассказать вам об эффектах в коде, которые никто не ждал =)
Го в телеграф, там много текста =)
https://telegra.ph/EHffekty-kotoryh-my-ne-ozhidali-12-07
Нет. Я хотел бы рассказать вам об эффектах в коде, которые никто не ждал =)
Го в телеграф, там много текста =)
https://telegra.ph/EHffekty-kotoryh-my-ne-ozhidali-12-07
❤7💯2
Новые посты начну писать скорей всего уже после НГ, так что пока скину сюда свои старые работы =)
Я когда-то не так давно написал большой пак статей о том, как работает текстурирование в играх от пикселя на экране до результата в игре.
Писал специально для тех, кто вообще никак не сталкивался с текстурированием, чтобы можно было им скинуть ссылку и сказать: "иди изучай", а завтра уже ждать первых результатов =)
Часть 1. Пиксель. https://dtf.ru/id3872/209535
Часть 2. Маски и текстуры. https://dtf.ru/gamedev/210209
Часть 3. PBR и материалы. https://dtf.ru/gamedev/210838
Часть 4. Модели, нормали и развертка. https://dtf.ru/gamedev/211976
Часть 5. Система материалов. https://dtf.ru/u/3872-denis-kuznecov/213001
Часть 6. Погружение в систему материалов. https://dtf.ru/u/3872-denis-kuznecov/225245
Там же на DTF есть пост и о том, как работает система локализации в анриле. Правда, на 4ку, но принцип сохранился и в 5ке. Здесь читать: https://dtf.ru/id3872/209371
Я когда-то не так давно написал большой пак статей о том, как работает текстурирование в играх от пикселя на экране до результата в игре.
Писал специально для тех, кто вообще никак не сталкивался с текстурированием, чтобы можно было им скинуть ссылку и сказать: "иди изучай", а завтра уже ждать первых результатов =)
Часть 1. Пиксель. https://dtf.ru/id3872/209535
Часть 2. Маски и текстуры. https://dtf.ru/gamedev/210209
Часть 3. PBR и материалы. https://dtf.ru/gamedev/210838
Часть 4. Модели, нормали и развертка. https://dtf.ru/gamedev/211976
Часть 5. Система материалов. https://dtf.ru/u/3872-denis-kuznecov/213001
Часть 6. Погружение в систему материалов. https://dtf.ru/u/3872-denis-kuznecov/225245
Там же на DTF есть пост и о том, как работает система локализации в анриле. Правда, на 4ку, но принцип сохранился и в 5ке. Здесь читать: https://dtf.ru/id3872/209371
❤8