yegor256 podcast

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