yegor256 podcast

Latest Episodes:

M141: Lines of Code is a good metric if your management is perfect, otherwise it will hurt Nov 05, 2020

Show notes

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

M140: Morning stand-ups are evil, use other management instruments instead Nov 02, 2020

Show notes

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

M139: It seems that better programmers write more lines of code Oct 29, 2020

Show notes

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

M138: Morning stand-ups are nothing else but guilt-triggers Oct 26, 2020

Show notes

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

M137: Don't ask your programmers to estimate, tell them how much you have Oct 22, 2020

Show notes

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

M136: Any software product has an unlimited number of bugs Oct 19, 2020

Show notes

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

M135: Don't ask for approval, educate them so that they make the decision themselves Oct 15, 2020

Show notes

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

M134: Don't blame the situation for the mess in the code, it's only your fault Oct 12, 2020

Show notes

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

M132: Your pet projects are the best contribution to your resume Oct 05, 2020

Show notes

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

M131: Be aware of conflict-of-interest concerns when you open source while being employed Sep 28, 2020

Show notes

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

Our TOPPODCAST Picks

Follow Us

Stay Connected

Related Podcasts

Links

Stay Connected