yegor256 podcast

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/SuAM9J2cTDo

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/CmUzNPqCF4s

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