Мы уже рассказывали, как нанимать и мотивировать людей. Теперь расскажем, как их правильно увольнять — не нарушая прав, не превышая полномочий, без людоедства и произвола
⚠️ Описанное ниже применимо, если вы работаете по ТК в окружении адекватных менеджеров.
Представим, что у нас есть разраб и он косячит так, что за ним потом прибирают все. Допустим также, что мы уже испробовали все мирные способы: поговорили по душам, отправляли в отпуск, приглашали в офис массажиста. Разработчик раскаялся, распрямился и порозовел, но творить дичь не перестал. Остаётся только уволить.
1️⃣ Соберите числовые показатели, которым сотрудник должен соответствовать. Показатели нужны понятные, отслеживаемые и общедоступные — по SMART.
2️⃣ Поговорите с сотрудником ещё раз. Постарайтесь выяснить, какие у него проблемы и почему он так хуёво работает.
Если сотрудник внятно не отвечает, покажите список показателей. Объясните, о чем и для чего каждый, как это влияет на работу команды. Попросите подтвердить согласие со списком в письме.
Если у сотрудника проблемы, на этом этапе он перестанет отмалчиваться и всё можно будет обсудить и попробовать исправить. Иначе идём далее.
3️⃣ Назначьте условный испытательный срок внутри команды, около месяца. Если сотрудник справился — проблема вроде как решена. Если не справился — у вас появляется аргумент для кадровиков.
4️⃣ Кадровики назначат сотруднику сокращенный испытательный срок, по результатам которого рассмотрят увольнение по ТК.
Процесс занимает до трёх месяцев. Разумеется, сотрудник будет в курсе происходящего и вам придётся с ним сосуществовать и работать. Поэтому проще наладить отбор и прохождение испытательного срока. Ну или работать там, где могут уволить одним днем, в том числе и вас ✨
⚠️ Описанное ниже применимо, если вы работаете по ТК в окружении адекватных менеджеров.
Представим, что у нас есть разраб и он косячит так, что за ним потом прибирают все. Допустим также, что мы уже испробовали все мирные способы: поговорили по душам, отправляли в отпуск, приглашали в офис массажиста. Разработчик раскаялся, распрямился и порозовел, но творить дичь не перестал. Остаётся только уволить.
Если сотрудник внятно не отвечает, покажите список показателей. Объясните, о чем и для чего каждый, как это влияет на работу команды. Попросите подтвердить согласие со списком в письме.
Если у сотрудника проблемы, на этом этапе он перестанет отмалчиваться и всё можно будет обсудить и попробовать исправить. Иначе идём далее.
Процесс занимает до трёх месяцев. Разумеется, сотрудник будет в курсе происходящего и вам придётся с ним сосуществовать и работать. Поэтому проще наладить отбор и прохождение испытательного срока. Ну или работать там, где могут уволить одним днем, в том числе и вас ✨
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2
StringConcat - разработка без боли и сожалений pinned «Практический курс Разработка Enterprise-приложений без боли и сожалений На конференциях все рассказывают об успехах и высоких нагрузках. Но в реальности архитектура не предусматривает изменений, требования меняются каждый спринт, а разработчики тушат пожары…»
Жопа босса знает лучше — важная особенность китайской культуры
В Thoughtworks мне предложили поработать на нового клиента, но предупредили, что это очень традиционная китайская организация. Оказалось, это важно знать заранее. И вот почему.
Пришёл к клиенту в офис, ищу стул. Пробую один, другой, регулирую — все не очень. Говорю разработчику Чену:
— Стулья неудобные какие-то.
— А я их сам выбирал.
— Так у тебя жопа как у меня, тебе удобно, что ли?
— Неудобно, но другие нельзя было выбрать.
И рассказывает историю. Привезли в офис разных стульев на пробу, позвали Чена выбирать ягодицами. Он приходит, а там уже начальство всё попробовало, выбрало и расхваливает. Чен садится, ему неудобно, но возразить начальству он не может, в Китае не принято перечить старшим. Причём и по возрасту, и по положению. Поэтому слово начальника — закон, даже если он решил фронт на PHP писать. И уже не важно, что нужно бизнесу, что пользователю, — начальник выбрал, ты кивнул.
Для сравнения в Скандинавии царит дух равенства и даже тимлид не может решать за всю команду. Любое решение придётся продавать, а команда может его не принять. И я такое встречал даже в банке.
По моим наблюдениям в атмосфере равенства получаются более качественные продукты: каждый в команде чувствует причастность и ответственность за результат. При подходе «спустили сверху» причастности не ощущается. С другой стороны, скандинавы некоторые проблемы решают месяцами, утопая в бесконечных обсуждениях. Китайцам же консенсус искать не нужно, за них всё Конфуций решил.
В Thoughtworks мне предложили поработать на нового клиента, но предупредили, что это очень традиционная китайская организация. Оказалось, это важно знать заранее. И вот почему.
Пришёл к клиенту в офис, ищу стул. Пробую один, другой, регулирую — все не очень. Говорю разработчику Чену:
— Стулья неудобные какие-то.
— А я их сам выбирал.
— Так у тебя жопа как у меня, тебе удобно, что ли?
— Неудобно, но другие нельзя было выбрать.
И рассказывает историю. Привезли в офис разных стульев на пробу, позвали Чена выбирать ягодицами. Он приходит, а там уже начальство всё попробовало, выбрало и расхваливает. Чен садится, ему неудобно, но возразить начальству он не может, в Китае не принято перечить старшим. Причём и по возрасту, и по положению. Поэтому слово начальника — закон, даже если он решил фронт на PHP писать. И уже не важно, что нужно бизнесу, что пользователю, — начальник выбрал, ты кивнул.
Для сравнения в Скандинавии царит дух равенства и даже тимлид не может решать за всю команду. Любое решение придётся продавать, а команда может его не принять. И я такое встречал даже в банке.
По моим наблюдениям в атмосфере равенства получаются более качественные продукты: каждый в команде чувствует причастность и ответственность за результат. При подходе «спустили сверху» причастности не ощущается. С другой стороны, скандинавы некоторые проблемы решают месяцами, утопая в бесконечных обсуждениях. Китайцам же консенсус искать не нужно, за них всё Конфуций решил.
🔥15😁8🤯7
Полезное для линуксоидов и маководов
SDKMAN — пакетный менеджер для JVM-мира. Позволяет устанавливать и жонглировать SDKашками и инструментами без геморроя и ручных манипуляций с переменными окружения, как, например, в brew.
Может держать, к примеру, несколько версий и разновидностей JDK и переключаться между ними по необходимости. Ну и разновидностей JDK целый вагон.
Работает на большинстве Unix-образных систем и вроде как даже на винде через Cygwin, но я не пробовал. Не заменит
SDKMAN — пакетный менеджер для JVM-мира. Позволяет устанавливать и жонглировать SDKашками и инструментами без геморроя и ручных манипуляций с переменными окружения, как, например, в brew.
Может держать, к примеру, несколько версий и разновидностей JDK и переключаться между ними по необходимости. Ну и разновидностей JDK целый вагон.
Работает на большинстве Unix-образных систем и вроде как даже на винде через Cygwin, но я не пробовал. Не заменит
brew или же apt, но рулить Java-миром через него однозначно удобнее. Крайне рекомендую к установке.🔥9👍7
Для чего же всё-таки нужно резюме
Представьте, заходите вы в чат, а там два полярных мнения:
1. Резюме бесполезно. Соискатели всё врут, поэтому работодатели резюме не читают и всё нужное узнают на собеседовании.
2. Резюме полезно. Соискатель может показать важные кейсы, а работодатель получить общее представление и подумать, о чём спрашивать на собеседовании.
Какое сами лайкните, а какое друзьям перешлёте?
Конечно, есть спектр мнений где-то между, но нам больше интересно именно ваше отношение к вопросу и волшебные истории с собеседований. Пишите в комментариях, устроим бугурт и фестиваль ненависти.
Представьте, заходите вы в чат, а там два полярных мнения:
1. Резюме бесполезно. Соискатели всё врут, поэтому работодатели резюме не читают и всё нужное узнают на собеседовании.
2. Резюме полезно. Соискатель может показать важные кейсы, а работодатель получить общее представление и подумать, о чём спрашивать на собеседовании.
Какое сами лайкните, а какое друзьям перешлёте?
Конечно, есть спектр мнений где-то между, но нам больше интересно именно ваше отношение к вопросу и волшебные истории с собеседований. Пишите в комментариях, устроим бугурт и фестиваль ненависти.
❤1👍1
Как Netflix мигрировали на новый API и ничего не потеряли. Первая часть
У Netflix недавно рассказали, как они мигрировали на новый API без даунтайма.
Вот самое любопытное:
Netflix мигрирует с legacy API на GraphQL. Просто выключить старый API и включить новый они не могут: обязательно что-нибудь пойдёт не так и будет стоить дорого.
Чтобы проверить новый API в боевых условиях, но без ущерба для пользователей, они деплоят его рядом со старым и проверяют через Reply Testing.
Когда получается, запрос пользователя отправляется на оба API: на новый и на старый, а ответы сравниваются. Если есть разница, значит, что-то в новом API упустили. Например:
Очевидно, забыли про поле ID и отдаём null.
А тут слетела локализация:
В статье пишут, что Reply Testing помог Netflix выявить следующие ошибки:
— encoding errors
— локализация
— формат даты и времени
— ну и, конечно, числа с плавающей точкой
А в следующей заметке поговорим, как они использовали A\B-тесты.
У Netflix недавно рассказали, как они мигрировали на новый API без даунтайма.
Вот самое любопытное:
Netflix мигрирует с legacy API на GraphQL. Просто выключить старый API и включить новый они не могут: обязательно что-нибудь пойдёт не так и будет стоить дорого.
Чтобы проверить новый API в боевых условиях, но без ущерба для пользователей, они деплоят его рядом со старым и проверяют через Reply Testing.
Когда получается, запрос пользователя отправляется на оба API: на новый и на старый, а ответы сравниваются. Если есть разница, значит, что-то в новом API упустили. Например:
/data/videos/0/tags/3/id: (81496962, null)
Очевидно, забыли про поле ID и отдаём null.
А тут слетела локализация:
/data/videos/0/tags/5/displayName: (Série, value: “S\303\251rie”)
В статье пишут, что Reply Testing помог Netflix выявить следующие ошибки:
— encoding errors
— локализация
— формат даты и времени
— ну и, конечно, числа с плавающей точкой
А в следующей заметке поговорим, как они использовали A\B-тесты.
Medium
Migrating Netflix to GraphQL Safely
By Jennifer Shin, Tejas Shikhare, Will Emmanuel
👍28❤1🔥1
Как Netflix мигрировали на новый API и ничего не потеряли. Вторая часть
В прошлой заметке было про тестирование нового API идемпотентными запросами. А в этой расскажем, как Netflix тестировали функциональность, которая меняет данные, и проверяли выполнение нефункциональных требований.
Для A\B-тестов Netflix поделили миллион пользователей на 2 группы:
— контрольную на старом API
— экспериментальную на новом.
Обе группы пользовались сервисом, а разработчики тщательно сравнивали quality of experience metrics: как часто возникают ошибки на клиенте, latency и прочее.
Конечно, разница метрик — это ещё не решение. Выявление проблем похоже на детектив: какой-то показатель ухудшился, а вам ещё нужно понять, из-за чего именно. К примеру, у Netflix нестабильный latency подсказал, что нужно подкрутить TTL кешей.
A\B-тесты оказались хорошим инструментом для проверки нефункциональных характеристик. За полгода Netflix уравняли показатели и мигрировали всех пользователей на новый API.
В прошлой заметке было про тестирование нового API идемпотентными запросами. А в этой расскажем, как Netflix тестировали функциональность, которая меняет данные, и проверяли выполнение нефункциональных требований.
Для A\B-тестов Netflix поделили миллион пользователей на 2 группы:
— контрольную на старом API
— экспериментальную на новом.
Обе группы пользовались сервисом, а разработчики тщательно сравнивали quality of experience metrics: как часто возникают ошибки на клиенте, latency и прочее.
Конечно, разница метрик — это ещё не решение. Выявление проблем похоже на детектив: какой-то показатель ухудшился, а вам ещё нужно понять, из-за чего именно. К примеру, у Netflix нестабильный latency подсказал, что нужно подкрутить TTL кешей.
A\B-тесты оказались хорошим инструментом для проверки нефункциональных характеристик. За полгода Netflix уравняли показатели и мигрировали всех пользователей на новый API.
👍10
А вы что думаете по этому поводу:
Anonymous Poll
44%
Согласен, разработка — физический труд
42%
Не согласен, программирование всё ещё элитарно
14%
Приду сраться в комменты
Здравствуйте! Это пост с набросом. Вы предупреждены.
Преамбула: в одном из архитектурных чатов у нас развернулась дискуссия по поводу специальности «разработчик»: стала она уже рабочей или ещё нет.
Рабочая — это когда нужно больше физического труда, чем умственного. И в этом смысле разработчик — вполне рабочая специальность, какоператор машинного доения сборщик на конвейере: собираешь типовые решения из представленных компонент за указанное время.
Всё описано в регламентах, собрано во фреймворки, поэтому средний разраб заменяется за день. А придумывать, как оно должно работать, — работа системных инженеров. И тут у нас получается условное деление по признаку образования:
— средне специальное образование для работяг — языки, эти ваши фреймворки и среды;
— высшее образование для инженеров — системное проектирование и всякие высокие абстракции.
И с этой позиции критика высшего образования, где «не учат актуальным языкам и фреймворкам» звучит неубедительно, там вроде как другому учить должны.
Что-то подобное я говорил на archdays, где рассказывал про подход с типовыми узлами, интерфейсами и даже наймом за день.
Преамбула: в одном из архитектурных чатов у нас развернулась дискуссия по поводу специальности «разработчик»: стала она уже рабочей или ещё нет.
Рабочая — это когда нужно больше физического труда, чем умственного. И в этом смысле разработчик — вполне рабочая специальность, как
Всё описано в регламентах, собрано во фреймворки, поэтому средний разраб заменяется за день. А придумывать, как оно должно работать, — работа системных инженеров. И тут у нас получается условное деление по признаку образования:
— средне специальное образование для работяг — языки, эти ваши фреймворки и среды;
— высшее образование для инженеров — системное проектирование и всякие высокие абстракции.
И с этой позиции критика высшего образования, где «не учат актуальным языкам и фреймворкам» звучит неубедительно, там вроде как другому учить должны.
Что-то подобное я говорил на archdays, где рассказывал про подход с типовыми узлами, интерфейсами и даже наймом за день.
YouTube
Как Event Storming, DDD и чистая архитектура помогают запустить стартап. Евгений Лукьянов
Выступление на ArchDays 2022. Подробнее о конференции: https://archconf.ru/arch
Бытует мнение, что все эти DDD и прочие DD нужны, только когда ваш проект вырос и генерирует сотни денег. На примере нашей конторы мы убедились, что это не так и все это позволяет…
Бытует мнение, что все эти DDD и прочие DD нужны, только когда ваш проект вырос и генерирует сотни денег. На примере нашей конторы мы убедились, что это не так и все это позволяет…
👍8😁1
Как сэкономить 120 000 $ в год на инфраструктуре? Просто возьмите старый проверенный EC2
Ситуация: клиент попросил оценить, не слишком ли много тратить 240 000 $ в год на инфраструктуру приложения, которое обслуживает 35 пользователей с 9:00 до 18:00.
Что мы нашли под капотом:
— 6 микросервисов, потому что модно и молодёжно
— по 2 инстансы каждого, потому что отказоустойчивость
— по 2 инстанса БД на каждый сервис, см. пункт выше
— деплой на AWS Fargate
Стоило это все 8000 $ в месяц на боевом сервере + столько же на UAT-стенде с зеркалом, который должен был быть у клиента по требованию регулятора.
Что мы изменили
1. Смёржили всё в два сервиса.
Микросервисы — отличная технология, когда вам нужно независимо масштабировать сервисы, устойчивость к отказам и независимый деплоймент сервисов. Но это при условии, что у вас микросервисы независимы и у вас зрелые Devops-практики. У нашего же клиента был типичный Distributed big ball of mud, который сводил все преимущества микросервисов в ноль.
2. Перевели деплой с AWS Fargate на EC2.
У AWS есть 2 варианта деплоя контейнеров:
— традиционный EC2. Вам выделяется виртуальная машина или несколько, в каждую машину напихивается столько контейнеров, сколько влезет.
— новый-молодежный Fargate, в котором кубернетису не нужно думать, раскидывать контейнеры по виртуалкам. Просто указываем, сколько каждому контейнеру нужно CPU и памяти, а тёмные электрические силы Амазона дальше сами всё делают.
Однако у всего есть цена. В EC2 мы могли развернуть несколько контейнеров и они шарили ресурсы. Например, пока сервис отчётов ничего не делает, он делится ресурсами с бизнесовым сервисом и наоборот. С Fargate так не выйдет, платить нужно и за простой, а ресурсы не пошаришь. Поэтому, если сервисы часто простаивают, Fargate стоит очень дорого.
EC2 стоил 3000 $ вместо 8000 $ за Fargate, получилось 60 тысяч экономии в год. Столько же удалось сэкономить на UAT-стенде. Итого те самые 120 тысяч в год из заголовка.
Ситуация: клиент попросил оценить, не слишком ли много тратить 240 000 $ в год на инфраструктуру приложения, которое обслуживает 35 пользователей с 9:00 до 18:00.
Что мы нашли под капотом:
— 6 микросервисов, потому что модно и молодёжно
— по 2 инстансы каждого, потому что отказоустойчивость
— по 2 инстанса БД на каждый сервис, см. пункт выше
— деплой на AWS Fargate
Стоило это все 8000 $ в месяц на боевом сервере + столько же на UAT-стенде с зеркалом, который должен был быть у клиента по требованию регулятора.
Что мы изменили
1. Смёржили всё в два сервиса.
Микросервисы — отличная технология, когда вам нужно независимо масштабировать сервисы, устойчивость к отказам и независимый деплоймент сервисов. Но это при условии, что у вас микросервисы независимы и у вас зрелые Devops-практики. У нашего же клиента был типичный Distributed big ball of mud, который сводил все преимущества микросервисов в ноль.
2. Перевели деплой с AWS Fargate на EC2.
У AWS есть 2 варианта деплоя контейнеров:
— традиционный EC2. Вам выделяется виртуальная машина или несколько, в каждую машину напихивается столько контейнеров, сколько влезет.
— новый-молодежный Fargate, в котором кубернетису не нужно думать, раскидывать контейнеры по виртуалкам. Просто указываем, сколько каждому контейнеру нужно CPU и памяти, а тёмные электрические силы Амазона дальше сами всё делают.
Однако у всего есть цена. В EC2 мы могли развернуть несколько контейнеров и они шарили ресурсы. Например, пока сервис отчётов ничего не делает, он делится ресурсами с бизнесовым сервисом и наоборот. С Fargate так не выйдет, платить нужно и за простой, а ресурсы не пошаришь. Поэтому, если сервисы часто простаивают, Fargate стоит очень дорого.
EC2 стоил 3000 $ вместо 8000 $ за Fargate, получилось 60 тысяч экономии в год. Столько же удалось сэкономить на UAT-стенде. Итого те самые 120 тысяч в год из заголовка.
👏19👍3❤1
Наткнулся на неплохой мануал с примерами по spring-security и oauth
Как известно, в
Как известно, в
spring-security сам черт ногу сломит, а если туда oauth добавить, то, вообще, никогда в жизни не разберёшься. В мануале автор неплохо объясняет, как что устроено с точки зрения спринга.GitHub
spring-addons/samples/tutorials at master · ch4mpy/spring-addons
Ease OAuth2 / OpenID in Spring RESTful backends. Contribute to ch4mpy/spring-addons development by creating an account on GitHub.
🔥12
Я тут систематизировал стратегии как я торговался за оффер в Thoughtworks 4 года назад. 🙂 https://www.youtube.com/watch?v=jtu_FdNDxNc
Кстати, а как вы обычно выбиваете на собеседованиях зарплату по-больше?
Кстати, а как вы обычно выбиваете на собеседованиях зарплату по-больше?
YouTube
Как торговаться о зарплате без контроффера
3 способа как можно торговаться по зарплате даже если у вас на руках только один оффер.
☝ Поваренная книга дядюшки боба: Как готовить Clean Architecture:
🎓 Курс : https://howto.stringconcat.ru/cleanarchitecture?utm_source=youtube&utm_content=how_to_negotiate_offer…
☝ Поваренная книга дядюшки боба: Как готовить Clean Architecture:
🎓 Курс : https://howto.stringconcat.ru/cleanarchitecture?utm_source=youtube&utm_content=how_to_negotiate_offer…
👍9
Небольшая заметка о том, как гарантированно заехать в дурку, находясь в айтишечке
💯19👍5
Наш студент запилил для походов на работу
🔥50👍7
Привет, зазываем на курс!
15 сентября — старт новой группы по практическому курсу Разработка Enterprise-приложений без боли и сожалений.
Самое время учиться: кризис в индустрии свирепствует, СhatGPT душит Stack Overflow. Скоро нейросети научатся перекидывать JSON в DTO, и многие кодеры окажутся не нужны, как знатоки Drupal. Чтобы остаться востребованным, нужно начинать мыслить не инструментами, а методологиями проектирования.
В общем, если хотите начать думать как тимлид, архитектор и техдир, идите на наш курс. Мы его переработали, так что теперь там ещё больше индивидуального подхода и обратной связи.
До 1 сентября курс стоит 90 000 ₽
Со 2 сентября — 140 000 ₽
Подайте заявку и сэкономьте 30% Изи мани, рил ток
15 сентября — старт новой группы по практическому курсу Разработка Enterprise-приложений без боли и сожалений.
Самое время учиться: кризис в индустрии свирепствует, СhatGPT душит Stack Overflow. Скоро нейросети научатся перекидывать JSON в DTO, и многие кодеры окажутся не нужны, как знатоки Drupal. Чтобы остаться востребованным, нужно начинать мыслить не инструментами, а методологиями проектирования.
В общем, если хотите начать думать как тимлид, архитектор и техдир, идите на наш курс. Мы его переработали, так что теперь там ещё больше индивидуального подхода и обратной связи.
До 1 сентября курс стоит 90 000 ₽
Со 2 сентября — 140 000 ₽
Подайте заявку и сэкономьте 30% Изи мани, рил ток
👍12💩5🤩3🔥2
Господа, давно не рекомендовали вам хорошей литературы. Хотим исправиться.
Не секрет, что мы с Сережей нежно любим котлин и еще нежнее - его отдельные концепции, такие как корутины. Если вы ими никогда не пользовались (но всегда хотели) или пользовались мало (и не заценили), то рекомендуем обратить внимание на книжку Kotlin Coroutines, Deep Dive за авторством Marcin Moskał. Разжевано хорошо, много картиночек и иллюстраций. Нет сложных концепций, хорошо это или плохо решайте сами, но читается точно легко.
Не секрет, что мы с Сережей нежно любим котлин и еще нежнее - его отдельные концепции, такие как корутины. Если вы ими никогда не пользовались (но всегда хотели) или пользовались мало (и не заценили), то рекомендуем обратить внимание на книжку Kotlin Coroutines, Deep Dive за авторством Marcin Moskał. Разжевано хорошо, много картиночек и иллюстраций. Нет сложных концепций, хорошо это или плохо решайте сами, но читается точно легко.
Leanpub
Kotlin Coroutines
Kotlin Coroutines, Concurrency, Threads, Multithreading, Parallel programming, Async Await
👍16🔥1
Я только что вернулся из командировки из Китая.
И хочу поделится впечатлениями, особенно тем что касается разработки. И китайских девочек.
Приятного пятничного просмотра под кофеек!
https://youtu.be/RZlpDhtR7lU
И хочу поделится впечатлениями, особенно тем что касается разработки. И китайских девочек.
Приятного пятничного просмотра под кофеек!
https://youtu.be/RZlpDhtR7lU
YouTube
[Личный Опыт] IT в Китае. Как работается в китайской ИТ компании
🎓 Разработка Приложений без Боли и Сожалений:
https://howto.stringconcat.ru/enterprise?utm_source=youtube&utm_content=interview_in_china
☝ Поваренная книга дядюшки боба: Как готовить Clean Architecture:
🎓 Курс : https://howto.stringconcat.ru/cleanarch…
https://howto.stringconcat.ru/enterprise?utm_source=youtube&utm_content=interview_in_china
☝ Поваренная книга дядюшки боба: Как готовить Clean Architecture:
🎓 Курс : https://howto.stringconcat.ru/cleanarch…
👍12💋3😢1
Хочу порекомендовать 3 классические книги молодым коллегам. Составил Top 2, нужен ваш совет по 3ей.
1.Clean Code by Robert Martin Или Code Complete by Book by Steve McConnell. (На мой взгляд они рассказывают об одно и том же)
Они научат писать понятный и поддерживаемый код на базовом уровне: Как думать объектами, а не процедурами, как называть переменные, когда нужно бросать исключения и пр. Мой путь к профессиональному разработчику начался именно с этих книг. Приучили к горшку, так сказать.
2.вторая не менее важная The Pragmatic Programmer: Your Journey To Mastery, которая рассказывает что происходит в разработке, если немного оторваться от кода. Что делать надо не то что вам сказали, а нужно думать “зачем” это нужно и “кому”. Да и вообще она о философии разработчика: как прожить долгую и счастливую программерскую жизнь.
3.А какую третью книгу вы бы порекомендовали разработчику с 1-2годами опыта? Какая книга на вас повлияла больше всего?
1.Clean Code by Robert Martin Или Code Complete by Book by Steve McConnell. (На мой взгляд они рассказывают об одно и том же)
Они научат писать понятный и поддерживаемый код на базовом уровне: Как думать объектами, а не процедурами, как называть переменные, когда нужно бросать исключения и пр. Мой путь к профессиональному разработчику начался именно с этих книг. Приучили к горшку, так сказать.
2.вторая не менее важная The Pragmatic Programmer: Your Journey To Mastery, которая рассказывает что происходит в разработке, если немного оторваться от кода. Что делать надо не то что вам сказали, а нужно думать “зачем” это нужно и “кому”. Да и вообще она о философии разработчика: как прожить долгую и счастливую программерскую жизнь.
3.А какую третью книгу вы бы порекомендовали разработчику с 1-2годами опыта? Какая книга на вас повлияла больше всего?
❤15👍2🔥1