yegor256 podcast

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 fr...

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/lgScA...

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...

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 h...

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...

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...

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 w...

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. T...

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/A59xGY...

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...

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://you...