yegor256 podcast: Recent Episodes
Yegor Bugayenko
Сергей Марков — руководитель разработки AI-проектов в Сбере (в т.ч. GigaChat, ruGPT-3/3.5, Kandinsky и др.), автор/соавтор научно-популярных работ об ИИ, автором двухтомника «Охота на электроовец. Большая книга искусственного интеллекта».00:00 Приветствие00:55 Какими моделями пользуется Сергей Марков?01:50 Если нас отключат от OpenAI? есть ли российские аналоги ИИ?08:51 Конвеер ИИ не может быть опенсорс10:28 20 конвееров по созданию ИИ в Китае11:53 Чем Anthropic лучше других конвеерв ИИ?16:50 Технологические революции под капотом22:30 Что будет тормозить развитие ИИ?31:24 Как развитие ИИ отразится на развитии человечества?39:24 AGI способный самостоятельно мыслить и действовать подобно человеку46:34 Что есть в людях, чего нет в машинах?51:51 Людям нужно меньше знаний? 55:40 Блокировка Mythos и Fable59:39 Чего боится правительство США закрывая Fable?01:02:57 Использование ИИ на интервью
Философия программиста в формате вопрос-ответ (каждую пятницу в 18:00 UTC+3)Blog: https://www.yegor256.comBooks: https://www.yegor256.com/books.htmlGitHub: https://github.com/yegor256 (don’t hesitate to follow in order to stay informed)Telegram channel with recent news and updates: https://t.me/yegor256news (subscribe to not miss a thing)Twitter with daily and weekly updates: https://twitter.com/yegor256 (follow me!)iTunes: https://podcasts.apple.com/us/podcast/yegor256-podcast/id1150826721SoundCloud: https://soundcloud.com/yegor256Yandex Music podcast by yegor256: https://music.yandex.ru/album/31142286VK Video: https://vk.com/yegor256news00:00 Вступление и 100-й выпуск03:31 Гигиена рабочего места и погода05:55 ИИ: двойное применение07:33 Большие игроки vs open-source09:01 ИИ в режиссуре и презентациях11:21 Ошибки Claude и лень GPT13:57 Устарел ли CleanCode?14:49 Qulice и эпоха инструментов качества22:17 Разрешение начальства на Claude Code25:46 Кризис дотком-масштаба30:13 Суперспособность: что строить дальше33:11 Карьера: вглубь или вширь35:30 Стартап или скиллы37:15 Переход с C++ на Go38:27 Как расти как IT-специалист39:30 Зарплаты в эпоху ИИ43:41 Вайб-кодеры и запасная профессия45:32 Инженер → продакт-менеджер52:19 Высшее образование в эпоху ИИ53:30 Управление без страха и жадности54:36 Офисное рабство и фриланс58:13 Если все перейдут на Zerocracy1:04:54 Промахи с бюджетами и сроками1:10:11 Стратегия Zerocracy и ИИ1:13:07 Claude Code в военной разработке1:17:57 Альтернативные мессенджеры1:19:25 Как строить коммунизм1:21:56 Россия и изоляционизм1:28:13 Философия: синдром самозванца1:29:14 Отношения с родителями и детьми
Философия программиста в формате вопрос-ответ (каждую пятницу в 18:00 UTC+3)Blog: https://www.yegor256.comBooks: https://www.yegor256.com/books.htmlGitHub: https://github.com/yegor256 (don’t hesitate to follow in order to stay informed)Telegram channel with recent news and updates: https://t.me/yegor256news (subscribe to not miss a thing)Twitter with daily and weekly updates: https://twitter.com/yegor256 (follow me!)iTunes: https://podcasts.apple.com/us/podcast/yegor256-podcast/id1150826721SoundCloud: https://soundcloud.com/yegor256Yandex Music podcast by yegor256: https://music.yandex.ru/album/31142286VK Video: https://vk.com/yegor256news00:00 Вступление: лаги, VPN и формат трансляции02:23 Категории вопросов на сегодня03:24 Разогрев: игры, Луна, Harmony OS06:00 Карьера: стоит ли идти «путём крысы»08:28 Справедливо ли ограничивать стажёров-студентов10:27 Selling point стартапа, когда код ничего не стоит12:38 Нужен ли английский для карьеры15:05 Почему индусы на ведущих ролях в корпорациях19:55 Вайб-кодинг, доктора наук и Claude Code23:01 Как успевать за трендами в эпоху шума24:21 Учиться писать код вручную или использовать агентов28:49 Как выбирать проект для опенсорса29:55 Моя самая большая ошибка: брошенная аспирантура31:03 AGI: ядерное оружие или просто удобный поиск35:11 Секреты и безопасность при работе с Claude Code37:38 Как ИИ закроет продукт «куполом» и что останется людям44:39 Может ли ИИ контролировать качество разработчика50:10 Литература по ООП и JavaScript53:03 Как правильно начинать большой проект55:33 Как зарабатывать больше в Zerocracy57:05 Микроменеджер: как с ним бороться1:00:41 Митинги — легализованный грабёж1:05:01 Философский вопрос: пассивный доход и раскулачивание1:12:46 Методологии: Scrum, Kanban и главный вопрос об оплате1:17:17 Поможет ли ИИ найти спутника жизни
Video is here: https://youtube.com/live/dT0xBRxY0WIФилософия программиста в формате вопрос-ответ (каждую пятницу в 18:00 UTC+3)Blog: https://www.yegor256.comBooks: https://www.yegor256.com/books.htmlGitHub: https://github.com/yegor256 (don’t hesitate to follow in order to stay informed)Telegram channel with recent news and updates: https://t.me/yegor256news (subscribe to not miss a thing)Twitter with daily and weekly updates: https://twitter.com/yegor256 (follow me!)iTunes: https://podcasts.apple.com/us/podcast/yegor256-podcast/id1150826721SoundCloud: https://soundcloud.com/yegor256Yandex Music podcast by yegor256: https://music.yandex.ru/album/31142286VK Video: https://vk.com/yegor256news00:00:00 Приветствие, технические проблемы00:01:57 Разогрев: американцы на Луне, коровы00:07:05 Live-кодинг с Claude Code00:09:53 Как ускорить code review с ИИ00:16:47 ИИ-секретарь для каждого00:18:17 Утечка source maps Claude Code00:22:37 ИИ-тестирование (Momentic)00:26:53 CodeSpeak и Markdown-планы для багов00:29:44 Как junior'у не отупеть с ИИ00:33:47 «Лестница в небо» Хазина00:39:51 Баги — это топливо проекта00:42:53 Оплата за результат и Zerocracy00:52:38 Domain Driven Design00:56:29 Почему software переусложнён, UML мёртв01:00:42 Куда расти DevOps-инженеру01:02:55 Прокрастинация01:06:33 Как менять траекторию карьеры01:09:36 Как попасть в Huawei без алгоритмов01:28:53 Половина IT — бесполезные проекты01:32:14 Китайские vs российские программисты
00:44:31 Торговый бот на $10 млрд и Fast Software00:50:10 Менеджмент при ТК: как добиться результатов00:55:03 Наказание и поощрение — инструменты менеджера00:57:34 Spec driven development и монорепозитории00:59:43 Spring vs Takes Framework01:01:38 Дети и тяга к деградации01:04:47 Робот Optimus vs биороботы-таксисты01:07:14 Семья как утешительный приз для лузеров?01:13:16 Книга Angry Tests и набор ревьюеров
Дмитрий Калаев — директор акселератора ФРИИ и венчурный инвестор. В интервью обсуждаем, как создать стартап, привлечь инвестиции, найти инвестора и построить технологический бизнес в России.Telegram канал Дмитрия: https://t.me/stayhungry_kalaevYouTube канал: @IIDFpodcast 00:00 Приветствие00:48 Как программисту создать стартап и стать фаундером?03:53 В каком виде фаундер получает деньги, наличка? 08:00 Как наказывают прогоревших фаундеров?10:30 Как венчурный инвестор следит за фаундером?11:14 Может ли фаундер купить себе Феррари?16:39 Какой этап в инвестировании требует больше всего энергии?18:31 Как происходит знакомство фаундера с инвестором и кто решается стать фаундером?24:24 Почему дивидентный поток не интересует инвесторов?26:36 Что такое IPO?30:27 Почему фаундеру сразу бы не пойти в IPO?34:45 ФРИИ подсказывает стартаперу направление?39:11 Чтобы начать стартап заполни форму на ФРИИ42:28 Хэппи сендвич и ИИ в выборе стартапов45:02 Красные флаги в стартапах50:06 Почему ФРИИ сам не дает идеи для стартапов?51:42 Стартап нельзя делать ради денег56:08 Перед стартапом лучше набраться опыта в корпорациях?58:36 Сравнение Y Combinator и ФРИИ01:05:07 Почему инвестиционный рынок в РФ в тысячу раз меньше, если ВВП меньше лишь в 10 раз?01:08:46 Почему вы не инвестируете миллиарды?01:11:29 В управлении ФРИИ всего шесть миллиардов рублей, почему так мало?01:14:36 Взгляд на ФРИИ со стороны инвестора01:19:37 Лучше запустить стартап. Дорогу осилит идущий.#стартап #инвестиции #венчурныйкапитал #предпринимательство #фрии #бизнес #стартапвроссии
Видео здесь: https://youtube.com/live/gfTb2FbgymAФилософия программиста в формате вопрос-ответ (каждую пятницу в 18:00 UTC+3)Angry Tests можно купить здесь: https://t.me/yegor256news/1768Наш чат Zerocracy в Телеграм: https://t.me/zerocracyBlog: https://www.yegor256.comBooks: https://www.yegor256.com/books.htmlGitHub: https://github.com/yegor256 (don’t hesitate to follow in order to stay informed)Telegram channel with recent news and updates: https://t.me/yegor256news (subscribe to not miss a thing)Twitter with daily and weekly updates: https://twitter.com/yegor256 (follow me!)iTunes: https://podcasts.apple.com/us/podcast/yegor256-podcast/id1150826721SoundCloud: https://soundcloud.com/yegor256Yandex Music podcast by yegor256: https://music.yandex.ru/album/31142286VK Video: https://vk.com/yegor256news
Видео здесь: https://youtube.com/live/2QESXkBhCvsФилософия программиста в формате вопрос-ответ (каждую пятницу в 18:00 UTC+3)Blog: https://www.yegor256.comBooks: https://www.yegor256.com/books.htmlGitHub: https://github.com/yegor256 (don’t hesitate to follow in order to stay informed)Telegram channel with recent news and updates: https://t.me/yegor256news (subscribe to not miss a thing)Twitter with daily and weekly updates: https://twitter.com/yegor256 (follow me!)iTunes: https://podcasts.apple.com/us/podcast/yegor256-podcast/id1150826721SoundCloud: https://soundcloud.com/yegor256Yandex Music podcast by yegor256: https://music.yandex.ru/album/31142286VK Video: https://vk.com/yegor256news00:00 Алиса, стоп!00:01:42 Менеджеры и AI00:02:23 Оплата за тикеты00:04:33 Блог программиста00:11:06 Алгоритмы на интервью00:16:09 Линус Торвальдс и успех00:20:06 VPN и блокировки00:27:57 Воспитание детей00:48:15 Обман и мораль00:55:28 Митинги и ответственность01:09:20 Поиск работы
F95: Роскомнадзор и MAX | Microsoft | Начальники | Huawei | PLD | Курсовые работы | Личные Границы by Yegor Bugayenko
Douglas Crockford is a software architect and language designer best known for his work on JavaScript, JSON, and for his sustained critique of mainstream programming language design and programming culture.Blog: https://www.crockford.com/pronto.htmlGitHub: https://github.com/douglascrockfordLinkedIn: https://www.linkedin.com/in/douglas-crockford-724600109/Video is here: https://youtu.be/BrlOIPEsSJ4
F82: 𝜑-calculus | Pet проекты | Распил | Социал-дарвинизм | UML | Apple vs. Google | Психологи by Yegor Bugayenko
Владимир Хориков — автор книг о unit тестировании, блоггер, спикер, программист на C#.Видео: https://youtu.be/9NT40K8KI6U
И35: А. И. Коробейников | компиляторы | LLVM | MLIR | Clang | биоинформатика by Yegor Bugayenko
F68: Наказания для Кодеров | ООП | MBA | Инфоцыгане | Zerocracy | Павка Корчагин by Yegor Bugayenko
F67: Java | Agil | CI/CD | MCP | зарплаты | софт скиллы | левые взгляды | справедливость by Yegor Bugayenko
F66: Децентрализация | Guy Ritchie | Aibolit | Ruby on Rails | Работа в Яндекс | Билл Гейтс by Yegor Bugayenko
И27: И. В. Аржанцев | ФКН ВШЭ, ICPC, стартапы, студенты, аспирантура, JetBrains, Yandex, MIT by Yegor Bugayenko
И26: В. А. Петров | СПбГУ, математика, R&D, наука в Китае, аспирантура не для всех by Yegor Bugayenko
Ицыксон Владимир Михайлович -- к.т.н, профессор института прикладных компьютерных наук в ИТМО
— один из первых деятелей рунета, российский учёный, директор по стратегическому маркетингу сервисов компании «Яндекс».
Шалыто Анатолий Абрамович -- профессор, доктор технических наук. Специалист в области автоматного программирования и проектирования алгоритмов логического управления технологическими процессами. С 2004 года заведующий кафедрой Технологии программирования факультета Информационных технологий и программирования (ФИТиП) Университета ИТМО. Преподает на кафедре «Компьютерные технологии». В 2008 году награждён премией Правительства РФ в области образования. В 2018 году в числе первых по стране награждён государственной наградой — знаком отличия «За наставничество».
Алексей Евгеньевич Недоря - специалист по разработке компиляторов, языков и систем программирования.
Скляров Дмитрий Витальевич - российский программист и специалист в области информатики, известный разработкой алгоритма программы Advanced eBook Processor для обхода защиты электронных книг в формате Adobe PDF. Руководитель отдела анализа приложений в компании Positive Technologies.
Анатолий Тимофеевич Фоменко — советский и российский математик, специалист в области многомерного вариационного исчисления, дифференциальной геометрии и топологии, теории групп и алгебр Ли, симплектической и компьютерной геометрии, теории гамильтоновых динамических систем. Академик Российской Академии Наук с 1994-го года. Лауреат Государственной премии РФ в области науки и техники. Один из авторов «Новой Хронологии» — концепции о том, что существующая хронология исторических событий неверна и требует коренного пересмотра.
Панов Александр Александрович - основатель и CEO компании Neiry, лидирующего российского разработчика уникальных ИТ-продуктов на базе нейротехнологий, а также один из основателей агентства «КБ-12», оказывающего широкий спектр услуг в областях брендинга, рекламы, креатива и маркетинга, и Лаборатории прибыльных стартапов, которая фокусируется на запуске дивидендных проектов в России и Африке.
Глеб Владимирович Носовский — советский и российский математик, известен, главным образом, как соавтор книг Анатолия Фоменко по «Новой Хронологии».
Евгений Рыжков - сооснователь PVS-Studio, инструмента для обнаружения ошибок и уязвимостей безопасности в исходном коде программ, написанных на C, C++, C# и Java.
Зуев Евгений Александрович - старший профессор практики Института разработки программного обеспечения и инженерии, заведующий лабораторией построения языков программирования и компиляторов в Университете Иннополис: https://innopolis.university/en/professor/eugene-zuev-/
Report at the IT Purple Conf conference (March 16-17, 2024, Moscow, MIPT).Conference website: https://fpmiconf.ru/Video is here: https://www.youtube.com/watch?v=VZDBG-BInWo
Яков Файн -- программист, эксперт в области software architecture, автор нескольких книг о JavaScript и TypeScript, блоггер и лидер общественного мнения.YouTube канал Якова: https://www.youtube.com/user/yfainTwitter: https://twitter.com/yfain
Райгородский Андрей Михайлович - российский математик, автор более 200 научных статей, лауреат премии Президента России 2011 года для молодых учёных, директор Физтех-школы прикладной математики и информатики МФТИ.
Coding without unit tests similar to building a house without a safety net: you can do this, but your productivity will be extremely low. You will mostly be driven by fear. Can you afford this?
Video is here: https://youtu.be/Y0Zx_sdVG48
When you interview each new candidate, your opinion will most likely be pretty subjective. I suggest you try to find a way to structure it with some generic approach, which you will apply to all interviews. This will help you not miss important information and always have a good explanation for your decisions.
The video is here: https://youtu.be/o_S1aSLoh14
The best bug report is the one that represents the simplest possible scenario where the bug shows up. Most bug reports are not like that. I suggest rejecting them and letting their authors simplify them.
Blog post: https://www.yegor256.com/2022/03/29/bugs-occam-razor.html
The video is here: https://youtu.be/UXu_Uejo0f0
When you report a bug, try to make it as simple as it's possible. When you accept a bug, ask the reporter to make it as simple as possible. Somebody has to do this work of minimization of a bug. I suggest this work is done by reporters.
Video is here: https://youtu.be/jiEJnLBowHc
When you write an academic paper or a patent together with your co-workers, who of them becomes your co-authors? All of them? Some of them? Who decides? In this video I'm asking for your help in defining the formula.
The video is here: https://youtu.be/TF8MKOfo3gI
AlphaCode recently announced that its ML model can write code as good as an average programmer. I don't think it's writing and I don't believe in this approach we will ever be able to get anything meaningful aside from pure marketing speculations.
Adam is a creator of CodeScene.com, a cloud service where you can check the quality of your code and spot places where your technical debt is the largest. He's also the author of "Your Code as a Crime Scene" book.
Adam's personal website: https://www.adamtornhill.com Twitter: https://twitter.com/adamtornhill?lang=en The book: https://amzn.to/3AXCPxz
Two months ago I bought a new MacBook Pro. After a month of waiting, I received it. My frustration was huge. I returned it to Apple and got the money back. Here is why.
The video is here: https://youtu.be/JYW25iNTqUE
Aino Corry is an expert in Agile and specifically in retrospectives: these are special type of meetings a team must conduct by the end of a sprint, a phase, or the entire project.
Aino's twitter is here: https://twitter.com/apaipi?lang=en
Aino's website: https://metadeveloper.com
And the book is here: https://amzn.to/3fREDOQ
The video is here: https://youtu.be/ByatpkT2-tI
Michael Kay is the editor of the W3C XSLT 2.0 and 3.0 language specifications for performing XML transformations and the developer of the Saxon XSLT and XQuery processing software.
The video is here: https://youtu.be/2Zt9oJtFKGw
"How do I become a software architect with a six-figure salary?" is the question I'm being asked very often. I can't say I know the answer but here is the strategy I would recommend to pursue: make sure your profile differs from all others somehow.
The video is here: https://youtu.be/mJb-H-8npFk
Andy Hunt is a writer of books on software development, co-author of "The Pragmatic Programmer," one of the 17 original authors of the Agile Manifesto, and a founder of "The Pragmatic Bookshelf" publishing agency.
The video is here: https://youtu.be/zebqDkVfY-g
Chief Technical Officer (CTO) is usually the highest technical position, where usually is a person who doesn't really remember how to write software code. A better setup would be with a CTO who codes every day and delegates management to Project Managers.
Video is here: https://youtu.be/b_w85hL2o04
Developing a software product and maintaining it are two different activities, even though both are very important. Developers and maintainers are people of different types and if you want to keep your best developers in the project, don't allow them to become maintainers.
The video is here: https://youtu.be/_BbgpugwpEI
Some of us think that the functionality of a product comes first, while the build pipeline (testing, coverage control, static analysis, style checking, deployment) goes next. Moreover, some of us believe that functionality is the foundation of a house, while the build is more like a decoration. I strongly disagree.
Video is here: https://youtu.be/TcD6jJKaLcg
When you are young and hungry for attention, you make open source products. They give you appreciation and recognition faster than anything else. When you grow up and become known for the products you created earlier, you lose interest in open source and give space to next-generation attention seekers. Thus, let's appreciate their work to keep new products coming.
The video is here: https://youtu.be/eyx69afklkY
What do you do with those who don't deliver almost anything except promises? Do you try to motivate them, discipline, organize, find better tasks for them? I suggest a better strategy: just ignore them. This is how you will save your time and energy for those who deserve your attention. This is how you help your team achieve better results.
The video is here: https://youtu.be/KvwEKA4Owuc
Many programmers love to use pre-commit hooks to run the build and test the code before it gets to the repository. I believe it's a bad idea for two reasons.
Most of us believe that it's impossible to measure the productivity of programmers, researchers, software experts, and other "talents". I believe it's possible. Here is a simple framework, which has experimentally proven its effectiveness. Try it out in your team.
The blog post is here: https://www.yegor256.com/2021/10/12/calibrated-achievement-points.html
The video is here: https://youtu.be/Qii3yrQJdHs
Proper management is not something any team can afford. Here is a simplified framework, which gives you enough control over project affairs and at the same time doesn't bother the team too much. I called it SIMBA since it's a Simplified Management By Artifacts.
The blog post is here: https://www.yegor256.com/2021/09/09/simba.html
The video is here: https://youtu.be/939ntzufGB0
Using auto-formatters to make your code look nice is a bad idea. Mostly because they won't teach you anything about code quality. Instead, always format your code manually. This is how you learn a lot about quality and good programming practices.
The video is here: https://youtu.be/NoBE-WNIVVs
Very often, as far as I can tell, programmers are not willing to participate in digital discussions (tickets, chats, boards) because they are afraid of bullying: their decisions may and will be criticized without any predefined rules. The solution is simple: make sure your team has a structured process of decision making, with explicit roles and permissions.
Jeff Atwood is an American software developer, author, blogger, and entrepreneur. He writes the computer programming blog Coding Horror. He co-founded the computer programming question-and-answer website Stack Overflow and co-founded Stack Exchange, which extends Stack Overflow's question-and-answer model to subjects other than programming.
Jeff's blog: https://www.codinghorror.com
Say you are an architect, and your customer or a product owner asks you to explain your technical decisions, you may immediately jump into explanations. Don't do that. There must be a clearly drawn line between your territory of responsibility and authority and theirs. They define requirements for the product you develop, you make technical decisions according to the requirements. You don't need to explain anything.
The video is here: https://youtu.be/WapJducA2NY
Your personal goals must be much more important for you than your project and your team's ones. Of course, the team will try to make you sell your soul to them, but you must not forget about your long-term objectives.
The video is here: https://youtu.be/rR4UFPvAulI
"Where do you find inspiration for coding," I hear very often. The trick is simple: I try not to stay for too long with the same code base. I try to extract sub-module, libraries, or frameworks from the products I work with and make them standalone products. This is fun: making new products.
The video is here: https://youtu.be/ygoWsvgXe1c
Very often our managers don't know exactly what we have to do. They don't have specific requirements, they don't know how to specify tasks for us. Is it bad? Many people complain and quit. I suggest the opposite strategy: you say and do what you think is important. Make your own requirements.
The video is here: https://youtu.be/a_UEkcV9laA
This year we organize a competition for student researchers. If you are a student (MSc, BSc, PhD), you most certainly do some diploma work. When finished, publish your results at ACM/IEEE conference and send us a link. We may give you a reward.
The video is here: https://youtu.be/53DCw1QyDRc
We all know how annoying are the recruiters who spam us instead of finding the right methods of approaching us carefully. Here is a quick summary of the advice I would give them all.
Video is here: https://youtu.be/dlPk1AE2aQk
Every time I start a new book, an article, or a new software project, I spend a lot of time making sure it visually looks nice. Sometimes this process even takes longer than the writing itself. I'm kidding about this, but it's not so far from the truth. Visual representation of data/text is very important.
The video is here: https://youtu.be/l4PhrB4AytY
Computer science is not so hard to do. If you are a professional software engineer, you can present your results in an academic way and publish them at one of those computer science conferences. You will get yourself a status of a researcher. This will only help you in your career.
The video is here: https://youtu.be/ARwiHvTA4dc
When you deal with a weak and incompetent manager, who is not capable of finding a way to measure people's results objectively, you have to behave like an imposter. If you don't, somebody else will and the manager will think that this guy is the best guy in the team, no matter what are the actual achievements.
Read the blog post: https://www.yegor256.com/2021/03/03/imposters-to-win.html
The video is here: https://youtu.be/ulrMXmIcC4w
You can acquire a new team member by making a better offer. I mean money. But you can't keep them with money. To keep someone in the team, especially if this is a top performer, you need two things: 1) challenging tasks, and 2) objective appraisal. Both of them are only available to good and strong managers.
Video is here: https://youtu.be/bRXaMOJMJYk
Just working for a product, creating a product, and making your customers happy doesn't mean being good. It only means being successful, rich, or effective. It's a pretty selfish strategy. If you consider yourself as a "good" person (whatever it means), you should think about giving something to the community, for free.
The video is here: https://youtu.be/TM7RodFnRr4
Our special guest is Pim de Morree from https://corporate-rebels.com/
More about Pim: https://corporate-rebels.com/rebel/pim
Twitter: https://twitter.com/pim_de_morree LinkedIn: https://www.linkedin.com/in/pimdemorree/
The video is here: https://youtu.be/VXbi5TXMsrY
If you outsource part of your software development project to a third-party, you may think that the best type of contract to sign is Fixed-Price: you set the scope, they promise the time and price, they deliver, you check the quality, and you pay. It sounds right, but in reality, it'll be a disaster. Instead, always sign Time&Material contracts: you tell them how much resources you need, they give you a quote per hour, you manage them, they work for you, you pay every month. This is much more effective.
The video is here: https://youtu.be/xUALewcix44
It's your job as a manager in a software team — to identify wrong behavior and find ways to punish it. The best manager, of course, will configure the management system so that it will enforce the punishment. Average managers use guilt and emotions as tools for that. Bad managers are scared to even think about punishment.
The video is here: https://youtu.be/2lyz-CRGBwk
Most of us are so scared now of the word "punishment" that all types of mistakes made by programmers remain unnoticed, very often. I believe, there are many types of mistakes that have to be punished. Everybody will win: the project, the people, and our customers.
The video is here: https://youtu.be/zJ_PqlMcYcE
Many of us believe that competition is not something a software team may need. Moreover, competition may destroy a team killing morale and promoting conflicts. This may happen, but not because the competition is a bad idea, but due to the misconfiguration of its rules.
The video is here: https://youtu.be/TyHCjKOFsBo
Traditionally, you tell your team what needs to be done and then force them (or motivate) to do it. You basically try to make your plans their plans. It works sometimes in some industries, but doesn't work with us programmers: we are too spoiled and lazy. I suggest a better planning principle: you let your people decide how many awards they are going to earn and then build your plans on top of their selfish desires.
The video is here: https://youtu.be/vaFPNdNaOAY
Competition in a team works only if are ready to lose some part of your team, and very soon. If you don't want that to happen and your main objective is to keep the team intact and alive — competition will only do you a bad favor.
Measuring the productivity of programmers to many of us seems like a dangerous process, which leads to a lack of value delivered. This is true, but only if you use the wrong metrics to do your measurements. Use the right ones and everything will be fine.
Video is here: https://www.youtube.com/watch?v=yZcNHZ_FJco
Many management experts believe that competition kills collaboration and that's why a software team must not encourage their people to compete. Instead, they should collaborate and help each other. I don't see a contradiction here. Moreover, I don't think that a fully altruistic collaboration is at all possible and/or productive. I argue with Allen Holub in this video.
The video is here: https://www.youtube.com/watch?v=qRuzYdmgjCg
It's a well-known "fact": best programmers are 30x times more effective than their average colleagues. How do you reward them? You pay them 30x salaries. Of course, you don't. However, they do deserve such a reward and won't work hard, if you don't give them something of this size. The only replacement of money is recognition, which you can give them only through fair competition.
The video is here: https://youtu.be/2bEB3phUXA4
If there is no competition in your team, everybody will soon be interested in making deals and cheating. The only simple rule that may prevent this from happening: when I win, you lose. If such a rule exists there, your team members will always be interested in achieving more instead of compromising the system.
The video is here: https://youtu.be/pgwVAaV0tRw
Shift-M podcast: https://www.yegor256.com/shift-m.html
Allen Holub personal website: https://holub.com/
Allen's Twitter: https://twitter.com/allenholub
Video is here: https://youtu.be/8OKdilyNOIg
I think there is a simple metric we all can use to understand who the minds of managers in teal organizations work. Just count the amount of message they send you every day and you will understand where you are standing compared to others in your team. No sarcasm.
The video is here: https://youtu.be/TmAJPeM4UlE
A famous book "Reinventing Organizations" suggests a new model of management, where people are not personally responsible for mistakes, but everybody altogether share responsibility and avoid hierarchies. I don't understand how this can work. It can't.
Video is here: https://youtu.be/WZlIb5oxDBQ
If you are a teacher, a mentor, or a team leader, your job is not to give your people the final opinion about their results. This would be a terrible mistake. Instead, you should make sure they work for the market and the market evaluates their performance. Best team leaders know how to do that.
If we reward programmers for each pull request they merge or for each ticket they submit and we don't control the quality of PRs and tickets, what will happen? Nothing good. They will easily abuse the system and there will be tons of low-quality tickets and PRs (or classes, or lines of code). However, if we do have strong quality control, everything will be just great. Thus, when someone says that paying per line of code will ruin the project I answer: "Only if your project is weak".
The video is here: https://youtu.be/JIspFqjRt80
Most of us don't feel comfortable asking a manager for a raise. And it's only natural. I suggest you don't do it. Instead, you approach them with a question about the system your company has for promotion and salary increases. Moreover, you don't ask because you need this, but you ask because you care about others. Should work! :)
The video is here: https://youtu.be/rvhI6m95Qxo
We do code reviews in order to control the quality of code programmers write. However, the question is: how can we control the quality of the code review process? The only objective metric that comes to my mind is the frequency of rejections. If a reviewer rejects too little, there is something wrong with the process or the reviewer.
The video is here: https://youtu.be/fbBotuMol6Q
They say that "collaboration" and "teamwork" are very important in software teams. I don't think so. I think that they are valued where the management and weak and information flow is chaotic. This is where you need collaboration. In perfect teams, people have individual tasks and personal appraisal of results.
The video is here: https://youtu.be/7xeQLtDZLYQ
The best and the only way to motivate programmers (and not only them) to achieve great results and solve complex problems is the give them fair rules of the game and make sure they compete against each other.
The video is here: https://youtu.be/darliiClsjE
David M. West is a retired professor in computer science, an author of a few books on object-oriented programming and software architecture, and a very interesting person. We recorded this interview on 8th of November.
The video is here: https://youtu.be/UaxSDFesUR0
No matter how you put it, we programmers are lazy. Most of us are lazy because incompetent, stupid, and not motivated to do anything at all, while others are lazy because they don't like to do boring work and only enjoy creativity and innovation. In either case, managers must keep this in mind and find methods of dealing with our laziness.
The video is here: https://youtu.be/FLZRgyXeZB4
We all hate daily stand-ups for so many reasons. But daily reports is a better tool, which makes the same impact, but with higher precision. I would recommend you use them in your team if you have no other management instruments.
The video is here: https://youtu.be/Yj1VFGK9vqc
There is only one indicator of a perfect management system in a company or a team. You can pay everybody for the results they deliver, instead of the time they spend? If you can, your management is perfect. If you can't, you still have room for improvement.
The video is here: https://youtu.be/2MUK_o9gU3E
If you tell your programmers that you measure their performance by the number of lines of code they write, you may have to possible outcomes. First, this will turn your management into bigger chaos if it was chaos before. Second, it will boost performance if your management was strong and transparent before.
The video is here: https://youtu.be/9Zen0B0SNwI
Making the entire team standing up every morning and discussing plans, issues, or exchanging information is a perfect way to demonstrate your team that you are an incompetent manager. Instead, use other management instruments to make technical decisions, share information, to plan, and to control progress.
The video is here: https://youtu.be/uov3LRJ12Nw
My experience tells me that there is a direct connection between the subjectively experienced performance of a programmer and the number of lines of code he or she produces every day. Believe it or not, the famous Lines of Code (LoC) metric may be used to measure who is the best and the worst in a software team.
The video is here: https://youtu.be/33Ym2ArSEjw
Why do we need morning standups in our Agile software teams? Some say that they help synchronize the team. Others believe that they are to encourage the team to share. There are many other stories, but I disagree with all of them. I think that we need these meetings in order to trigger guilt in our team members. They have to feel bad when they let everybody else down. Standing in the morning in front of everybody is the perfect moment to feel it.
The blog post about this: https://www.yegor256.com/2019/09/03/injection-of-guilt.html
Also, read this one: https://www.yegor256.com/2015/01/08/morning-standup-meetings.html
The video is here: https://youtu.be/ues5Dks37zI
Asking your programmers to estimate how much time or money a software product would cost is a mistake. They don't know and can't now. They can spend all your money and still deliver an incomplete product. Because the product is never complete. Instead, tell them how much you have. They will do their best to deliver the most they can within the limitations.
The video is here: https://youtu.be/lgScAwsYWCc
No matter how big or good is your software, it has an unlimited number of bugs, especially if we remember that maintainability bugs also are very important for the overall quality of a product.
This is my talk at TestCon: https://www.youtube.com/watch?v=aYXuK2do6FA
The blog post you may want to read: https://www.yegor256.com/2017/05/23/unlimited-number-of-bugs.html
The video is here: https://youtu.be/ZdHCrsQsoMI
If and when you want to convince your management to approve your idea, don't go there directly with a cold proposal asking for an answer. Instead, make a series of educational presentations, in order to help them understand the idea and agree with it. Then, they will come back to you and ask you to implement it. They may even forget who was the author. But the goal will be achieved.
The video is here: https://youtu.be/9ym5u4en0Tc
If the code is messy and dirty, blaming the situation is not correct. No matter what were the restrictions (both time, scope, and cost), your responsibility as a programmer is to deliver the code up to the quality expectations of the project. If you can't do that, you should inform the project beforehand. But don't blame the customer later.
The video is here: https://youtu.be/WKX8CUPuYvo
No matter how many big companies you worked for, your future employer will still pay more attention to your personal projects, especially open source. Well, provided the employer is savvy enough. Your personal code is much more valuable than the big name of some Facebook you have in your CV. They are just job places, but your code is something you managed to created. So, don't waste time and start your own pet projects now.
The video is here: https://youtu.be/_ga2tP3wZbI
When you work for a company and at the same time do open source development, you most certainly have a conflict of interest. The open-source is mostly for your own benefit, while the company expects you to give all your results to it. How will answer the questions when they ask you when your product is popular?
The video is here: https://youtu.be/TW4uxuiHjCw
Solving software problems in most cases is not about finding the right algorithms or optimizing the effectiveness of existing ones. It's about cleaning up the mess left by other programmers and by ourselves.
The video is here: https://youtu.be/kPmbRkSWYnY
"Jacks of all trader" were appreciated and valued in the past when computers were young. Now the situation is different: you either are a niche specialist and you make good money, or you know everything and your income is below average. This situation will only get worse for those who don't want to dive deeper into a specific tech domain.
The video is here: https://youtu.be/-WpBUrOxoDI
I often hear programmers complaining about projects they work in: customers are not happy, the market doesn't like us, nobody wants our product, etc. They not only complain, but they also quit. This is ridiculous. You don't need your product to be successful, you need your project to give you everything you need to be successful, personally. And this includes freedom and open source.
The video is here: https://youtu.be/wQwZPOzN2gI
Most of us programmers are good at writing code, but very bad in reporting bugs so that other programmers understand what is wrong and help us resolve issues. This is a very important "soft" skill. You can train it in open source projects, where nobody will listen to you unless you explain yourself very clearly and professionally. Take some open source project and try to submit bugs to them. You will see the reaction.
The video is here: https://youtu.be/Hrk_Jorc5z4
One of the most complex tasks while working in a team of software engineers is how to convince them that you are right and your technical decisions are correct. No matter how smart you are, you will have problems with this. In order to win in those fights, you need a support group: people who agree with you and will vote for your decisions. Open source projects may give you such a support group.
The video is here: https://youtu.be/DA9pK_yNLtc
1-го сентября 2020 года мне повезло выступить перед 200+ студентами Факультета Компьютерных Наук (ФКН) Высшей Школы Экономики (ВШЭ) в Москве, по случаю начала нового учебного года.
Видео здесь: https://youtu.be/Ly9u_ZAZFCk
You may think that being altruist and give your project and your team more than taking back is the right thing to do. It's not true. To the contrary, if you are being selfish and always make sure that the team is giving you back the same amount of value you are giving to it—you are doing the right thing and improving the management system in your company.
The video is here: https://youtu.be/A59xGYb-aGY
Being a talented programmer, in my opinion, means having an innate intolerance to mess. It means a permanent desire to structure and organize the code you are working on. This may be a great advantage if you are in a small project or a startup. However, if you join an enterprise, this will be your disadvantage, which may only hurt you and the people around you. Instead, you will have to learn new skills and acquire new talent for yourself: the ability to put up with mess around you.
The blog post about talent is here: https://www.yegor256.com/2019/12/31/talented-programmers.html
The video is here: https://youtu.be/8Ls88a_Y5iY
Some of us believe that a good open source project (or some of them) must have extensive and big documentation, in multiple Wiki pages or Markdown files. I don't believe in this. I believe that any project must be able to fit its documentation into a single README. If you can't fit it all into it, you are doing something wrong.
The video is here: https://youtu.be/Qxvk9z0tEP8
When someone comes to your product and asks questions about how it works, why it doesn't work, or simply complains about its problems: don't help them right away. Instead, fix the product while they are waiting "on the line," show them a new version of it, and ask to provide feedback again. This is how you use them as free testers and make your product become better.
The video is here: https://youtu.be/tI6rGQIevxU
No matter what kind of enterprise you are working in, you won't like what's happening around you: chaos, lack of control, lack of logic, and so on. Don't expect them to improve. Instead, find a place for yourself and make changes there. Be the leader of the changes and earn yourself karma points.
The video is here: https://youtu.be/SuAM9J2cTDo
Most managers are incompetent, lazy, and stupid. If you expect them to tell you what to do, you will have a lot of frustration. Because they don't know and they don't want to know. The solution is simple: start planning everything yourself and show them your plans. In most cases, they will be happy to leave you alone and let you do what you want. If it will be open-source, you will have a double win.
The video is here: https://youtu.be/CmUzNPqCF4s
Having a good source code repo in GitHub is not enough if you want your users to trust you and use your product. They expect you to deploy it somewhere where you can't delete it. Maven Central is a good example of such storage. If your binary artifacts are not there, your users will have serious concerns about whether to use your libraries or not.
The video is here: https://youtu.be/iFx2-U8fsrE
When they say that we are working for a big goal and that's why we don't use fine-grained metrics, be aware: you are dealing with an incompetent manager or an architect. Their job is to decompose larger tasks into smaller pieces, instead of feeding us stories about "Big Goals".
The video is here: https://youtu.be/kPTKT3jOG7c
Do you still wonder what is the best license to use for your new open-source product? GPL, BSD, Apache? Stop thinking about this. It doesn't matter. Just use the most simple one: MIT.
The video is here: https://youtu.be/vBOg8_nGDls
There are three strategies to get into open source when you are just starting. They didn't work for me. There is the fourth one, which I would suggest you try. I didn't try it myself, but I'm sure it's much more effective than the first three.
The video is here: https://youtu.be/IeoYXstRvzw
Most of us think that the programmers' performance can't be measured. We can't, they say, put a number on a person. I believe, we can and must. Just like any other job, software development has to be measured. The question is which metrics to use in order to do this objectively and effectively. In one of my recent blog posts, I suggested a number of metrics, which can be used individually or all together. Try to apply them for yourself and see what happens.
This is the blog post about this: https://www.yegor256.com/2020/06/23/individual-performance-metrics.html
The video is here: https://youtu.be/jjeW1hTtRh0
GitHub is the place you should keep your code at, no matter how perfect or complete it is. Small scripts, short documentation pages, some notes, simple documents: they all may be there, they all may be interesting for your followers. Don't wait until you have a complete library to open source, start smaller.
The video is here: https://youtu.be/xFXW5j2x7XI
We all work with some legacy and boring code. In most cases we can't decide what to work with, since this is what the business is paying for. Making small open source projects may become a great solution to deal with the boresome of the legacy: make them on your own and be the architect there, and have fun!
The video is here: https://youtu.be/qJxDV1TrEGE
A static analyzer is not a "nice" tool generating fancy statistics, which you can show to your boss and get back to work. A static analyzer is supposed to be a punisher for you for the mistakes you make.
The video is here: https://youtu.be/7rtQ4yQVAK0
If you have a good product to open source, don't do it in one go. Instead, take pieces out of it and open them slowly. This is how you buy your freedom from your organization and learn how to do open source, avoiding big mistakes.
The video is here: https://youtu.be/VuJNBXPnRy8
Your main goal as a creator of an open-source project is to prepare it for the users and contributors who will come after you. You will not stay with your project forever. You may not even stay with is for a few years. You don't want the project to die, do you? Just make it look attractive for future users and it will live forever.
The video is here: https://youtu.be/kV5j4Uysivo
The product you develop is very important. But the way you format and present your repository on GitHub is equally (or even more) important. This is how you attract contributors: by making your project look well-organized on GitHub.
The video is here: https://youtu.be/elOkw1OYd_U
It is inevitable: open source is how we will be developing software in the future. Nobody will pay for software, but only for services around it. You have to join this new market as soon as possible.
The video is here: https://youtu.be/JBdtSAJjFaU
Open source projects are the best places for training programmers and helping them grow their soft and tech skills. If you want to convince your management to allow you to work in an open-source, use this argument: your skills will only grow if your code is open.
The video is here: https://youtu.be/D12gi1x6Cdw
Venkat Subramaniam is a famous software expert, a regular speaker at software conferences, a book writer, and a software architect/programmer. He shares his views about self-development.
When you see the code that needs improvements you, as a good programmer, fix it because you don't want the bad quality to stay in your project. However, this good intent only harms the project. When you work in a team, you are not allowed to do what is not approved by the project. Every time you see an opportunity for refactoring, make a ticket and let the project decide when and who will do it.
The video is here: https://youtu.be/PkmVF64mZNo
Very often, those who read about Zerocracy and watch my videos, ask me whether I believe that the management model we are promoting, is applicable to real projects. They sometimes call it utopian and unrealistic. I suggest you look at it as a picture of an ideal software world, which may become your world if you try to apply it to your work, piece by piece. Try harder! :)
The video is here: https://youtu.be/cIq-pSFswUI
Independent technical reviews, which you may get in Zerocracy, won't help you find bugs in your software, this is what testers are for. They will help you understand how far your code base from the industry standards applicable to your tech stack. Most teams tend to do things in their own special way, which is a huge threat to maintainability. Don't wait until it's too late, start now.
The video is here: https://youtu.be/jzMZaC54nbc
Most CTOs and project managers I'm talking to believe that their teams "are doing fine" and don't need any audits. This means only one thing: they are incompetent managers. Professional managers know that "doing fine" now doesn't mean that the team doesn't have hidden and currently invisible defects, which will cost a lot, in the future. The job of a professional manager is to regularly identify problems, technical debt, risks, and threats. Zerocracy provides exactly this service, remotely.
The video is here: https://youtu.be/GlBf5-g4nGk
There are many reasons why people are being active in social networks, like Twitter, Instagram, Facebook, or Telegram channels. Some of them even have their own blogs or YouTube channels, like me. Some of them are having fun, but my primary objective of doing this and publishing my ideas online is that this activity helps me structure my thinking and make it more logical. I have thousands of censors constantly looking at what I'm saying and writing. You should do the same if you want to grow: start publishing your thoughts and see how many people follow you and read. If the number will grow, you have ideas. If not, well...
The video is here: https://youtu.be/CJ6oYeLGdmo
Most companies suffer from the legacy code they inherit from software teams that disband or programmers just quick. Companies have to do something with the software and they can't throw it away. Most of them hire full-timers to support the code, maintain, and hope that they will improve it. This won't happen. Full-timers are not interested in doing that and they won't. If you want your code base to become better you need people who are interested in going into conflict with the code base and the status quo. Freelancers are your only option.
The full video is here: https://youtu.be/0gnDmr_H2Ks
Very often I hear managers saying that if you even try to punish programmers for their mistakes they will quit and you will have no team. This may only happen to junior or lazy programmers. Professional software engineers are interested in being challenged and rewards+punishment is what constitutes a challenge. And the challenge is what motivates us, technical people, to work.
The video is here: https://youtu.be/PlvoXBgwooY
Our bosses what us to be productive, effective, and deliver results. However, the question is whether they can make us do it or not. When they hire us as full-timers and pay us for a full month of our time in the office, they can't do anything to force us to work. They can only rely on our desire to be "good soldiers." For some people, this may work, but true professionals are always smarter than their bosses and know how to look busy while doing something else. This will never be the case with people who are paid by the result.
Want to try to hire a team of freelancers in Zerocracy? Fill this form out: https://www.zerocracy.com/rfp
The full video is here: https://youtu.be/salVaSqJwb8
Junior programmers usually don't know where to start in order to practice, learn how to code, and work with professionals. They can't find the right project to contribute to. I'm suggesting you find a project, which is ready to reject your mistakes, no matter what. We have such projects, which are owned and managed by our best programmers, in Zerocracy. Join our Telegram chat and ask, there will be plenty of offers.
The chat is here: https://t.me/zerocracy
The video is here: https://youtu.be/dCn53X1I2R0
Sometimes we have tasks in our projects, which nobody wants to complete. They are difficult or impossible to decompose, or simply too complex. What do we do in order to motivate our programmers to work with those tasks? We use Boost Factor, which is a multiplier of a micro budget. In other words, we use money in order to motivate programmers. We believe that professional programmers are motivated by money and know how to demand more when more work is required.
The video is here: https://youtu.be/nvXu_Yl5Y_w
Most full-timers are afraid of showing their bosses that they find help at StackOverflow, because their managers expect them to be smart and know everything about the technologies they work with. Who would want to pay a full monthly salary to someone who constantly seeks help at StackOverflow, right? This is not the case with freelancers, on the other hand. Those who are paid by result are not required to be smart. They need to be productive and effective contributors. Who do you want to be?
The video is here: https://youtu.be/_4pk5GNUySg
Most companies and managers believe that they have to check people before they let them get into the team, through a number of very complex interviews. After that, they trust their programmers and hope they will be motivated and committed enough to deliver the best results. Agile also suggests the same. I strongly disagree. We must not deliver our trust only once when we hire someone. We must continuously inform programmers about their performance and trust them as much as they deliver, every day.
The video is here: https://youtu.be/KPbKqTXfZwA
I often hear a question: what is better, Agile or RUP? This question doesn't make a lot of sense since Rational Unified Process (RUP) is a framework with a large set of artifacts, processes, roles, and procedures; while Agile is a short list of philosophical points. I would actually strongly recommend you study RUP to understand software development (or even get certified). XDSD is our philosophy and Zerocracy is a framework.
Technical debt is a huge problem, when it is, well ... huge. What usually happens is this: we start a project, we work on its "prototype," we wait until it is fully ready, and then we start thinking about unit tests, continuous integration, and build automation. But it is too late because the product already is too big. The problem is that we hold the product in the prototype mode for too long. I believe that two weeks is the maximum a prototype should take. After that, it's a normal product, not a proof-of-concept anymore.
The video is here: https://youtu.be/4MP3xXGrpCY
Most programmers feel uncomfortable realizing that their employer may replace them one day. To make this event less likely to happen they do many things in order to make themselves unreplaceable. One of those things is unmaintainable source code, which nobody else will be able to understand if its author is fired. I think that this mindset is not only toxic but also very typical for unprofessional engineers. If you are professional enough, the market always has something to offer you and you always know what is the next step for you, after this team gets rid of you or you decide to quit. If you feel scared, just look into the future and start checking opportunities.
The video is here: https://youtu.be/yRm97umW4vE
I think that any repository, be it open source or proprietary, must have a single README file, which must include everything a new contributor needs to know about it: the product statement, the vision, the list of features and non-functional requirements, the list of technical decisions, which are important to know. Unfortunately, this file is very often forgotten, especially in non-OSS products. If you don't have it now, it's never too late to create it, and make it right.
The video is here: https://youtu.be/1zCH0xBiCP4
We started reviewing software projects of other companies, just a few weeks ago and our first finding is that programmers don't pay attention to anything aside from the code they write. They don't have build automation, unit testing, static analysis, continuous integration, test coverage control, database versioning, and many other things which are supposed to keep the code together. It seems that this is happening because of the lack of knowledge and experience.
The video is here: https://youtu.be/keGVpncTn4Q
The job of a good project manager is to organize the team the way that every team member wants to contribute and is ready to go through all possible obstacles and barriers, in order to make sure their results are accepted by the project. If the project manager has to chase programmers, ask them, beg them, and pull results from them, it is a bad project manager and the project is mis-configured.
The video is here: https://youtu.be/4j4Kddo5Xgw
A software team where everybody expresses their opinions loudly and strongly, always being ready to admit that "I was wrong," is not able to produce anything serious. This is what I read in one blog post recently. And I do agree with this. However, I disagree with the solution suggested in the blog post. The author suggests programmers be more humble and skeptical, which I believe will only lead to more compromises. We know that compromises are bad for quality. My solution is to have a formally assigned architect, who makes all final technical decisions.
When I start talking about 100% open source business model, most people wonder how is it possible to give away the entire source code base and still remain profitable, money wise. I think that any modern digital business has three components of success: the source code, the database, and the community of users, programmers, clients, and so on. If you make your source code fully open, you will only help your other two components (data and community) to grow. In Zerocracy and all our satellite projects, we rely on this business model. We open the code and invest in the community.
The video is here: https://youtu.be/4-7fth8Iku8
Do you want to be known in the open source world? If you don't, don't watch this video. If you do, there are eight things you should pay attention to when making a new GitHub repo: 1) make it small, 2) don't depend on other libraries, 3) make your README sexy, 4) write up a complete documentation, 5) ask everybody around to give you GitHub stars, 6) release it, 7) configure continuous integration, 8) communicate with your users via issues and pull requests. You can see how I do it in my libraries, in my GitHub account: https://github.com/yegor256
The video is here: https://youtu.be/vhOg-7uPbvA
Very often software project sponsors complain about the low quality of their programmers. They also say that changing the team doesn't really help. They believe that it's possible to hire the "right" people and everything will be great. This is a myth. Instead of expecting your people to be great, you should control their results, by auditing it with an external expert. I'm suggesting you find such an expert in our Telegram chat: https://t.me/zerocracy. There are almost 400 people, most of whom are true experts. Pay them by the hour and you will be impressed by the changes you will see in your project.
The chat is here: https://t.me/zerocracy
The blog post is here: https://www.yegor256.com/2017/11/21/trust-pay-lose.html
The blog post about technical reviews is here: https://www.yegor256.com/2014/12/18/independent-technical-reviews.html
Here a blog post about questions such an auditor must answer: https://www.yegor256.com/2019/04/02/software-project-review-checklist.html
The video is here: https://youtu.be/TxYi7J0vKC8
I created a simple Ruby library just about two weeks ago: https://github.com/yegor256/iri. I already have more than 60 GitHub stars there. How did I do that? I just published it where I usually publish my open source libraries. There is no secret. I just create them, publish and then some of them (!) become popular. You should do the same. Every time you see an opportunity to make a small piece of code open -- do it. And make them small. The smaller your open source products the easier they are to use and the higher the chance that they will be popular.
The video is here: https://youtu.be/jeflGHMpfDc
Most companies and project managers feel proud of spending a lot of money for finding programmers, training them, getting them on board. They tell me very often that programmers are their valuable assets and they don't want to lose them since they invested so much into them. That's a terrible approach, which is only disrespectful to us programmers. We are not your property or your assets. We want to be equal partners with your team. Change your attitude before it's too late.
The video is here: https://youtu.be/UFfJCRhLCZ0
It is a well-known fact that Lines of Code (LoC) is a very inaccurate metric for a software developer. It doesn't demonstrate anything and can't be used to measure the progress of a programmer or a number of efforts the programmer puts into the source code. However, there is another metric called Hits-of-Code (or Code Churn), which is calculated differently and perfectly indicates how much time or efforts the repository required to be created. There is a command line tool of mine, which can help you calculate HoC in your repo. There is also a hosted web service, to do the same.
The video is here: https://youtu.be/hTs_R0dFoFM
Most programmers think that writing code is enough to be useful for a software project. It's not true, especially now, when projects are becoming smaller and teams are more distributed. A modern programmer must understand all the processes and phases of a software development lifecycle. The best way to learn them all, if you ask me, is to study the Rational Unified Process (RUP).
The video is here: https://youtu.be/Af0E8Bn8qcw
Most people ask me why exactly I think it's important for a software developer or an architect to be a blogger and stay active on Twitter, for example. I believe, and most recent practical cases prove that a well-connected and "visible" software architect would bring a lot more value to a project than someone who just knows how to write code.
The video is here: https://youtu.be/l-bM2XyhlkQ
Risk Driven Development is a powerful concept, which may help you prevent many bad things in your project. Unfortunately, many teams don't know how to do it right. I'm going to publish an online tool for that soon, which will be used by Zerocracy and for anyone since it will be free and open source.
The book by Rita Mulcahy: http://amzn.to/266pAYB (you must read it!)
Zerocracy is here: https://www.zerocracy.com
The video is here: https://youtu.be/WlI6IZ6M7vY
Microtasking, in order to work properly, requires a certain amount of discipline. First of all, all tasks and communications about them have to happen in tickets. However, our customers are far from being disciplined enough to use tickets for every requirement they have. Instead, they make phone calls, chat with us online, and send emails. I believe that is the responsibility of an architect to make sure each request that is coming from a client turns into a ticket. If you, as an architect, don't do that, you are doing a very bad favor to the project.
Very often our investors and users ask us why Zold has master nodes, even though it claims to be decentralized and anonymous. I answer that I can't imagine a serious cryptocurrency without a certain amount artificially created master nodes, which help it survive when it is still young. Without them, it will be possible to destroy us easily, just by a majority of hardware, which is not that expensive, while we are young and small.
The video is here: https://youtu.be/kNqKLCWFzbY
Many startup founders think that by sharing equity with programmers or giving them annual bonuses according to the overall result of the company, they can motivate them to work better. This is a wrong idea because programmers can't control those things. They can control the quality of their code, the speed of its delivery, their unit tests, their build pipeline, and other technical things. By rewarding them for things they don't control, the business only demonstrates that it doesn't understand what it is doing.
The video is here: https://youtu.be/MyBbtwKgc9k
Every time someone comes to me for a piece of information, I ask myself: "Why? Isn't this information available in our documentation?" And if the answer is "No," I try to improve the documentation, to make that piece of information visible and accessible, to avoid future requests of the same kind. You should do the same. Don't train anybody, don't teach anybody. Instead, write tutorials. Help yourself and your project.
The video is here: https://youtu.be/QzU2Fbr3xuI
Very often my readers complain about me saying that programmers must be in conflict with testers, or code reviewers in conflict with programmers, and so on. They claim that a good software team must have everybody going along and share the same set of objectives. They say that we should work "together," not against each other. I strongly disagree with that. I believe that good management means organizing conflicts and giving people explicit rules for resolving them. That's how quality can be achieved.
The video is here: https://youtu.be/DUWiy7fvVzk
Being a freelancer and charging $100 per hour, switching projects every few months and living in Bali, sounds like a dream for many programmers. But the question is, how to get there? Where can one get experience and training? Does it seem that the only way to learn to programme is to work somewhere as a full-timer? Yes, why not. Most of you will remain full-timers, but some of you will become freelancers. Those two categories will co-exist on the market.
The video is here: https://youtu.be/sJRM4VWkzSM
Building teams that were supposed to stay together for many years, was a good strategy, many years ago. Not anymore. The reality of the modern software development market demands us to work with remote programmers, who in most cases will be individual contractors or freelancers. They will not be emotionally attached to the team or to the company. They will be looking for the most interesting projects on the market and will quit the moment they will realize that your project is not the one they fit well with. That's why, if you want your business to be ahead of the market, you should start learning how to work with freelancers and how to manage projects. Instead of building teams.
The video is here: https://youtu.be/5GfGXhzQb4Y
The current situation on the software development market it terrible: programmers are spoiled by large salaries and very high demand. They know that their managers can't really do anything with them, can't make them work faster or better, can't fire them, and can't enforce any discipline. Large companies, like Google or Facebook, have the luxury of buying 10 times more programmers than they really need, that's how they solve their productivity problems. However, if you don't have that amount of money, you must not manage your programmers the way Google does it. You need a better management formula. Which one? Microtasking from Zerocracy is one of the options. Use it or invent your own one, but don't copy Google.
The video is here: https://youtu.be/XQQoaBZEs38
When a microtask arrives to you, very often you may need some additional information, which is not specified in the task description. Your first intent would be to go and find that information, even if it's not available. This would be a mistake. You should not spend your time, which is a valuable project resource, on something the management hasn't approved yet. You should create a new ticket/task and ask for additional information. It will be provided and you will be able to continue your main task.
The video is here: https://youtu.be/XYXNOOH8q3M
Most managers and business owners believe that programmers are interested in their ideas, in their business, in their vision. They expect programmers to work because they share a global vision. In reality, it doesn't work that way. Programmers work for their own profit and care about their own personal results. If the business fails to align its objects with personal objectives of its programmers, it will get enemies, not friends.
The video is here: https://youtu.be/TvvSQq_c4X8
The business model of Zerocracy by definition requires a pretty big amount of venture capital in order to connect many programmers with many customers and make them attractive to each other. In order to attract VC money, we have to demonstrate them the traction on the market. Zold is going to help us achieve exactly that, by collecting micro-investments from you and showing bigger money people that the market is interested in us. Help us make Zerocracy bigger, invest in Zold!
The video is here: https://youtu.be/sbONYCd5iUI
Microtasking is a great method of managing programmers, but it's very difficult or almost impossible to switch to this new model of work from traditional full-time management. There is a list of five simple steps I would recommend you making with your team if you want to get yourself ready for microtasking in a few months or a few years. First, make sure the use GitHub. Second, make them report their weekly results in a list of completed tasks. Third, make sure their code gets into the repository via pull requests and only after code reviews. Fourth, invite external reviewers and let them submit their ideas only through tickets. Fifth, let them work remotely, from home.
The video is here: https://youtu.be/0mOn9MvuMzU
What do you do as a customer, when you realize the your architect is totally wrong and the architecture is flawed and you have to start from scratch? Most likely, you got aware of that from one of your friends of the experts you invited to the project. What's next? Replace the architect? Start from scratch? Or continue working with the existing team? My recommendation: never start from scratch.
The video is here: https://youtu.be/RWV6f90eHek
How much would it cost to create a Twitter clone? You won't believe how often I hear this or similar questions. There is no such thing as a realistic estimate of a software price if we are talking about a more or less big product. It starts with a few thousand dollars and ends with a few billion if the product becomes successful on the market. Those who tell you that to develop your app would cost, say, $100,000 are just trying to fool you or they don't understand what they are talking about.
The video is here: https://youtu.be/j5uXrY2gttA
A team of freelancers working in a microtasking mode is not focused on your business objectives, by definition. They are doing what they are willing to do, randomly covering the entire scope of the product's functionality. This is why so many customers get frustrated when they experience this for the first time. In order to avoid this frustration, you should do something, to align technical goals with your business objectives and focus the team on tickets, which are important.
The video is here: https://youtu.be/w3HwEtFU2wo
Very often customers of Zerocracy ask me whether we can find them some good UI/UX designers, who will make sure their application looks great and can work together with programmers. We can't do that because UI people are too artistic and their work has no explicit borders. It's better to find them somewhere else, make sure they are managed and disciplined somehow differently and let programmers integrate their code with their creativity, somehow. How exactly you do that, depends on many technical factors.
The video is here: https://youtu.be/dzepTbcQkgU
Why do startups fail? Conflicts between investors and founders, marketing issues, lack of customer development, not enough money, etc. I believe that all those issues are secondary. The primary cause of problems is the inability to manage programmers right and make sure they deliver what they promise to deliver. Everything else happens as a consequence of the technical incompetence of the software team.
The video is here: https://youtu.be/AwN4emJT0n4
Very often our customers in Zerocracy expect software architects to be very knowledgeable in the tech stack they are going to use in their projects. Even though it doesn't hurt, but this is not what software architects are for. An architect is not going to be the knowledge provider in the project, instead, he or she has to know where to find the right experts, how to engage them, how to motivate them, and how to deal with the information flow they provide and programmers work with. Soft skill is what differ an architect from a regular programmer.
The full video is here: https://youtu.be/_XPonwxsXGI
Many customers, who pay for software development, think that some programming languages are fast, while others are slow and when they need a great/fast/awesome application, they need to use the language some other team has been using before and managed to create some other great application. This is the wrong approach. Instead, when you choose the language pay attention to how it matches your business objectives. Whether your project is going to be alive for a month or a few years, how big will be your team, how much money do you have to hire experts, how disciplined is your management style, etc. Almost any language can create a fast application, but not any language is suitable for disciplined management.
The full video is here: https://youtu.be/Pz256gcyuHs
I've heard it very often that people don't like the word "control" being applied to a group of programmers. They find it abusive, offensive, and de-motivating. I absolutely disagree with this. Control is abusive only if it's implicit, hidden, and not obvious. However, if the rules of work are well defined, accepted by everybody and applied strictly, just like those laws we all know in civil life, control is not abusive at all.
The video is here: https://youtu.be/ezE0hRH9BnQ
Agile, as a software development methodology, was invented by programmers and for programmers, to make things easier for them and to get a perfect excuse when things go south. In Agile the management is not in charge anymore, can't control things, can't really predict anything, and can't blame programmers for mistakes. If you are a programmer, Agile is your perfect shield against most of the problems in the office. If you are a project sponsor, it's your ticket to failure.
The full video is here: https://youtu.be/OOAMNOso46g
In order to isolate your production from the "dirty" master branch, I'm suggesting to use a simple release/delivery model. First, you let everybody commit to the "master" branch, of course, after they pass all unit/integration tests and the entire merge pipeline. Then, you create a candidate branch, which you deploy to the staging environment and let your testers break it as much as they can. Then, when it becomes obvious that testers can't find anything critical there, you the "candidate" branch into the "live" branch and deploy to production, via the deployment pipeline. You may have a number of release candidates, staying in testing simultaneously. This model proved its validity in many projects I've been doing over the last years. If you tried it and there were problems, please let me know in the comments.
Most big websites I work with don't show their error details when something goes wrong. Here is an example: my account with Amazon is in trouble and I see nothing except the "We are sorry" message from them. Instead, I believe, would be much better to show me much more technical information and make me part of the development process. That's what we do in our projects: making our technical defects as much visible for end-users as possible, in order to make them fixed faster.
The video is here: https://youtu.be/t1locjBAXYY
The biggest problem of modern software testing is that neither testers, nor programmers, or their managers understand the role of a software tester. A tester is not someone who confirms that the software works as intended. Instead, a tester is the one who confirms that the software has bugs and who knows how to discover them and document. I will be speaking in JPoint in a month, exactly with this topic. Here is a short rehearsal of my presentation for them. I'm interested in your comments, criticism and suggestions.
The video is here: https://www.youtube.com/watch?v=D5RtdHicCXE
There are many cryptocurrencies on the market, while 99.9% of them are based on the Blockchain architecture, with some modifications. About a year ago we decided to try to create our own solution, which would be a true alternative to Blockchain. It seems that we managed to achieve what we planned and now it's the right time for you to join us and convert your bitcoins to zolds. This is how you will help Zerocracy and will make yourself a profit.
The video is here: https://www.youtube.com/watch?v=5A9uBwMow0M
If I would need to create software for a nuclear power station, who I would work with: freelancers or full-time employees? Of course, the first intent is to get a team of full-timers who we can "trust" and who will care about the business, will be committed to it and will feel personal responsibility. However, this is a very wrong idea. The business will eventually suffer because of lost control. In order to stay in charge of the quality the business should work with people who care mostly about themselves. Freelancers are exactly that type of people. If you manage to deal with them and keep them under control, your business will be strong and successful.
The full video is here: https://www.youtube.com/watch?v=12SEpsOH7CE
Very often this question is asked: how Zerocracy can be compared with Upwork and similar platforms for freelancers. Long story short, we are not competitors and can't be compared directly. Upwork provides unmanaged teams of freelancers, while Zerocracy turn them into managed teams. You may and should find freelancers in Upwork and then come to Zerocracy and let your team work under the management of our AI and according to our policy of work. Hope this helps.
The full video is here: https://www.youtube.com/watch?v=A6AC2Tgyhzs
When your objective is to put programmers together in one office and make them look like hard working slaves, spending the money of your investors, you definitely need full-timers, with good salaries and benefits. However, if you need to achieve results, and you know how to manage programmers, you need freelancers, who work for results, for money, and for themselves. You don't mix those two categories, they are absolutely different. And you don't apply the same selection criteria to those two groups.
The video is here: https://www.youtube.com/watch?v=hDsy-D5zaVs
Changing jobs frequently is usually considered to be a sin for a professional programmer. Recruiters don't like that and to leave just a few places in the resume, to look more "loyal." However, this is not true for freelancers, who by definition change projects frequently. That's why their resumes have to look very different and recruiters and project managers have to be ready to read them differently.
The full video is here: https://www.youtube.com/watch?v=31xOLs-DqTo
Being a senior developer doesn't mean getting a large salary or being appreciated in the office. It means belonging to an elite group of developers who know how to do certain things and can do them. If you want to be senior, think again about open source contribution, about StackOverflow participation, about conferences and certifications. Without that, you are just yet another programmer, one of a million.
The full video is here: https://youtu.be/Y_IUzt-Oyww
Most software teams interview programmers before getting them on board. Later they get surprised how was it possible to hire someone who doesn't understand programming. Those so-called "fake interviews" would not exist if we would let the market vouch for programmers, instead of us relying on the information we manage to collect at those Skype calls. We, in Zerocracy, pay attention to five things that are important: 1) GitHub reputation, 2) Stackoverflow history, 3) certifications, 3) conferences, 4) blogging experience. Once a programmer has all of those, we know that he/she is senior enough for us.
The full video is here: https://www.youtube.com/watch?v=gVs9NKSlOVc
The first thing you should worry about when you start a software project is how your product can be delivered to end-users in an automated way. Right after you managed to create a skeleton and make it "work on your laptop," start configuring the deployment pipeline. Only after it's done, demonstrate your product to your testers, partners, investors, customers, etc. Don't tell them that your product is in GitHub and if they want they can check it out themselves. This is very unprofessional. Make sure they can touch the product where its end-users will see it when it's fully ready for the market launch.
The full video is here: https://www.youtube.com/watch?v=p-Hv-TC0JHc
I'm being asked about English speaking skills very often, that's why this video. You want to improve? Here is hot-list: 1) read English books; 2) watch movies in English, with subtitles; 3) find someone to chat with online, not about work; 4) go to the United States of America and stay there for a few months; 5) make lectures or presentations in English; 6) write in English, like blog post or anything that someone else will have to read. This is what helps me to practice and not to be afraid of speaking English.
The full video is here: https://www.youtube.com/watch?v=6de0RNdIIFk
Quality management, if I understand PMBOK and ISO-9001 correctly, is all about the Plan-Do-Check-Act cycle, where we 1) plan what quality objectives are important for us and how they can be numbered, 2) let the team produce the results, 3) collect the numbers, and 4) compare them with our expectations and take corrective and preventive actions. In order to make this all happen, you need to turn your human resources in numbers. How do you do that in your software team, depends on many factors. But software business is the easiest one for that: most of our activities are easy to measure.
The entire video is here: https://www.youtube.com/watch?v=euEOroFEHWM
Meetings are a great solution for lazy, immature, stupid, and non-professional software developers, architects, and their managers. The more you grow, the more professional you become, the bigger will be your frustration from those meetings. What is the alternative? How can we make technical decisions without sitting together in a room and talking? The alternative is a strict and disciplined process of decision making, which has to be based on ... guess what ... microtasking.
The full video is here: https://www.youtube.com/watch?v=KUUzUb9arNg
When you are ready to delegate your software project to Zerocracy, you will need an architect, who will guide you through the bootstrap steps, will understand the requirements, will build the team of freelancers, and will supervise it, with the help of Zerocrat, our AI-powered chatbot. To find that architect you have to submit a Request-for-Proposal (RfP), which will be "purchased" by one of the most active and reputable programmers and you will get a chance to discuss your project with him or her. Then, if you both like each other, the project will start and you will be the Product Owner and requirements provider. If not, you will have to try again or ask help in our Telegram chat.
The full video is here: https://www.youtube.com/watch?v=QsxwHdKoWEI
It happens very often: the requirements we have to work with are not clear. Customers, requirements providers, product owners, managers, architects, and other programmers are simply too lazy to specify them right and they just drop those feature requests and bugs on our heads. We have to deal with them. The most enthusiastic of us dive into those unclear problem descriptions and attempt to clear things our on their our, attempt "to figure it out themselves." This is a very unprofessional behavior. Instead, you should always try to push back those requirements providers and make sure the requirements you work with are unambiguous, clear, and easy to understand.
The full video is here: https://www.youtube.com/watch?v=z59jkRAeBDg
You remember my recommendations for a programmer if the management is weak and stupid, right? Don't be loyal. Instead, use their resources for your own good. But what do you do if you are the architect and the tech lead of the project? In that case, the situation is more complicated, but it's solvable. You just need to be more careful, here is how.
The full video is here: https://www.youtube.com/watch?v=_Y2lZsRLwlk
Very often startup founders and CTOs are asking me how and whether it's possible to transition from traditional full-time management to pay-by-result and microtasking, which we practice in Zerocracy. My answer is that it's possible but expensive. It will take time, money, and nerves. Here is a short summary of why it will be so difficult and why you should use Zerocracy instead.
The full video is here: https://www.youtube.com/watch?v=dAgRUtR3LQg
Multitasking is something only senior developers can deal with, because it's stressful, results-focused, and demands a lot of skills, which junior developers simply don't have. However, the question is: What those junior developers should do? How they can contribute to the project? There is a number of possible ways.
The full video is here: https://www.youtube.com/watch?v=6OHfh36zLsk
I know so many testers who think that they are QA engineers. They are so wrong that I decided to record a video about that. Testing is about breaking the software and finding bugs. QA is about watching the entire software development process and improving its quality indicators. They are two absolutely different activities.
The full video is here: https://www.youtube.com/watch?v=hp4PL0AJAVo
Proper management is very rare, happens only in some companies. Others are treating people like office slaves, expecting them to do stay in the office instead of delivering results. What do you do when you happen to be hired by such a company? How do you change it? How can you improve your team and motivate your management to shift to better management practices, like microtasking, paying by result, etc? You can't! And you shouldn't even try.
The full video is here: https://www.youtube.com/watch?v=Op3EIwhMxrg
Do you know what micromanagement is? It's when your manager is telling you exactly what you have to do right now in order to achieve the results he or she wants. The micromanager doesn't trust you and that's why wants and needs to control every step you make. It's annoying and unproductive, but it's inevitable unless you have small tasks and a transparent and unambiguous system of rewards and punishment.
The full video is here: https://youtu.be/0Jte_LGR5Zk
The average salary of american workers is growing 1% every year, while the paygap between similar jobs is decreasing. What do I think about this trend? Does it sound like people are getting more every year and it's good? Not at all. This trend is completely against what Zerocracy is fighting for: unequal pay for unequal contribution. We want to work with free people, who get what they deserve because of their work, not because of their place in the company. Meritocracy is yet another name for the movement we are leading now in the industry of software development.
The full video is here: https://www.youtube.com/watch?v=mKZOuJ7AAas
In order to do the project right, you need the right person, right? Wrong! This type of thinking doesn't help at all and only leads to failures. It's the management that needs to be "right," not its people. Watch this morning video about this problem: https://www.youtube.com/watch?v=SSZnloEHeOk
Microtasking is a great management method, provided you can break your larger scope into smaller micro-tasks. Who should do this decomposition and how much time will work by itself will take? This question I hear very often when we start talking about paying-by-results and microtasking. We've spent a few years to find the answer and the methodology invented was called Puzzle Driven Development, here is how it works (the full video is there): https://www.youtube.com/watch?v=LmSaC_OjIbQ
You know how much I love microtasking and paying-by-result, but you may wonder how can we estimate the future of our projects if we deal with very small pieces of work. I made an attempt to explain it in the video. Long story short, microtasks not only make estimation easier for computers, but ensure much higher accuracy and preciseness of the result.
The full video is here: https://www.youtube.com/watch?v=1rmZN3r5SWg
How do you protect your business ideas from potential theft by your own programmers? Do you sign NDAs? Do you hire only those who won't steal? Well, I believe you should do the opposite. Don't be scared of theft, just be prepared to prove that the idea was originally yours and share their success, when and if they get it.
The full video is here: https://www.youtube.com/watch?v=H56jeG_Xi64
I've got a meeting with a potential investor a few days ago, which asked me to help him develop some software, in order to prove that Zerocracy is an investable business. I refused and here is the explanation of my logic.
The full video is here: https://www.youtube.com/watch?v=F3eRSRt-zDY
We claim that Zerocracy is an AI bot that is capable of managing people better than a human being. But very often I hear questions: How is it possible to make a computer so smart? Is AI so powerful already? In this morning video I ask you a question: Do you know what AI is? What exactly is happening in that "thinking" machines? Do they really "think" as you expect them to? No, they don't. Just like Zerocracy chatbot doesn't really think, but only does what its algorithms are designed to do. There are no thinking machines in the world, as of yet. And they won't show up in the near future.
The full video is here: https://www.youtube.com/watch?v=XBZcVHc0LNE
If you need to demonstrate your investors that your software team is working hard on something great, you need a group of junior developers — they are easy to manage and are afraid of going into conflicts. On the other hand, if you need to develop a great product, you need senior developers. However, they are difficult to manage because they prefer to work for themselves, not for you and your project. Will you be able to manage them?
The full video is here: https://www.youtube.com/watch?v=SdrtZIW5JtY
I was asked to explain what Zerocracy is doing exactly, but a potential client of ours. Here is what I managed to create, in just 15 minutes (I wanted to do five, but didn't manage). The bottom line is that full-time hiring and outsourcing are two great recipes for disaster, for a young startup. To the contrary, Zerocracy is a life saver.
The full video is here: https://www.youtube.com/watch?v=GozQCUH2D0I
Very often I hear people saying that microtasking is only suitable for junior developers, who are ready to work like "coding monkeys", while professional senior programmers can't do that. That's a mistake. Junior developer simply can't do microtasking, because it's stressful and complex. It's something that only experienced programmers can do right and make money out of it.
The video is here: https://www.youtube.com/watch?v=1pHUx-ISrS8
18 December 2017; please post your comments here: www.yegor256.com/shift-m/2017/19.html
20 November 2017; please post your comments here: www.yegor256.com/shift-m/2017/15.html
19 June 2017; please post your comments here: http://www.yegor256.com/podcast/2017/3.html
BDMSummit 2017; 17 June 2017; Kiev, Ukraine; video is here: https://youtu.be/oiNI2jF46h0
PMCon 2017; 11 June 2017; Kharkiv, Ukraine; video is here: https://www.youtube.com/watch?v=Rip_04Bv3Jk
12 June 2017; please post your comments here: http://www.yegor256.com/podcast/2017/2.html
5 June 2017; please post your comments here: http://www.yegor256.com/podcast/2017/1.html
JEEConf 2017; Kyiv, Ukraine; 26 May 2017; video is here: https://www.youtube.com/watch?v=GS45LzE3LPQ
Kyiv Outsourcing Forum 2017; Kyiv, Ukraine; 26 May 2017; video is here: https://www.youtube.com/watch?v=DLk_5BmgTVk
RigaDevDays 2017; 15 May 2017; Riga, Latvia; video is here: https://www.youtube.com/watch?v=K_QEOtYVQ7A
DevOn Summit 2017; Delft, The Netherlands; 30 March 2017; video is here: https://www.youtube.com/watch?v=MSBf2RftCKo
DevTernity 2016; Riga, Latvia; 1 December 2016; video is here: https://www.youtube.com/watch?v=7EytYc7K5JA
Webinar #19; 7 December 2016; video is here: https://www.youtube.com/watch?v=zaKTNK8g2-M
BuildStuff Kiev 2016; Kiev, Ukraine; 22 November 2016; video is here: https://www.youtube.com/watch?v=R1lA7pN60xg
Build Stuff 2016; Vilnius, Lithuania; 18 November 2016; video is here: https://youtu.be/wd-SA1HVmLg
TopConf Tallinn 2016; Tallinn, Estonia; 17 November 2016; video is here: https://www.youtube.com/watch?v=mq4bsnKK0qs
XPDays Kiev, 2016; Kiev, Ukraine; 12 November 2016. Video is here: https://www.youtube.com/watch?v=tCr9dtGdi2c
Software architect is responsible for failures. Software is powerful enough to make and overrule any decision. But that's not it. We will also talk about delegation of responsibility and micromanagement.
WebIT.Festival; Sofia, Bulgaria; 20 April 2016. Original blog post is here: http://www.yegor256.com/2014/10/08/continuous-integration-is-dead.html
We discussed how to turn chaos into a disciplined software development. The discussion will be based on these articles: http://www.yegor256.com/2015/01/15/how-to-cut-corners.html and http://www.yegor256.com/2015/02/16/it-is-not-a-school.html
Getters are evil in OOP, but what is the alternative? Printers is the way to go. The discussion is based on this article: http://www.yegor256.com/2016/04/05/printers-instead-of-getters.html Video is here: https://www.youtube.com/watch?v=_Q0cNykXB04
We discussed what bugs were for, how they must be understood by the management, how many of them we should expect to find and what is in general the right philosophy of bug tracking.