yegor256 podcast

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