Shows
yegor256 podcastF68: Наказания для Кодеров | ООП | MBA | Инфоцыгане | Zerocracy | Павка КорчагинF68: Наказания для Кодеров | ООП | MBA | Инфоцыгане | Zerocracy | Павка Корчагин by Yegor Bugayenko2025-05-311h 19yegor256 podcastF67: Java | Agil | CI/CD | MCP | зарплаты | софт скиллы | левые взгляды | справедливостьF67: Java | Agil | CI/CD | MCP | зарплаты | софт скиллы | левые взгляды | справедливость by Yegor Bugayenko2025-05-251h 03
yegor256 podcastF66: Децентрализация | Guy Ritchie | Aibolit | Ruby on Rails | Работа в Яндекс | Билл ГейтсF66: Децентрализация | Guy Ritchie | Aibolit | Ruby on Rails | Работа в Яндекс | Билл Гейтс by Yegor Bugayenko2025-05-161h 02
yegor256 podcastИ33: Вадим Петроченков | Как создается язык RustИ33: Вадим Петроченков | Как создается язык Rust by Yegor Bugayenko2025-05-1251 min
yegor256 podcastF59: Friday Q&A about programming and managementF59: Friday Q&A about programming and management by Yegor Bugayenko2025-02-281h 02
yegor256 podcastИ27: И. В. Аржанцев | ФКН ВШЭ, ICPC, стартапы, студенты, аспирантура, JetBrains, Yandex, MITИ27: И. В. Аржанцев | ФКН ВШЭ, ICPC, стартапы, студенты, аспирантура, JetBrains, Yandex, MIT by Yegor Bugayenko2024-09-031h 15
yegor256 podcastИ26: В. А. Петров | математика, СПбГУ, R&D, наука в Китае, аспирантура не для всехИ26: В. А. Петров | математика, СПбГУ, R&D, наука в Китае, аспирантура не для всех by Yegor Bugayenko2024-08-201h 02
yegor256 podcastM129: Niche narrow-skilled developers will earn more than others"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/-WpBUrOxoDI2020-09-2105 min
yegor256 podcastM128: Don't quit failing projects, quit those that fail youI 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/wQwZPOzN2gI2020-09-1405 min
yegor256 podcastM127: The ability to explain a problem so that it's understood is the most important soft skillMost 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_Jorc5z42020-09-1004 min
yegor256 podcastM126: Use open source projects to build yourself a support groupOne 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_yNLtc2020-09-0704 min
yegor256 podcastВыступление перед студентами ВШЭ1-го сентября 2020 года мне повезло выступить перед 200+ студентами Факультета Компьютерных Наук (ФКН) Высшей Школы Экономики (ВШЭ) в Москве, по случаю начала нового учебного года.
Видео здесь: https://youtu.be/Ly9u_ZAZFCk2020-09-0442 min
yegor256 podcastM125: When you contribute to your project altruistically, you are killing itYou 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-aGY2020-09-0306 min
yegor256 podcastM124: Put your talent away and learn new skills when working in an enterpriseBeing 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...2020-08-3106 min
yegor256 podcastM123: One README should be enough for any open source projectSome 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/Qxvk9z0tEP82020-08-2705 min
yegor256 podcastM122: Don't help them, instead use their free contribution to improve the productWhen 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/tI6rGQIevxU2020-08-2406 min
yegor256 podcastM121: Don't be frustrated by the enterprise chaos around you, conquer it!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/SuAM9J2cTDo2020-08-2005 min
yegor256 podcastM120: Don't wait for your manager to tell you what to do, do what you think is right (open source)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/CmUzNPqCF4s2020-08-1705 min
yegor256 podcastM118: Deploy your ready-to-use open source artifacts into immutable repositoriesHaving 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-U8fsrE2020-08-1005 min
yegor256 podcastM117: Breaking responsibility down is the responsibility of a manager/architectWhen 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/kPTKT3jOG7c2020-08-0604 min
yegor256 podcastM116: Which license to use for an open source product?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_nGDls2020-08-0305 min
yegor256 podcastM115: Going along with large open source projects is a perfect strategy for newbiesThere 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/IeoYXstRvzw2020-07-3006 min
yegor256 podcastM114: The performance of programmers can be measured, with the right metricsMost 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...2020-07-2705 min
yegor256 podcastM112: Put as much as possible on GitHub, no matter what it isGitHub 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/xFXW5j2x7XI2020-07-2006 min
yegor256 podcastM111: Use open source projects to beat the boresome of the office workWe 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/qJxDV1TrEGE2020-07-1605 min
yegor256 podcastM110: Professional developers enjoy being punished by static analyzersA 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/7rtQ4yQVAK02020-07-1303 min
yegor256 podcastM109: Open your sources piece by piece, not all at onceIf 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/VuJNBXPnRy82020-07-0902 min
yegor256 podcastM108: Your job is to prepare your open source project for the future communityYour 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/kV5j4Uysivo2020-07-0604 min
yegor256 podcastM107: Make your GitHub project look attractive and contributors will comeThe 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_U2020-07-0204 min
yegor256 podcastM106: Very soon all important software projects will open their sourcesIt 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/JBdtSAJjFaU2020-06-2905 min
yegor256 podcastM105: Open source developers inevitably have better soft and tech skillsOpen 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/D12gi1x6Cdw2020-06-2306 min
programmier.bar – der Podcast für App- und WebentwicklungFolge 46 - Testing – ein ÜberblickSoftware-Testing ist ein wesentlicher Bestandteil, wenn es um die Umsetzung eines Programmier-Projekts geht. Doch wie soll man den Durchblick behalten und wissen, was die richtige Methode für das eigene Vorhaben ist? Und wie wichtig ist Testing eigentlich?Bei der programmier.bar geht es munter weiter und wir geben euch in der ersten Folge des neuen Jahres einen Überblick zu verschiedenen Methoden des Software-Testings. Wir unterteilen hier in funktionale (Unit- und Device-Testing, Akzeptanz-, Integrations-, System- und Smoke Tests) sowie nicht-funktionale Tests (Last-, Performance-, A/B-, User- und Monkey-Tests, Apache Bench und eigene Herangehensweisen). Während wir von unseren Erf...2020-01-101h 00
yegor256 podcastShift-M/42: self-development with Venkat SubramaniamVenkat 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.2019-12-101h 03
yegor256 podcastM104: Refactoring without a ticket means stealing project resourcesWhen 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/PkmVF64mZNo2019-11-1100 min
yegor256 podcastM102: Zerocracy may look like utopia for you now, but eventually you will be thereVery 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-pSFswUI2019-07-1206 min
yegor256 podcastM100: Tech audits help you identify the gaps between your code base and industry standadsIndependent 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/jzMZaC54nbc2019-07-0808 min
yegor256 podcastM98: If you think that your team is doing fine, you are a bad managerMost 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-g4nGk2019-06-2805 min
yegor256 podcastM97: Let your followers be your best censors helping you think more logicalThere 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...2019-06-2605 min
yegor256 podcastM96: Freelancers are a pain, but they are your only hope if you want the quality to go upMost 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...2019-06-2406 min
yegor256 podcastM95: Only lazy and immature programmers are afraid of penalties and punishmentVery 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/PlvoXBgwooY2019-06-2006 min
yegor256 podcastM94: It is impossible to make a full-timer deliver results, unless they want itOur 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...2019-06-2006 min
yegor256 podcastM93: To become a good programmer you have to find a project that rejects your mistakesJunior 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/dCn53X1I2R02019-06-1705 min
yegor256 podcastM92: We in Zerocracy use Boost Factor to help architect motivate programmersSometimes 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_w2019-06-1205 min
yegor256 podcastM91: Full-timers want to look smart, freelancers want to deliver resultsMost 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/_4pk5GNUySg2019-06-1104 min
yegor256 podcastM89: Deliver your trust continuously, not discreteMost 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/KPbKqTXfZwA2019-05-3105 min
yegor256 podcastM90: RUP is a framework, Agile is a philosophy; just like Zerocracy and XDSDI 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.2019-05-3107 min
yegor256 podcastM88: If you are working on a prototype for longer than two weeks, you are doing it wrongTechnical 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...2019-05-2805 min
yegor256 podcastM87: If you are afraid of being replaced, you are not a good programmerMost 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...2019-05-2705 min
yegor256 podcastM86: The README file must be the only provider of product specificationI 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/1zCH0xBiCP42019-05-2204 min
yegor256 podcastM85: The source code is just a part of a software project, not the biggest oneWe 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/keGVpncTn4Q2019-05-2005 min
yegor256 podcastM84: Don't chase your team members, make them chase youThe 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/4j4Kddo5Xgw2019-05-1607 min
yegor256 podcastM83: Strong opinions loosely held is not a problem, the absence of an architect isA 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.2019-05-1306 min
yegor256 podcastM82: Is it possible to open the entire source code base and still make business? Definitely.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.
...2019-05-1006 min
yegor256 podcastM81: How to make your GitHub repo popular? Eight things to pay attention to.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...2019-05-0813 min
yegor256 podcastM80: Every two weeks you should hire a new auditor to review your software projectVery 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...2019-05-0605 min
yegor256 podcastM79: Make as many open source libraries as possible, eventually one of them will become a successI 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...2019-05-0304 min
yegor256 podcastM78: Programmers are not your property, don't invest in them!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/UFfJCRhLCZ02019-05-0207 min
yegor256 podcastM77: Lines-of-Code don't show anything meaningful, but Hits-of-Code are pretty accurateIt 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...2019-05-0105 min
yegor256 podcastM76: Learn Rational Unified Process to understand SDLC betterMost 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/Af0E8Bn8qcw2019-04-2905 min
yegor256 podcastM75: Your presence in social networks is important for your career as a software architectMost 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-bM2XyhlkQ2019-04-2204 min
yegor256 podcastM74: If your project doesn't have a formal Risk List, you are doing management wrongRisk 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/WlI6IZ6M7vY2019-04-1805 min
yegor256 podcastM73: It is your job, as an architect, to convert client's requirements into ticketsMicrotasking, 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.2019-04-1603 min
yegor256 podcastM72: Zold, like any other young cryptocurrency, needs master nodes to surviveVery 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/kNqKLCWFzbY2019-04-1503 min
yegor256 podcastM71: Motivating programmers by equity or profit sharing is a bad idea, it doesn't workMany 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/MyBbtwKgc9k2019-04-1202 min
yegor256 podcastM69: Write tutorials instead of training and teachingEvery 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/QzU2Fbr3xuI2019-04-1002 min
yegor256 podcastM70: A software team without conflicts can't produce anything of a good qualityVery 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/DUWiy7fvVzk2019-04-0905 min
yegor256 podcastM68: Is it necessary to be a full-timer first, in order to become a freelancer? Yes, why not!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/sJRM4VWkzSM2019-04-0903 min
yegor256 podcastM67: The future of software development has no offices and no companies, only projectsBuilding 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...2019-04-0808 min
yegor256 podcastM66: If you will manage programmers the way Google does it, you will loseThe 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...2019-04-0505 min
yegor256 podcastM65: If you need to learn the code around your microtask, don't do it! Create a new ticket.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/XYXNOOH8q3M2019-04-0405 min
yegor256 podcastM64: You want your programmers to be your enemies? Pay them monthly.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_c4X82019-04-0206 min
yegor256 podcastM63: The growth of Zold rate is direct marketing expenses of ZerocracyThe 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/sbONYCd5iUI2019-03-2906 min
yegor256 podcastM62: Five steps to migrate from traditional management to microtaskingMicrotasking 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...2019-03-2809 min
yegor256 podcastM61: What do you do when a client says that everything is wrong and has to be done from scratch?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/RWV6f90eHek2019-03-2709 min
yegor256 podcastM60: Ask a software team for a quote only to check whether they refuse to provide itHow 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...2019-03-2605 min
yegor256 podcastM59: How to not get frustrated when dealing with freelancers and microtasking?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/w3HwEtFU2wo2019-03-2507 min
yegor256 podcastM58: Don't expect UI/UX people to work in microtasking mode, they are too creative for thatVery 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/dzepTbcQkgU2019-03-2205 min
yegor256 podcastM57: Tech startups fail mostly because of software development incompetenceWhy 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/AwN4emJT0n42019-03-2107 min
yegor256 podcastM56: Don't expect your architect to be an expert in your tech stack, that's what developers are forVery 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...2019-03-2005 min
yegor256 podcastM55: The programming language you choose must match your project business objectivesMany 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...2019-03-1907 min
yegor256 podcastM54: Make sure you control your programmers and do it explicitly and openlyI'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/ezE0hRH9BnQ2019-03-1804 min
yegor256 podcastM53: What do I think about Agile? It's a recipe for disaster, if you are a project sponsor.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/OOAMNOso46g2019-03-1504 min
yegor256 podcastM52: Three-branches release model: Master, Release Candidate, LiveIn 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...2019-03-1410 min
yegor256 podcastM51: Don't hide error stacktraces, make end-users part of your quality control instead!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/t1locjBAXYY2019-03-1205 min
yegor256 podcastM50: Testing is the process of confirming that the software has defects (JPoint talk rehearsing)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=D5...2019-03-1114 min
yegor256 podcastM49: Zold is an experimental non-Blockchain cryptocurrency, made by ZerocracyThere 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=5A9uBwMow0M2019-03-0707 min
yegor256 podcastM48: If you depend on your programmers, you are a bad architect!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...2019-03-0606 min
yegor256 podcastM47: What is the difference between Zerocracy and Upwork? We are not competitors!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=A6AC2Tgyhzs2019-03-0505 min
yegor256 podcastM46: Freelancers and full-times are like oil and water, don't mix them, they are not friendsWhen 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-D5zaVs2019-03-0406 min
yegor256 podcastM45: Freelancers and full-timers have very different resumes, don't expect them to look similarChanging 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-DqTo2019-03-0109 min
yegor256 podcastM44: What do you think you are a senior developer? Who says so? Think again.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-Oyww2019-02-2807 min
yegor256 podcastM43: Technical interviews are pointless, pay attention to these five things instead!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...2019-02-2706 min
yegor256 podcastM42: Make sure your software is deployable from the first day!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...2019-02-2503 min
The Art Of ProgrammingВыпуск №173 — The Art Of Programming [ DevOpsConfRussia ] Главное не качество, а количествоЕгор Бугаенко в кругу подкастеров на конференции DevOpsConfRussia 2018
Главное не качество, а количество
Fear driven development — нанимать лучших, тренировать, мотивировать, наказывать, увольнять
Code Ahead by Yegor Bugayenko https://www.amazon.com/dp/1982063742
Zerocracy https://www.zerocracy.com
Zerocracy Policy https://www.zerocracy.com/policy.html
Благодарности патронам:
Aleksandr Kiriushin, B7W, BigB, Eduard Matveev, Fedor Rusak, Grigori Pivovar, Konstantin Kovrizhnykh, Konstantin Petrov, Lagunovsky Ivan, Leo Kapanen, Mikhail Gaidamaka, Neikist, nikaburu, Pavel Drabushevich, Pavel Sitnikov, Sergey Kiselev, Sergey Vinyarsky, Sergii Zhuk, Vasiliy Galkin, Евгений Власов, Никита Ложников, Сёмочкин Максим
Поддержи подкаст http://bit.ly/TAOPpatron
Подпишись в iTunes http://bit.ly/TAOPiTunes
Подпишись без iTunes http://bit.ly/TAOPrss
Скачай подкаст http://bit.ly/TAOP173mp3
Старые выпуски http://bit.ly/oldtaop
2018-10-081h 06
Devskiller's Yellow Duck PodcastA Conversation about Software Development with Yegor BugayenkoYegor Bugayenko is a professional Java engineer and project manager with certifications in PMP®, RUP, PRINCE2 Foundation, MCP, and COSMIC. He’s an author, blogger, avid Twitter user boasting 12,000 followers. In this conversation he'll discuss a variety of topics including managing software engineers, project management, how to select the best engineers and more.2018-08-2200 min
The Collaboration Superpowers Podcast170 - From The Archives: Extreme Results Oriented Working With Yegor Bugayenko Teamed.io develops software in an "extremely" distributed mode. They have no central office, no meetings, no conference, calls, and no Skype chats. They work through task management systems and call it: "Team as a service". I interview Yegor, Founder and CTO, about this unique way of working! For more stories, visit www.CollaborationSuperpowers.com. 2017-11-2745 min
The Art Of ProgrammingВыпуск №135 — The Art Of Programming [ Drinking ] Аннотации злоArtifactory и Conan.io
Впечатления от jPoint
Cory HouseFollow — Why I Stopped Using Multiple Monitors. A Single Monitor Manifesto // http://bit.ly/TAOP135mon
Рабочий стол Баруха // http://bit.ly/TAOP135b
Yegor Bugayenko — Java Annotations Are Evil (in Russian) // http://bit.ly/TAOP135aae
Yegor Bugayenko — Elegant Objects // http://bit.ly/TAOP134eo
Максим Дорофеев — «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» // http://bit.ly/TastyBooks61shared
Новые патроны: Евгений Власов, Vasiliy Galkin, Grigori Pivovar, Yakov
Благодарности патронам: Sergey Kiselev, Sergey Petrov, Sergey Vinyarsky, Bogdan Storozhuk, Aleksandr Kiriushin, Sergii Zhuk, Pavel Sitnikov, Yakov Krainov, Lagunovsky Ivan, Konstantin Kovrizhnykh, Евгений Власов, Vasiliy Galkin, Grigori Pivovar, Nikolay Ushmodin, Pavel Drobushevich, Yakov, B7W
Поддержи подкаст http://bit.ly/TAOPpatron
Подпишись в iTunes http://bit.ly/TAOPiTunes
Подпишись без iTunes http://bit.ly/TAOPrss
Скачай подкаст http://bit.ly/TAOP135mp3
Старые выпуски http2017-04-1245 min
The Art Of ProgrammingВыпуск №134 — The Art Of Programming [ Book ] Долой экспертовФоточки CodeFest 2017 http://bit.ly/TAOP134cf
Уже идёт JBreak https://2017.jbreak.ru
Последний шанс на JPoint https://jpoint.ru
Yegor Bugayenko — Elegant Objects // http://bit.ly/TAOP134eo
Yegor Bugayenko — Get Rid of Experts, AgileDays 2017 // http://bit.ly/TAOP134groe
Максим Дорофеев — «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» // http://bit.ly/TastyBooks61shared
Galaxy S8 // http://bit.ly/TAOP134gs8
Jeff Barr — Amazon Connect – Customer Contact Center in the Cloud // http://bit.ly/TAOP134ac
Salesforce Announces Service Cloud Einstein and Amazon Connect Integration // http://bit.ly/TAOP134sf
Magnet http://magnet.crowdcafe.com
Spectacle https://www.spectacleapp.com
Moom https://itunes.apple.com/us/app/id419330170
Amethyst http://ianyh.com/amethyst/
Благодарности патронам: Sergey Kiselev, Sergey Petrov...2017-04-0445 min
yegor256 podcastJava vs OOP (JavaDay Kyiv 2016)Java vs OOP (JavaDay Kyiv 2016) by Yegor Bugayenko2016-10-1552 minThe Collaboration Superpowers Podcast8 - Extreme Results Oriented Working (Yegor Bugayenko)Teamed.io develops software in an "extremely" distributed mode. They have no central office, no meetings, no conference, calls, and no Skype chats. They work through task management systems and call it: "Team as a service". I interview Yegor Bugayenko, Founder and CTO, about this unique way of working! For more stories, visit www.collaborationsuperpowers.com.2014-11-1045 min