Пару лет назад прочитал книгу Тома ДеМарко “Deadline. Роман об управлении проектами”. Всем менеджерам категорически советую ознакомится!
Чтобы освежить память, решил публиковать заметки главного героя, которые он делает походу повествования. Начнем!
Чтобы освежить память, решил публиковать заметки главного героя, которые он делает походу повествования. Начнем!
Из записной книжки мистера Томпкинса
Четыре основных правила менеджмента
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше. (Все остальное — административная ерундистика.)
Четыре основных правила менеджмента
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше. (Все остальное — административная ерундистика.)
Из записной книжки мистера Томпкинса
Безопасность и перемены
1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.
Безопасность и перемены
1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.
Из записной книжки мистера Томпкинса
Отрицательная мотивация
1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
3. Более того, если люди не справятся, вам придется выполнить свои обещания.
Отрицательная мотивация
1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
3. Более того, если люди не справятся, вам придется выполнить свои обещания.
Из записной книжки мистера Томпкинса
Части тела, необходимые для управления проектами
1. Для руководства нужны сердце, нутро, душа и нюх. Так что:
• руководить надо сердцем;
• чувствовать нутром;
• вкладывать в команду и проект душу;
• иметь нюх на всякую ерунду и бессмыслицу
2. Главнокомандующий на поле битвы как метафора управления проектами
3. К началу сражения работа главнокомандующего уже закончена.
Части тела, необходимые для управления проектами
1. Для руководства нужны сердце, нутро, душа и нюх. Так что:
• руководить надо сердцем;
• чувствовать нутром;
• вкладывать в команду и проект душу;
• иметь нюх на всякую ерунду и бессмыслицу
2. Главнокомандующий на поле битвы как метафора управления проектами
3. К началу сражения работа главнокомандующего уже закончена.
Из записной книжки мистера Томпкинса
Собеседование и прием на работу
1. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
2. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
3. Попросите наводку: тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
4. Больше слушайте, меньше говорите.
5. И все это сработает лучше, если вы слегка подтасуете колоду.
Собеседование и прием на работу
1. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
2. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
3. Попросите наводку: тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
4. Больше слушайте, меньше говорите.
5. И все это сработает лучше, если вы слегка подтасуете колоду.
Из записной книжки мистера Томпкинса
Повышение производительности
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»
Повышение производительности
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»
Часто слышал про https://www.hackerrank.com, и, к своему стыду, только сейчас взглянул на него.
К концу недели попробую попасть в топ 50к по С++ и python. Не думаю, что будет сложно, скорее, много времени.
К концу недели попробую попасть в топ 50к по С++ и python. Не думаю, что будет сложно, скорее, много времени.
Hackerrank
HackerRank - Online Coding Tests and Technical Interviews
HackerRank is the market-leading coding test and interview solution for hiring developers. Start hiring at the pace of innovation!
Всем двухфакторную аутентификацию! Чтобы убедиться, а стоит ли ее включить - проверьте, а не слили ли ваши персональные данные ранее. В моем случае, к сожалению, оказалось, что да. 6 лет назад у linkedIn, dropbox и два года назад у geekedIn был слив пользователей, в числе которых оказался и я. Слили мыло и еще что-то по мелочи. Пароли не хранились явно, поэтому и не были слиты (иначе я бы узнал об этом намного раньше =), а вот соль и хеши - да. Но это все равно позволило подобрать пароли для некоторого количества пользователей. Вывод - быстро включать двухфакторную аутентификацию!
https://monitor.firefox.com/
https://monitor.firefox.com/
Mozilla Monitor
Find out if you’ve been part of a data breach with Mozilla Monitor. We’ll help you understand what to do next and continuously monitor for any new breaches.
Из записной книжки мистера Томпкинса
Управление рисками
1. Чтобы управлять проектом, достаточно управлять его рисками.
2. Создайте список рисков для каждого проекта.
3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
4. Оцените вероятность возникновения и стоимость каждого риска.
5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству
Управление рисками
1. Чтобы управлять проектом, достаточно управлять его рисками.
2. Создайте список рисков для каждого проекта.
3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
4. Оцените вероятность возникновения и стоимость каждого риска.
5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству
Из записной книжки мистера Томпкинса
Играй в защите
1. Сокращайте потери.
2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.
Играй в защите
1. Сокращайте потери.
2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.
Из записной книжки мистера Томпкинса
Моделирование процесса разработки
1. Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
2. Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.
3. Предсказывайте результаты работы с помощью модели.
4. Сравнивайте результаты, полученные в процессе моделирования, с реальными.
Моделирование процесса разработки
1. Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
2. Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.
3. Предсказывайте результаты работы с помощью модели.
4. Сравнивайте результаты, полученные в процессе моделирования, с реальными.
И снова о главном!
https://habr.com/company/skillbox/blog/426051/
Самое важное - не забывается про троссировку, это реально может сэкономить дни, проведенные в отладчике.
https://habr.com/company/skillbox/blog/426051/
Самое важное - не забывается про троссировку, это реально может сэкономить дни, проведенные в отладчике.
Habr
Улучшаем навыки отладки ПО — несколько советов
От переводчика. Отладка ПО для многих кодеров — скучное и рутинное занятие. Но все же обойтись без дебагинга просто невозможно. Этот пост — перевод...
Когда не работаешь с потоками долго, всегда есть сомнения в корректности своих знаний в этой области.
Вспомним пару особенностей stl:
* shared_ptr - thread safe сам по себе, инкремент и декремент ссылок происходит безопасно. Доступ к объекту внутри, есстественно - не типобезопасен.
* все контейнеры - не thread safe, писать в одни элементы как и модифицировать контейнеры нельзя, но можно создавать объекты этих контейнеров (нет глобальных переменных по всей видимости в реализации), читать, итерироваться, изменять различные элементы в контейнере (но не vector<bool>)
Вспомним пару особенностей stl:
* shared_ptr - thread safe сам по себе, инкремент и декремент ссылок происходит безопасно. Доступ к объекту внутри, есстественно - не типобезопасен.
* все контейнеры - не thread safe, писать в одни элементы как и модифицировать контейнеры нельзя, но можно создавать объекты этих контейнеров (нет глобальных переменных по всей видимости в реализации), читать, итерироваться, изменять различные элементы в контейнере (но не vector<bool>)
Уже как полгода я тим лид команды в 7 замечетельных человек.
Я постоянно задаюсь вопросом, а достоин ли я этого?
Ответа до сих пор я не нашел, но есть замечательный принцип Питера:
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности»
Я достаточно некомпетентен, чтобы занимать эту позицию :)
Я постоянно задаюсь вопросом, а достоин ли я этого?
Ответа до сих пор я не нашел, но есть замечательный принцип Питера:
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности»
Я достаточно некомпетентен, чтобы занимать эту позицию :)
"Managers are people who do things right; leaders are people who do the right thing" © Warren Bennis
Немного теории из вычислительной математики:
https://en.wikipedia.org/wiki/Numerical_stability
Вычислительная устойчивость алгоритмов характеризует отклонение между результатом и идеальным решением. Очень важно понимать, что много вычислений с плавающей точкой могут давать значительную погрешность, что приводит к вычислительной неустойчивости.
https://en.wikipedia.org/wiki/Numerical_stability
Вычислительная устойчивость алгоритмов характеризует отклонение между результатом и идеальным решением. Очень важно понимать, что много вычислений с плавающей точкой могут давать значительную погрешность, что приводит к вычислительной неустойчивости.
Wikipedia
Numerical stability
In the mathematical subfield of numerical analysis, numerical stability is a generally desirable property of numerical algorithms. The precise definition of stability depends on the context. One is numerical linear algebra and the other is algorithms for…
Акронимы, которые должны знать все программисты. Открою этот список с моего любимого:
KISS - Keep it simple, stupid
Принцип утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности.
DRY - Don’t repeat yourself
Принцип разработки, нацеленный на снижение повторения информации различного рода.
SOLID
Single responsibility - Каждый класс выполняет лишь одну задачу;
Open-closed - Программные сущности должны быть открыты для расширения, но закрыты для модификации;
Liskov substitution - Наследующий класс должен дополнять, а не изменять базовый;
Interface segregation - много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения;
Dependency inversion - Зависимость на Абстракциях. Нет зависимости на что-то конкретное.
YAGNI - You aren't gonna need it
Отказ добавления функциональности, в которой нет непосредственной надобности.
GRASP - General responsibility assignment software patterns
Набор шаблонов по разделению и назначению ответсвенности
TMTOWTDI - There’s More Than One Way To Do It
Девиз языка Perl
KISS - Keep it simple, stupid
Принцип утверждает, что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности.
DRY - Don’t repeat yourself
Принцип разработки, нацеленный на снижение повторения информации различного рода.
SOLID
Single responsibility - Каждый класс выполняет лишь одну задачу;
Open-closed - Программные сущности должны быть открыты для расширения, но закрыты для модификации;
Liskov substitution - Наследующий класс должен дополнять, а не изменять базовый;
Interface segregation - много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения;
Dependency inversion - Зависимость на Абстракциях. Нет зависимости на что-то конкретное.
YAGNI - You aren't gonna need it
Отказ добавления функциональности, в которой нет непосредственной надобности.
GRASP - General responsibility assignment software patterns
Набор шаблонов по разделению и назначению ответсвенности
TMTOWTDI - There’s More Than One Way To Do It
Девиз языка Perl
Давно пишу на питоне. У него есть большое количество несомненных плюсов и минусов. Но за его Дзен, я думаю, стоит ценить особенно. Как так просто и компактно можно сформулировать идеологию языка?
Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец (намек на создателя Гвидо ван Россума).
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имён — отличная вещь! Давайте будем делать их больше!
Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и, желательно, только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец (намек на создателя Гвидо ван Россума).
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имён — отличная вещь! Давайте будем делать их больше!
Полезная тулза под linux и mac os. Создать новую сессию
screen
#CNTRL+A, D - выйти из сессии.
#Подключиться к ранее созданной сессии
screen -r
Бывает, работаешь над задачей долгое время, наделаешь дофигище промежуточных коммитов, потом еще и замечания по ревью поправить не одним придеться.
Хочется все-таки чтобы история была более или менее информативной. Поэтому сквошу коммиты по каким-то крупным фичам.
Для этого есть простой, как по мне, способ:
В истории пулл реквеста на битбакете, как показала практика, коммиты остаются, они просто помечаются удаленными, как и замечания по коду.
Хочется все-таки чтобы история была более или менее информативной. Поэтому сквошу коммиты по каким-то крупным фичам.
Для этого есть простой, как по мне, способ:
git fetch # забираем изменения
git merge origin/master # подмерживаем ветку, куда мы делаем в дальнейшем pull request
git reset --soft origin/master # подчищяем ветку и оставляем только изменения
git commit -am "Message text" # коммит все это дело в наш бранч, с хорошим коммит сообщением о сделанных изменениях
git push --force # удаленный репозиторий должен принять все наши изменения
В истории пулл реквеста на битбакете, как показала практика, коммиты остаются, они просто помечаются удаленными, как и замечания по коду.