https://www.bloomberg.com/opinion/articles/2020-01-07/coding-is-collaborative-and-stem-education-should-be-too
While the vast majority of employers value essential “soft skills” even more highly than a candidate’s college major, hiring managers place communication and problem-solving skills among the top-five competencies computer science students are missing.
The results can be seen in Silicon Valley’s individualistic culture, in which engineers struggle for power within their teams and even refuse colleagues’ input for fear of losing sole credit for their work. Code reviews are supposed to be opportunities to workshop issues, but instead become contests for recognition. When new team members have questions, they are told to “RTFM” or “read the fine manual.” Accepting help is cast as a weakness, and giving help is cast as a waste of time. Every time a coder fails to brainstorm or offer direction to a colleague, the industry loses out.
While the vast majority of employers value essential “soft skills” even more highly than a candidate’s college major, hiring managers place communication and problem-solving skills among the top-five competencies computer science students are missing.
The results can be seen in Silicon Valley’s individualistic culture, in which engineers struggle for power within their teams and even refuse colleagues’ input for fear of losing sole credit for their work. Code reviews are supposed to be opportunities to workshop issues, but instead become contests for recognition. When new team members have questions, they are told to “RTFM” or “read the fine manual.” Accepting help is cast as a weakness, and giving help is cast as a waste of time. Every time a coder fails to brainstorm or offer direction to a colleague, the industry loses out.
Bloomberg.com
We're Teaching Coding All Wrong
Budding computer scientists should learn to collaborate, not go it alone.
https://marker.medium.com/the-cynics-guide-to-reading-business-books-f4da2be2d7cb
But business information is valuable, and it should strike us as strange that we can spend $20 on Amazon for a billion-dollar idea. So it’s worth asking: What motivates business leaders and insiders to reveal these priceless secrets? Why would Ray Dalio want to tell you about the principles he used to make Bridgewater one of the world’s largest hedge funds? Why would George Soros want to share the strategies that have made him a successful investor?
Текст о том, как правильно читать между строк бизнес-литературу.
But business information is valuable, and it should strike us as strange that we can spend $20 on Amazon for a billion-dollar idea. So it’s worth asking: What motivates business leaders and insiders to reveal these priceless secrets? Why would Ray Dalio want to tell you about the principles he used to make Bridgewater one of the world’s largest hedge funds? Why would George Soros want to share the strategies that have made him a successful investor?
Текст о том, как правильно читать между строк бизнес-литературу.
Medium
The Cynic’s Guide to Reading Business Books
How to get the most out of CEO biographies and business tomes — and not just the lessons they want to teach you
Ещё одна схема для медитации и обдумывания. M&S здесь — это modeling and simulation, но схему можно и на другое распространить.
Слайд из вот этого документа.
Слайд из вот этого документа.
Закон Митчелла:
Любую проблему можно сделать неразрешимой, если провести достаточное количество совещаний по её обсуждению.
Закон Оулда и Кана:
Эффективность совещания обратно пропорциональна числу участников и затраченному времени.
Закон Хендриксона:
Если проблема требует множества совещаний, они, в конечном счете, станут важнее самой проблемы.
Закон комитето-динамики:
Чем меньше удовольствия вы испытываете от присутствия на совещании, тем больше вероятность того, что вам придется в нем участвовать.
Правило Рейберна:
Хочешь жить в согласии - соглашайся!
Закон Паттона:
Хороший план сегодня лучше безупречного завтра.
Правило очередности Свиппла:
Кто кричит громче всех, тому и дают слово.
Постулат Харриссона:
На каждое действие есть равная ему противодействующая критика.
Правило Сенеки для кормчего:
Когда корабль не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным.
Закон Карла Маркса:
Отдельный скрипач сам управляет собой, а оркестр нуждается в дирижере.
Правило Роджерса:
Проект примут только когда никого из членов комиссии нельзя будет обвинить в случае провала, но зато при успехе все смогут претендовать на поощрение.
Теорема неизбежности Бахмана:
Чем больше затраты на выполнение плана, тем меньше шансов отказаться от него - даже если он окажется несостоятельным.
Следствие: Чем выше престиж людей, стоящих за планом, тем меньше шансов его отмены.
Задержался - опоздал безнадежно.
Аксиома Гурда:
На собраниях - экономят минуты и теряют часы.
Закон Матильды об образовании подкомитетов:
Стоит выйти из комнаты, как тебя тут же выберут.
Любую проблему можно сделать неразрешимой, если провести достаточное количество совещаний по её обсуждению.
Закон Оулда и Кана:
Эффективность совещания обратно пропорциональна числу участников и затраченному времени.
Закон Хендриксона:
Если проблема требует множества совещаний, они, в конечном счете, станут важнее самой проблемы.
Закон комитето-динамики:
Чем меньше удовольствия вы испытываете от присутствия на совещании, тем больше вероятность того, что вам придется в нем участвовать.
Правило Рейберна:
Хочешь жить в согласии - соглашайся!
Закон Паттона:
Хороший план сегодня лучше безупречного завтра.
Правило очередности Свиппла:
Кто кричит громче всех, тому и дают слово.
Постулат Харриссона:
На каждое действие есть равная ему противодействующая критика.
Правило Сенеки для кормчего:
Когда корабль не знает, к какой пристани он держит путь, для него ни один ветер не будет попутным.
Закон Карла Маркса:
Отдельный скрипач сам управляет собой, а оркестр нуждается в дирижере.
Правило Роджерса:
Проект примут только когда никого из членов комиссии нельзя будет обвинить в случае провала, но зато при успехе все смогут претендовать на поощрение.
Теорема неизбежности Бахмана:
Чем больше затраты на выполнение плана, тем меньше шансов отказаться от него - даже если он окажется несостоятельным.
Следствие: Чем выше престиж людей, стоящих за планом, тем меньше шансов его отмены.
Задержался - опоздал безнадежно.
Аксиома Гурда:
На собраниях - экономят минуты и теряют часы.
Закон Матильды об образовании подкомитетов:
Стоит выйти из комнаты, как тебя тут же выберут.
Мне много лет хочется систему разработки и документирования архитектуры, но я так называю, по факту это система для хранения и визуализации разнообразных решений для проекта, планируемых или уже принятых. Я её визуально очень хорошо представляю: нечто вроде mindmap, только в любой элемент можно «погружаться», цеплять к нему задачи из трекера, тест-кейсы и тест-планы, результаты из трекера-задач и тест-трекера тоже каким-то образом попадают в этот семантический граф в нужное место. Любая функция продукта находится где-то в этой сети, её можно найти и посмотреть все связанные с ней элементы (результаты совещаний, результаты тест-планов, тикеты из сапортерской системы, задачи из таск-трекера и всё такое). Естественно, этот граф имеет временну́ю (точнее, версионную) размерность, то есть можно смотреть всё это применительно к определённой версии.
Короче, полный граф знаний, фактов и артефактов проекта. Его остро не хватает, когда пытаешься выяснить предпосылки появления некоей фичи пять лет назад, но никто ничего не помнит, а фича с тех пор шесть раз переименовалась и в трекере поиск тоже не работает, так как не все задачи корректно оформлены (на текущий момент, но пять лет назад были корректно!).
Короче, полный граф знаний, фактов и артефактов проекта. Его остро не хватает, когда пытаешься выяснить предпосылки появления некоей фичи пять лет назад, но никто ничего не помнит, а фича с тех пор шесть раз переименовалась и в трекере поиск тоже не работает, так как не все задачи корректно оформлены (на текущий момент, но пять лет назад были корректно!).
https://www.ufried.com/blog/systems_thinking_and_quality/
Очень краткое, но крайне насыщенное информацией изложение базовых принципов системного мышления.
Очень краткое, но крайне насыщенное информацией изложение базовых принципов системного мышления.
Ufried
Systems thinking and quality
Wise words from Russell Ackoff regarding systems thinking and quality improvement – and what we can learn from them
Три книги, которые выбрали мне будущее.
«И тут появился изобретатель» — детская книга про ТРИЗ.
«Сто историй о подземном городе» — книга об истории и технологии строительства ленинградского метро.
«Логическая игра» — несколько произведений Льюиса Кэрролла, включая собственно «логическую игру» — графическое решение силлогизмов.
Была ещё одна книжка, которая очень нравилась — об устройстве современной фермы, но я забыл её название, а в сети поиском найти не удалось.
«И тут появился изобретатель» — детская книга про ТРИЗ.
«Сто историй о подземном городе» — книга об истории и технологии строительства ленинградского метро.
«Логическая игра» — несколько произведений Льюиса Кэрролла, включая собственно «логическую игру» — графическое решение силлогизмов.
Была ещё одна книжка, которая очень нравилась — об устройстве современной фермы, но я забыл её название, а в сети поиском найти не удалось.
У американских братушек скоро тоже всё хорошо будет с криптографией и безопасностью, под бдительным надзором государева ока.
https://cyberlaw.stanford.edu/blog/2020/02/doj-plans-strike-against-encryption-while-techlash-iron-hot
https://cyberlaw.stanford.edu/blog/2020/02/doj-plans-strike-against-encryption-while-techlash-iron-hot
Витус Вагнер очень умную вещь пишет:
Lets Encrypt празднует выдачу миллиардного сертификата. И с гордостью сообщает, что сейчас 81% траффика в мире идет по https.
Мозилла планирует включить поддержку DNS over HTTPS.
Все дружно радуются. А по-моему, и то и другое - ПЛОХИЕ новости.
HTTPS вместо HTTP, это значит прощай кэширующие прокси, прощай антивирусы и баннерорезалки на роутерах.
DNS over HTTPS в БРАУЗЕРЕ это еще хуже. Это значит что мы не доверяем не только роутеру нашей локальной сети, нои и локальному DNS-резолверу того устройства, на котором запущен браузер. Зато доверем каким-то хренам с горы в Cloudflare.
У меня, между прочим на работе 80% запросов к веб-страницам это запросы к внутренним ресурсам локальной сети. И получается что если я не прослежу за настройками в резолвере при апгрейде файрфокса, он начнет с помощь DNS over HTTPS закладывать в CloudFlare структуру нашей корпоративной локальной сети.
То есть вместо традиционной иерархической структуры, когда есть программа, есть операционная система, которая этой программе обеспечивает безопасную и комфортную среду (например тот же ресолвер), есть локальная сеть и только за ее пределами начинается враждебный внешний мир, да и тот разделен на кольца враждебности по Войновичу, нам предлагают двухуровневую структуру - программа и сразу глобальная корпорация - провайдер сервиса. Ни локальный сисадмин, ни государство не могут защитить пользователя от произвола этой глобальной корпорации.
Lets Encrypt празднует выдачу миллиардного сертификата. И с гордостью сообщает, что сейчас 81% траффика в мире идет по https.
Мозилла планирует включить поддержку DNS over HTTPS.
Все дружно радуются. А по-моему, и то и другое - ПЛОХИЕ новости.
HTTPS вместо HTTP, это значит прощай кэширующие прокси, прощай антивирусы и баннерорезалки на роутерах.
DNS over HTTPS в БРАУЗЕРЕ это еще хуже. Это значит что мы не доверяем не только роутеру нашей локальной сети, нои и локальному DNS-резолверу того устройства, на котором запущен браузер. Зато доверем каким-то хренам с горы в Cloudflare.
У меня, между прочим на работе 80% запросов к веб-страницам это запросы к внутренним ресурсам локальной сети. И получается что если я не прослежу за настройками в резолвере при апгрейде файрфокса, он начнет с помощь DNS over HTTPS закладывать в CloudFlare структуру нашей корпоративной локальной сети.
То есть вместо традиционной иерархической структуры, когда есть программа, есть операционная система, которая этой программе обеспечивает безопасную и комфортную среду (например тот же ресолвер), есть локальная сеть и только за ее пределами начинается враждебный внешний мир, да и тот разделен на кольца враждебности по Войновичу, нам предлагают двухуровневую структуру - программа и сразу глобальная корпорация - провайдер сервиса. Ни локальный сисадмин, ни государство не могут защитить пользователя от произвола этой глобальной корпорации.
Я с самого начала очень скептически отношусь к идее DNS over HTTPS. И совершенно не понимаю, почему молчит вся прогрессивная общественность. Я своему провайдеру и даже ФСБ доверяю больше, чем американским корпорациям.
Корпорации, конечно, могут сколько угодно говорить, что DoH настраивается и можно сменить сервер, но все же понимают, что дефолтным будет американский корпоративный, а это колоссальная дыра в безопасности.
Корпорации, конечно, могут сколько угодно говорить, что DoH настраивается и можно сменить сервер, но все же понимают, что дефолтным будет американский корпоративный, а это колоссальная дыра в безопасности.
Почему изобретения не появляются раньше? https://rootsofprogress.org/epistemic-standards-for-why-it-took-so-long
tl;dr:
Изобретения появляются тогда, когда возникает необходимость в них и возможность создания. Иногда кажется, что некий девайс можно было на сотни лет раньше изобрести, но всегда оказывается, что до этого момента не было либо необходимости, либо возможности. Плюс ключевым моментом оказывается не само устройство в сборке, а некий ключевой элемент, появившийся недавно и благодаря которому девайс в принципе стал возможным.
tl;dr:
Изобретения появляются тогда, когда возникает необходимость в них и возможность создания. Иногда кажется, что некий девайс можно было на сотни лет раньше изобрести, но всегда оказывается, что до этого момента не было либо необходимости, либо возможности. Плюс ключевым моментом оказывается не само устройство в сборке, а некий ключевой элемент, появившийся недавно и благодаря которому девайс в принципе стал возможным.
The Roots of Progress
Epistemic standards for “Why did it take so long to invent X?”
How to answer this question—and how not to
Аутсорс — это абсолютно нормальная и легитимная форма деятельности. Люди, которые демонстративно презирают аутсорс, либо дурачки, либо провокаторы.
Начнём с того, что большинство людей мало что знают про аутсорсинг, так как это изначально деятельность формата business-to-business, и обычные люди с ней никогда не пересекаются и толком не знают, как она работает. А причина презрения кроется в хроническом когнитивном заблуждении «чтобы было лучше, нужно делать самому», которое восходит к Эффекту Данинга-Крюгера и явно ещё к чему-нибудь, что мне лень гуглить.
Аутсорсинг требует специальных знаний и квалификаций с обоих сторон, причём если про эти квалификации аутсорс-конторы более-менее все осведомлены, то про знания и умения со стороны заказчика все забывают. И совершенно напрасно, так как именно в их отсутствии кроется непонимание и неприятие.
Собственно, в чём суть аутсорса — отдать на сторону часть собственной работы. Человеку со стороны может показаться, что это легко, но если вы попробуете детально представить весь процесс, то окажется, что он довольно сложный. И главных проблем здесь две: изолировать некий кластер внутренних работ, которые можно отдать на аутсорс, и дальше интегрировать результат внешней работы назад в свою систему. Очень важно при этом понимать, что аутсорс — это «чёрный ящик», про детали внутреннего устройства которого вы ничего не знаете, в отличие от процессов в вашей компании, поэтому для вас окажется сюрпризом, что «изолировать кластер внутренних работ» вовсе не так просто. Ведь вы не знаете ничего про внутренности чёрного ящика аутсорса, но внутри компании работаете в «прозрачном ящике», и все ваши работы построены с учётом знаний о внутреннем устройстве и процессах компании: описания, техническая документация, тесты и прочее. И чтобы передать работу в чёрный ящик, вы должны эту документацию, тесты и прочее полностью переделать так, чтобы можно было это «скормить» внешнему чёрному ящику.
Простой пример. Когда вы разрабатываете что-нибудь внутри компании, в процессе можно неоднократно что-то менять и поправлять, однако для аутсорсера у вас обычно нет таких рычагов влияния. Поэтому чтобы отдать, скажем, некий код на аутсорс, вы должны предельно точно и подробно описать, что этот код должен принимать на вход и что отдавать на выход. И это действительно сложно, если вы такой код делаете в первый раз — вам понадобится действительно умный и толковый инженер-аналитик, чтобы предельно тщательно расписать и согласовать все нюансы.
Итог: аутсорс работает там, где заранее чётко и точно известно, что именно нужно сделать и как это затем проверить, чтобы интегрировать назад в систему. Когда вы отдаёте что-то на аутсорс, вы экономите затраты на разработчика (в широком смысле, речь не обязательно про software), но зато тратите деньги на аналитика. Если вторая сумма больше, то вам аутсорс точно не нужен.
Начнём с того, что большинство людей мало что знают про аутсорсинг, так как это изначально деятельность формата business-to-business, и обычные люди с ней никогда не пересекаются и толком не знают, как она работает. А причина презрения кроется в хроническом когнитивном заблуждении «чтобы было лучше, нужно делать самому», которое восходит к Эффекту Данинга-Крюгера и явно ещё к чему-нибудь, что мне лень гуглить.
Аутсорсинг требует специальных знаний и квалификаций с обоих сторон, причём если про эти квалификации аутсорс-конторы более-менее все осведомлены, то про знания и умения со стороны заказчика все забывают. И совершенно напрасно, так как именно в их отсутствии кроется непонимание и неприятие.
Собственно, в чём суть аутсорса — отдать на сторону часть собственной работы. Человеку со стороны может показаться, что это легко, но если вы попробуете детально представить весь процесс, то окажется, что он довольно сложный. И главных проблем здесь две: изолировать некий кластер внутренних работ, которые можно отдать на аутсорс, и дальше интегрировать результат внешней работы назад в свою систему. Очень важно при этом понимать, что аутсорс — это «чёрный ящик», про детали внутреннего устройства которого вы ничего не знаете, в отличие от процессов в вашей компании, поэтому для вас окажется сюрпризом, что «изолировать кластер внутренних работ» вовсе не так просто. Ведь вы не знаете ничего про внутренности чёрного ящика аутсорса, но внутри компании работаете в «прозрачном ящике», и все ваши работы построены с учётом знаний о внутреннем устройстве и процессах компании: описания, техническая документация, тесты и прочее. И чтобы передать работу в чёрный ящик, вы должны эту документацию, тесты и прочее полностью переделать так, чтобы можно было это «скормить» внешнему чёрному ящику.
Простой пример. Когда вы разрабатываете что-нибудь внутри компании, в процессе можно неоднократно что-то менять и поправлять, однако для аутсорсера у вас обычно нет таких рычагов влияния. Поэтому чтобы отдать, скажем, некий код на аутсорс, вы должны предельно точно и подробно описать, что этот код должен принимать на вход и что отдавать на выход. И это действительно сложно, если вы такой код делаете в первый раз — вам понадобится действительно умный и толковый инженер-аналитик, чтобы предельно тщательно расписать и согласовать все нюансы.
Итог: аутсорс работает там, где заранее чётко и точно известно, что именно нужно сделать и как это затем проверить, чтобы интегрировать назад в систему. Когда вы отдаёте что-то на аутсорс, вы экономите затраты на разработчика (в широком смысле, речь не обязательно про software), но зато тратите деньги на аналитика. Если вторая сумма больше, то вам аутсорс точно не нужен.
Очередной отличный текст Анатолия Левенчука о перспективах умственной деятельности и как пережить грядущие перемены с максимальной выгодой.
https://ailev.livejournal.com/1505596.html
https://ailev.livejournal.com/1505596.html
Livejournal
Спасайся, кто может: поднимайте свой интеллект, ибо непонятно, от чего спасаться
Будут ли ужасные перемены в занятости? Будут. Всегда были. Разве что не всегда эти перемены были такими скоростными и касались буквально всех занятых. И что делать? Государственный прогноз про последствия разрастания "цифровой экономики", затем выстроить…
Forwarded from 3pcb.ru
Почему в Китае производство электроники всё ещё дешевле? Если отбросить мистификации, то четыре причины:
1. Дешевое производство. Так было раньше, но после 2014 года всё изменилось. Рабочая сила в России не дороже китайской, да и остальные расходы точно не выше. В итоге стоимость часа одного рабочего примерно одинаковая.
2. Дешевые компоненты от мировых вендоров. По мере проникновения глобальных дистрибьюторов, ситуация в России постепенно меняется. Вслед за ними локальные дистрибюторы тоже вынуждены снижать наценки. Но всё равно остаётся азрыв в пользу Китая процентов десять.
3. Дешевые компоненты от китайских вендоров. Тоже всё не так плохо, многие качественные китайские бренды постепенно проникают в Россию. Главной проблемой остается инерция разработчиков, которые по-прежнему любят ставить какой-нибудь Amphenol или даже, прости господи, Würth. Преимущество Китая 10-20%.
4. "Китайский бизнес". Обычная ситуация - демпинг при первом заказе, а когда клиент увязнет - начинается поиск путей экономии. Замена компонентов на дешёвые аналоги без спроса, повышение цены по любому поводу, высокие цены на новые изделия. В итоге, никаких чудес - нормальная маржа китайского производителя 10-25 процентов, иначе бизнес не выживает.
С другой стороны, в пользу выгодности российского производства тоже есть аргументы:
5. Близость к разработке. Это не только экономия на командировках, но и отсутствие разницы во времени и языкового барьера - транзакционные издержки ниже, запуски и любые изменения быстрее.
6. Короткая логистика. Отгрузки продукции можно делать малыми партиями, и как следствие, оперативнее реагировать на возникающие проблемы.
7. Развитие компетенций. При работе с российским производством, легче происходит "перекрестное опыление", когда опыт, полученный на одном проекте, переносится на другой. Производство учит разработчиков, и наоборот. С Китаем это происходит намного сложнее из-за того же самого языкового барьера.
Собственно, суть нашего бизнеса контрактного производства - добавить пункты 2 и 3 к пунктам 5-6-7 и исключить 4.
1. Дешевое производство. Так было раньше, но после 2014 года всё изменилось. Рабочая сила в России не дороже китайской, да и остальные расходы точно не выше. В итоге стоимость часа одного рабочего примерно одинаковая.
2. Дешевые компоненты от мировых вендоров. По мере проникновения глобальных дистрибьюторов, ситуация в России постепенно меняется. Вслед за ними локальные дистрибюторы тоже вынуждены снижать наценки. Но всё равно остаётся азрыв в пользу Китая процентов десять.
3. Дешевые компоненты от китайских вендоров. Тоже всё не так плохо, многие качественные китайские бренды постепенно проникают в Россию. Главной проблемой остается инерция разработчиков, которые по-прежнему любят ставить какой-нибудь Amphenol или даже, прости господи, Würth. Преимущество Китая 10-20%.
4. "Китайский бизнес". Обычная ситуация - демпинг при первом заказе, а когда клиент увязнет - начинается поиск путей экономии. Замена компонентов на дешёвые аналоги без спроса, повышение цены по любому поводу, высокие цены на новые изделия. В итоге, никаких чудес - нормальная маржа китайского производителя 10-25 процентов, иначе бизнес не выживает.
С другой стороны, в пользу выгодности российского производства тоже есть аргументы:
5. Близость к разработке. Это не только экономия на командировках, но и отсутствие разницы во времени и языкового барьера - транзакционные издержки ниже, запуски и любые изменения быстрее.
6. Короткая логистика. Отгрузки продукции можно делать малыми партиями, и как следствие, оперативнее реагировать на возникающие проблемы.
7. Развитие компетенций. При работе с российским производством, легче происходит "перекрестное опыление", когда опыт, полученный на одном проекте, переносится на другой. Производство учит разработчиков, и наоборот. С Китаем это происходит намного сложнее из-за того же самого языкового барьера.
Собственно, суть нашего бизнеса контрактного производства - добавить пункты 2 и 3 к пунктам 5-6-7 и исключить 4.