Визитная карточка канала.
Или пост о том, что тут можно найти.
Кто ведет этот канал?
Мое имя Денис Кузнецов, и я делаю игры на Unreal Engine порядка 10 лет. Я работал как в ААА студиях (Sony PlayStation), так и в небольших инди над различными проектами, большая часть из которых так и не увидела свет. Сейчас я работаю в одной из крупных компаний в РФ и Европе лидом команды очень крутых программистов.
До создания игр я работал в одном из интернет-провайдеров Руководителем Направления Обслуживания, отвечая за то, как компания взаимодействует с клиентами, начиная от отдела продаж, заканчивая технической поддержкой и офисами. В подчинении было несколько отделов с около сотней людей в общей сложности.
О чем будет этот канал?
У меня достаточно большой опыт как управления, так и программирования, и я считаю ,что мне есть что вам рассказать и каким опытом с вами поделиться =)
Здесь я буду рассказывать о проблемах программистов, о том, что многие не любят озвучивать и о том, что многим не нравится.
Буду рассуждать о том:
- Как лучше выстраивать свою работу.
- Как строить диалог между ПМ и программистами.
- Кто должен выставлять сроки на выполнение задач.
- Что лучше - кодить или лидить?
- Какие подводные камни ждут лидов.
- Как лучше оценивать грейд программистов.
- Как разделять ответственность.
- Сколько строк кода должен выкатывать программист в день.
- Насколько важна фантазия программисту.
- И так далее.
Тем будет очень много, и все они направлены не только на программирование, но и на то, как нужно работать и, самое главное, мыслить программисту. Но посты буду выкладывать 1-2 раза в месяц, так что не ждите наплыва уведомлений.
Чего вы здесь точно не увидите - это рекламные посты. Данный канал я создал не для заработка, а для того, чтобы делиться опытом.
С моими тезисами будет несогласно очень большое количество людей, и, в целом-то, мне плевать =)
Или пост о том, что тут можно найти.
Кто ведет этот канал?
Мое имя Денис Кузнецов, и я делаю игры на Unreal Engine порядка 10 лет. Я работал как в ААА студиях (Sony PlayStation), так и в небольших инди над различными проектами, большая часть из которых так и не увидела свет. Сейчас я работаю в одной из крупных компаний в РФ и Европе лидом команды очень крутых программистов.
До создания игр я работал в одном из интернет-провайдеров Руководителем Направления Обслуживания, отвечая за то, как компания взаимодействует с клиентами, начиная от отдела продаж, заканчивая технической поддержкой и офисами. В подчинении было несколько отделов с около сотней людей в общей сложности.
О чем будет этот канал?
У меня достаточно большой опыт как управления, так и программирования, и я считаю ,что мне есть что вам рассказать и каким опытом с вами поделиться =)
Здесь я буду рассказывать о проблемах программистов, о том, что многие не любят озвучивать и о том, что многим не нравится.
Буду рассуждать о том:
- Как лучше выстраивать свою работу.
- Как строить диалог между ПМ и программистами.
- Кто должен выставлять сроки на выполнение задач.
- Что лучше - кодить или лидить?
- Какие подводные камни ждут лидов.
- Как лучше оценивать грейд программистов.
- Как разделять ответственность.
- Сколько строк кода должен выкатывать программист в день.
- Насколько важна фантазия программисту.
- И так далее.
Тем будет очень много, и все они направлены не только на программирование, но и на то, как нужно работать и, самое главное, мыслить программисту. Но посты буду выкладывать 1-2 раза в месяц, так что не ждите наплыва уведомлений.
Чего вы здесь точно не увидите - это рекламные посты. Данный канал я создал не для заработка, а для того, чтобы делиться опытом.
С моими тезисами будет несогласно очень большое количество людей, и, в целом-то, мне плевать =)
Когда я был маленьким, в классе 6-7, у меня были самые крутые оценки - двойки и тройки. Я не любил учиться, и не понимал, что говорят эти дяди и тёти за столом на другом конце класса. Мне больше нравилось рисовать, играть на Денди (Сеге), прогуливать школу, чем их слушать. Но тогда я не понимал почему.
Примерно тогда мама отдала меня учиться в частную школу Рона Хаббарда* (дада, того самого, что с динозаврами и инопланетянами дружит, а его лично и его саентология признана нежелательной в РФ, и книги признаны экстремистскими).
Я проучился там примерно 1-2 месяца, но потом вернулся назад, так как мы не были даже уровня среднего достатка, и денег у нас не хватило на оплату дальнейшего обучения. Не спрашивайте меня "Как так получилось, и что разве это не было понятно сразу?". Я был слишком мал, чтобы оценивать риски.
За этот короткий промежуток времени, пока я учился в этой школе, я прошел почти весь учебник своего класса по математике, а так же по русскому языку и другим предметам. То есть, я за 1-2 месяца прошел почти весь курс своего класса вместо 9 положенных.
При этом учителя в этой школе мне вообще не помогали. Они только контролировали то, что я изучил и что запомнил, но ни разу не объясняли мне суть предметной области.
Вы спросите:
А учили они учиться.
Учителя сидели со мной от начала и до конца только когда я читал книгу "Учись Учиться" Рона Хаббарда*. Они убедились, что я понял эту книгу от самого начала до самого конца, и только потом допустили меня к школьным предметам.
Дальше я полностью самостоятельно изучал учебники, решал задачи и ни разу не звал ни одного учителя, чтобы они мне объяснили тему предмета. Я проходил все тесты, которые они проводили каждые две недели, отвечал на все вопросы без каких-либо сложностей и имел одни пятерки.
Что же такого было в этой книге?
На самом деле абсолютно ничего сверхъестественного. Там всего 3 правила, которых нужно придерживаться, и тогда любая тема, любая технология, абсолютно любое направление станет легким для понимания.
Текст получился очень большой, и Telegram не дал мне опубликовать его в одном посте, поэтому пришлось переместить его в телеграф =)
Ссылка на продолжение:
https://telegra.ph/Post-o-tom-kak-nado-uchitsya-Och-bolshoj-post-08-17
*Рон Хаббард признан нежелательным в РФ, а его книги - экстремистскими.
Примерно тогда мама отдала меня учиться в частную школу Рона Хаббарда* (дада, того самого, что с динозаврами и инопланетянами дружит, а его лично и его саентология признана нежелательной в РФ, и книги признаны экстремистскими).
Я проучился там примерно 1-2 месяца, но потом вернулся назад, так как мы не были даже уровня среднего достатка, и денег у нас не хватило на оплату дальнейшего обучения. Не спрашивайте меня "Как так получилось, и что разве это не было понятно сразу?". Я был слишком мал, чтобы оценивать риски.
За этот короткий промежуток времени, пока я учился в этой школе, я прошел почти весь учебник своего класса по математике, а так же по русскому языку и другим предметам. То есть, я за 1-2 месяца прошел почти весь курс своего класса вместо 9 положенных.
При этом учителя в этой школе мне вообще не помогали. Они только контролировали то, что я изучил и что запомнил, но ни разу не объясняли мне суть предметной области.
Вы спросите:
А чему же тогда они учили?
А учили они учиться.
Учителя сидели со мной от начала и до конца только когда я читал книгу "Учись Учиться" Рона Хаббарда*. Они убедились, что я понял эту книгу от самого начала до самого конца, и только потом допустили меня к школьным предметам.
Дальше я полностью самостоятельно изучал учебники, решал задачи и ни разу не звал ни одного учителя, чтобы они мне объяснили тему предмета. Я проходил все тесты, которые они проводили каждые две недели, отвечал на все вопросы без каких-либо сложностей и имел одни пятерки.
Что же такого было в этой книге?
На самом деле абсолютно ничего сверхъестественного. Там всего 3 правила, которых нужно придерживаться, и тогда любая тема, любая технология, абсолютно любое направление станет легким для понимания.
Текст получился очень большой, и Telegram не дал мне опубликовать его в одном посте, поэтому пришлось переместить его в телеграф =)
Ссылка на продолжение:
https://telegra.ph/Post-o-tom-kak-nado-uchitsya-Och-bolshoj-post-08-17
*Рон Хаббард признан нежелательным в РФ, а его книги - экстремистскими.
1
Программистам (не знаю, как другим) очень хочется продумать архитектуру системы таким образом, чтобы она охватывала все возможные кейсы. Например, чтобы управление в RTS могло переключаться в FPS или TPS. Чтобы можно было написать систему, которая легко заменяется на другую.
Молодые программисты (я сейчас о возрасте их программистского духа, а не физическом возрасте) особенно сильно стремятся к тому, чтобы написать код "максимально гибким и масштабируемым". Прибегают к различным ухищрениям, продумывают огромные сложные заковыристые связи, которые можно подменять чуть ли не на каждой строчке кода, и это выглядит масштабно, это выглядит действительно круто. Но только в их глазах.
Приходят серьезные дядьки и ничего не понимают. Спрашивают "Что это?" А в ответ:
И дальше идет закономерный вопрос, который почему-то все это время игнорировался полностью: "А заказчик это просил?".
Была ли идея геймдизайнера запускать игру на космическом аппарате? Нужно ли оптимизировать проект? В интерфейсе класса вот эти 2 функции, написанные впрок, кто-то использует уже? Погодите, а ПМ разве выставил задачу написать целую систему настройки персонажа, его лица, тела, рук, когда он просил добавить возможность менять шляпки?
Я думаю, почти всегда будет один и тот же ответ "Нет". Продумывать системы наперед - это тратить свое время, время команды, компании впустую.
А вы не согласитесь, ведь:
А что если я вам скажу, что заказчик не придет к вам за этой фичей? Что, если я вам скажу, что вы потратите на несколько часов работы больше сейчас, продумывая систему так, чтобы она могла еще и "Х делать", но этот Х никто никогда не будет использовать? Более того, программисты будут приходить и смотреть на этот Х и думать, что он работает, и даже будут обращаться к нему. Но вы подумали о будущем, и всё же не до конца, и великий баг ждет своего часа.
А время, которое вы потратили уже не вернуть.
Более того, когда придет время использовать наконец-то вашу штуку Х, то ее все равно перепишут и почти всегда с нуля.
И не потому, что ваш код плохой. Просто когда приходит время реально делать то, что требует заказчик, всегда приходит и совершенно другой подход к реализации, чем тот, что был "на всякий случай".
Мы с ребятами в команде недавно прикинули, что было бы, если бы мы сделали работу впрок?
В итоге, получилось, что сейчас, не продумывая заранее, мы написали бы код за 1 час. А потом, когда к нам пришли бы и попросили добавить новую фичу - мы бы потратили еще 4 часа.
Но если бы мы заранее начали думать о том, как эта фича должна быть в коде - мы бы потратили 5 часов.
И вы сейчас скажите:
Только к нам никто не пришел. Нас никто так и не попросил добавить эту фичу. В итоге код ушел бы в прод. А время нам никто не вернул бы. Оно бы сгорело безвозвратно.
А та самая милая фича, которая была не в приоритете, оказалась не реализована потому, что нам не хватило на нее 4х часов. И проект провалился, просто потому, что котиков нельзя гладить в игре.
Хорошо, что в команде есть понимание, что "впрок" - это время в мусорку =)
Другой вопрос, когда вам заняться нечем, и вы экспериментируете. Там вы можете продумывать системы хоть на 100 фич вперед и 100 лет поддержки. Вдруг, вы сможете создать такой фреймворк, который будет и для FPS, и для TPS, и для RTS, и вообще тык-пык, и GTA 10 готова?
Я как-то от скуки, например, решил посмотреть, что получится, если геймплейный фреймворк для TPS разделить на десятки плагинов и подключать их в зависимости от необходимости. Получилось гавно, конечно, но я люблю эксперименты =)
Молодые программисты (я сейчас о возрасте их программистского духа, а не физическом возрасте) особенно сильно стремятся к тому, чтобы написать код "максимально гибким и масштабируемым". Прибегают к различным ухищрениям, продумывают огромные сложные заковыристые связи, которые можно подменять чуть ли не на каждой строчке кода, и это выглядит масштабно, это выглядит действительно круто. Но только в их глазах.
Приходят серьезные дядьки и ничего не понимают. Спрашивают "Что это?" А в ответ:
Теперь можно наш проект на космическом корабле запускать на фазе запуска.
И дальше идет закономерный вопрос, который почему-то все это время игнорировался полностью: "А заказчик это просил?".
Нет…
Была ли идея геймдизайнера запускать игру на космическом аппарате? Нужно ли оптимизировать проект? В интерфейсе класса вот эти 2 функции, написанные впрок, кто-то использует уже? Погодите, а ПМ разве выставил задачу написать целую систему настройки персонажа, его лица, тела, рук, когда он просил добавить возможность менять шляпки?
Я думаю, почти всегда будет один и тот же ответ "Нет". Продумывать системы наперед - это тратить свое время, время команды, компании впустую.
А вы не согласитесь, ведь:
Никто не может сказать, что в будущем потребуется! Продумав код заранее, мы готовимся к будущему!
А что если я вам скажу, что заказчик не придет к вам за этой фичей? Что, если я вам скажу, что вы потратите на несколько часов работы больше сейчас, продумывая систему так, чтобы она могла еще и "Х делать", но этот Х никто никогда не будет использовать? Более того, программисты будут приходить и смотреть на этот Х и думать, что он работает, и даже будут обращаться к нему. Но вы подумали о будущем, и всё же не до конца, и великий баг ждет своего часа.
А время, которое вы потратили уже не вернуть.
Более того, когда придет время использовать наконец-то вашу штуку Х, то ее все равно перепишут и почти всегда с нуля.
И не потому, что ваш код плохой. Просто когда приходит время реально делать то, что требует заказчик, всегда приходит и совершенно другой подход к реализации, чем тот, что был "на всякий случай".
Мы с ребятами в команде недавно прикинули, что было бы, если бы мы сделали работу впрок?
В итоге, получилось, что сейчас, не продумывая заранее, мы написали бы код за 1 час. А потом, когда к нам пришли бы и попросили добавить новую фичу - мы бы потратили еще 4 часа.
Но если бы мы заранее начали думать о том, как эта фича должна быть в коде - мы бы потратили 5 часов.
И вы сейчас скажите:
Никакой разницы! А код был бы готов! Я был прав!
Только к нам никто не пришел. Нас никто так и не попросил добавить эту фичу. В итоге код ушел бы в прод. А время нам никто не вернул бы. Оно бы сгорело безвозвратно.
А та самая милая фича, которая была не в приоритете, оказалась не реализована потому, что нам не хватило на нее 4х часов. И проект провалился, просто потому, что котиков нельзя гладить в игре.
Хорошо, что в команде есть понимание, что "впрок" - это время в мусорку =)
Другой вопрос, когда вам заняться нечем, и вы экспериментируете. Там вы можете продумывать системы хоть на 100 фич вперед и 100 лет поддержки. Вдруг, вы сможете создать такой фреймворк, который будет и для FPS, и для TPS, и для RTS, и вообще тык-пык, и GTA 10 готова?
Я как-то от скуки, например, решил посмотреть, что получится, если геймплейный фреймворк для TPS разделить на десятки плагинов и подключать их в зависимости от необходимости. Получилось гавно, конечно, но я люблю эксперименты =)
❤6
Приветственный пост о том, как я открываю комменты для последующих постов (за одно тестирую, все ли верно настроил) =)
Во-первых, в канал пришло 153 человека, чего я не рассчитывал, если честно. Был уверен, что соберется человек 50, и то уже неплохо. Всех рад видеть, всех буду рад читать в комментах, велкоме =)
Во-вторых, открывая комменты, я бы хотел обозначить несколько правил общения:
- Можно поливать грязью мои посты путем проставления смайликов ( 💩 и/или🖕). Никто не узнает, что это вы. Радуйтесь =)
- Я люблю критику, но здоровую, логическую, без эмоций, сарказма и эго. С удовольствием обсужу ваши точки зрения, если в них не будет предвзятости =)
- Старайтесь все-таки оценивать себя и свое восприятие. Может быть, вы не правы? Может быть, вы что-то упустили или забыли? (Я стараюсь эти вопросы задавать постоянно себе).
- Банить буду за любые переходы на личности.
А эт мой кот =) Он будет здесь часто мелькать =)
Во-первых, в канал пришло 153 человека, чего я не рассчитывал, если честно. Был уверен, что соберется человек 50, и то уже неплохо. Всех рад видеть, всех буду рад читать в комментах, велкоме =)
Во-вторых, открывая комменты, я бы хотел обозначить несколько правил общения:
- Можно поливать грязью мои посты путем проставления смайликов ( 💩 и/или🖕). Никто не узнает, что это вы. Радуйтесь =)
- Я люблю критику, но здоровую, логическую, без эмоций, сарказма и эго. С удовольствием обсужу ваши точки зрения, если в них не будет предвзятости =)
- Старайтесь все-таки оценивать себя и свое восприятие. Может быть, вы не правы? Может быть, вы что-то упустили или забыли? (Я стараюсь эти вопросы задавать постоянно себе).
- Банить буду за любые переходы на личности.
А эт мой кот =) Он будет здесь часто мелькать =)
3❤14💩7
Когда ко мне приходит новый сотрудник, я рассказываю ему обязательные требования к работе в команде.
Эти требования сформированы из нескольких тем, направленных на то, как мы общаемся. И одну из них я сегодня хотел бы осветить.
Вопросы.
Вопросы не бывают глупыми. Вопросы не бывают плохими или несерьезными. Вопросы, которые вам хочется задать, не отражают заниженный уровень знаний. Наоборот, когда у вас появляются вопросы - это повод для радости. Ведь вы размышляете, вы пытаетесь выровнять в голове картину какой-то сущности, вам интересно, вы хотите понять.
Я вроде успел пообщаться с огромным количеством людей за свою жизнь и видел множество различных реакций на вопросы.
Например:
Я лежал на кресле у хирурга-стоматолога. Он должен был мне удалить зуб, вокруг которого образовалось очень сильное воспаление. Я переживал и хотел понять - последняя ли это процедура, или придется потом долго и упорно удалять всё вокруг. Я спросил его:
И он взорвался! Он начал на повышенных тонах объяснять мне, какой он специалист, как много лет он трудился и изучал всё. Как он жил в Индонезии, как он жил в каких-то еще странах, где проходил обучение, сколько он операций сделал. Да как я вообще посмел сомневаться в его навыках!
И всё это на ломаном английском (было оч смешно). В итоге, вместо того, чтобы он меня успокаивал, успокаивал я его и объяснял ему, что вопросы важны для моего внутреннего понимания происходящего и планирования будущего =)
Проблема в теме вопросов вот в чем:
Есть люди, которые не могут нормально воспринимать вопросы. Для них это повод вас унизить, вас уволить, ткнуть вас носом в это, воспользоваться вашими незнаниями, и так далее.
Мы растем не в вакууме и так или иначе постоянно взаимодействуем с людьми разного сорта. Когда мы задаем вопросы - мы видим определенные реакции, и те реакции, которые приводят к нежелательным последствиям, оказывают на нас значительное влияние.
Чем больше таких реакций мы видим, тем больше мы перестаем задавать вопросы, чтобы их не видеть. Но в этом случае мы остаемся в пузыре незнания того, что же в итоге должны мы сделать.
Или другой пример. Как программист игровой логики, я сталкивался с большим количеством геймдизайнеров и "геймдизайнеров". И вторые бесились от того, что я приходил к ним и задавал им вопросы, чтобы понять, что они хотят. Я отвлекал их своими вопросами от "работы над проектом" (вместо того, чтобы продумывать игру, они делали ролики), и за спиной они даже начали называть меня канарейкой.
И когда я не выдержал и психанул, то выяснилось, что:
Здесь стоит добавить, что есть такое понятие, как "Разделение Ответственности", и я обязательно разберу его до основания.
Есть и те "геймдизайнеры", которые не умеют описывать словом то, что в их представлении, и тогда они требуют искать программистов "с нужным опытом в жанре". Ну, представьте, как это удобно, когда вы просто говорите "хочу, как в диабло", и программист создает свою игру, а вы говорите, что это ваша идея, получаете повышение, и тд.
А если начать засыпать их вопросами... Ну что ж, ищите новую работу. И такое было =)
Примечание: Я сейчас не отменяю то, что есть те люди, которые спрашивают, чтобы потом насрать. Мерзкие люди существуют среди нас - это факт.
Но если вам задают вопросы - не уходите в защиту. Защита - это частая причина старта конфликтов в общении в команде.
Никто на вас не нападет. Никто не собирает информацию, чтобы разбить ваше эго. Люди хотят получать информацию, чтобы выстроить свои планы, работы, картинки в голове или просто утолить свое любопытство без какого-либо злого умысла. Отвечайте на вопросы максимально открыто и честно. Не создавайте еще одну негативную реакцию в копилку у спросившего. Нам эти травмы ни к чему.
Помните, вопросы важны.
Вы задаете их, чтобы закрыть пробелы, поэтому если кто-то считает вас тупым за ваши вопросы -бейте по это не ваша команда. Вы обязательно найдете ту команду, в которой вопросы имеют значение.
Эти требования сформированы из нескольких тем, направленных на то, как мы общаемся. И одну из них я сегодня хотел бы осветить.
Вопросы.
Вопросы не бывают глупыми. Вопросы не бывают плохими или несерьезными. Вопросы, которые вам хочется задать, не отражают заниженный уровень знаний. Наоборот, когда у вас появляются вопросы - это повод для радости. Ведь вы размышляете, вы пытаетесь выровнять в голове картину какой-то сущности, вам интересно, вы хотите понять.
Я вроде успел пообщаться с огромным количеством людей за свою жизнь и видел множество различных реакций на вопросы.
Например:
Я лежал на кресле у хирурга-стоматолога. Он должен был мне удалить зуб, вокруг которого образовалось очень сильное воспаление. Я переживал и хотел понять - последняя ли это процедура, или придется потом долго и упорно удалять всё вокруг. Я спросил его:
То есть, после удаления зуба воспаление уйдет, так?
И он взорвался! Он начал на повышенных тонах объяснять мне, какой он специалист, как много лет он трудился и изучал всё. Как он жил в Индонезии, как он жил в каких-то еще странах, где проходил обучение, сколько он операций сделал. Да как я вообще посмел сомневаться в его навыках!
И всё это на ломаном английском (было оч смешно). В итоге, вместо того, чтобы он меня успокаивал, успокаивал я его и объяснял ему, что вопросы важны для моего внутреннего понимания происходящего и планирования будущего =)
Проблема в теме вопросов вот в чем:
Есть люди, которые не могут нормально воспринимать вопросы. Для них это повод вас унизить, вас уволить, ткнуть вас носом в это, воспользоваться вашими незнаниями, и так далее.
Мы растем не в вакууме и так или иначе постоянно взаимодействуем с людьми разного сорта. Когда мы задаем вопросы - мы видим определенные реакции, и те реакции, которые приводят к нежелательным последствиям, оказывают на нас значительное влияние.
Чем больше таких реакций мы видим, тем больше мы перестаем задавать вопросы, чтобы их не видеть. Но в этом случае мы остаемся в пузыре незнания того, что же в итоге должны мы сделать.
Или другой пример. Как программист игровой логики, я сталкивался с большим количеством геймдизайнеров и "геймдизайнеров". И вторые бесились от того, что я приходил к ним и задавал им вопросы, чтобы понять, что они хотят. Я отвлекал их своими вопросами от "работы над проектом" (вместо того, чтобы продумывать игру, они делали ролики), и за спиной они даже начали называть меня канарейкой.
И когда я не выдержал и психанул, то выяснилось, что:
Ты ж лид (программистов)! Ты должен сам всё придумывать и делать (за них игру)!
Есть и те "геймдизайнеры", которые не умеют описывать словом то, что в их представлении, и тогда они требуют искать программистов "с нужным опытом в жанре". Ну, представьте, как это удобно, когда вы просто говорите "хочу, как в диабло", и программист создает свою игру, а вы говорите, что это ваша идея, получаете повышение, и тд.
А если начать засыпать их вопросами... Ну что ж, ищите новую работу. И такое было =)
Примечание: Я сейчас не отменяю то, что есть те люди, которые спрашивают, чтобы потом насрать. Мерзкие люди существуют среди нас - это факт.
Но если вам задают вопросы - не уходите в защиту. Защита - это частая причина старта конфликтов в общении в команде.
Никто на вас не нападет. Никто не собирает информацию, чтобы разбить ваше эго. Люди хотят получать информацию, чтобы выстроить свои планы, работы, картинки в голове или просто утолить свое любопытство без какого-либо злого умысла. Отвечайте на вопросы максимально открыто и честно. Не создавайте еще одну негативную реакцию в копилку у спросившего. Нам эти травмы ни к чему.
Помните, вопросы важны.
Вы задаете их, чтобы закрыть пробелы, поэтому если кто-то считает вас тупым за ваши вопросы -
1❤24
Мне интересно, что вы думаете по поводу частоты постов. Я заметил, что некоторые подписчики отключаются, если долго не выкладывать посты (иногда работы бывает очень много ❤️ ).
Как часто вы бы хотели видеть здесь посты?😛
Как часто вы бы хотели видеть здесь посты?
Anonymous Poll
34%
1 раз в неделю🥳
29%
2-3 раза в неделю⛏
13%
2-3 раза в месяц 🤩
22%
Чем чаще, тем лучше 🔨
28%
Мне без разницы 🤪
7%
Мне есть разница. ☹️
Сегодня я продолжу тему разговоров, так как считаю, что коммуникация между людьми - это основная точка опоры проектов. Нет коммуникации - нет проекта. Если только вы не разрабатываете в соло.
Следующая тема называется "Как правильно рассказать".
Пост получился очень большим, поэтому я оформил его в телеграфе =)
Предлагаю продолжить там:
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
❤4