We started reviewing software projects of other companies, just a few weeks ago and our first finding is that programmers don't pay attention to anything aside from the code they write. They don't have build automation, unit testing, static analysis, continuous integration, test coverage control, database versioning, and many other things which are supposed to keep the code together. It seems that this is happening because of the lack of knowledge and experience.

The video is here: https://youtu.be/keGVpncTn4Q

The job of a good project manager is to organize the team the way that every team member wants to contribute and is ready to go through all possible obstacles and barriers, in order to make sure their results are accepted by the project. If the project manager has to chase programmers, ask them, beg them, and pull results from them, it is a bad project manager and the project is mis-configured.

The video is here: https://youtu.be/4j4Kddo5Xgw

A software team where everybody expresses their opinions loudly and strongly, always being ready to admit that "I was wrong," is not able to produce anything serious. This is what I read in one blog post recently. And I do agree with this. However, I disagree with the solution suggested in the blog post. The author suggests programmers be more humble and skeptical, which I believe will only lead to more compromises. We know that compromises are bad for quality. My solution is to have a formally assigned architect, who makes all final technical decisions.

When I start talking about 100% open source business model, most people wonder how is it possible to give away the entire source code base and still remain profitable, money wise. I think that any modern digital business has three components of success: the source code, the database, and the community of users, programmers, clients, and so on. If you make your source code fully open, you will only help your other two components (data and community) to grow. In Zerocracy and all our satellite projects, we rely on this business model. We open the code and invest in the community.

The video is here: https://youtu.be/4-7fth8Iku8

Do you want to be known in the open source world? If you don't, don't watch this video. If you do, there are eight things you should pay attention to when making a new GitHub repo: 1) make it small, 2) don't depend on other libraries, 3) make your README sexy, 4) write up a complete documentation, 5) ask everybody around to give you GitHub stars, 6) release it, 7) configure continuous integration, 8) communicate with your users via issues and pull requests. You can see how I do it in my libraries, in my GitHub account: https://github.com/yegor256

The video is here: https://youtu.be/vhOg-7uPbvA

Very often software project sponsors complain about the low quality of their programmers. They also say that changing the team doesn't really help. They believe that it's possible to hire the "right" people and everything will be great. This is a myth. Instead of expecting your people to be great, you should control their results, by auditing it with an external expert. I'm suggesting you find such an expert in our Telegram chat: https://t.me/zerocracy. There are almost 400 people, most of whom are true experts. Pay them by the hour and you will be impressed by the changes you will see in your project.

The chat is here: https://t.me/zerocracy

The blog post is here: https://www.yegor256.com/2017/11/21/trust-pay-lose.html

The blog post about technical reviews is here: https://www.yegor256.com/2014/12/18/independent-technical-reviews.html

Here a blog post about questions such an auditor must answer: https://www.yegor256.com/2019/04/02/software-project-review-checklist.html

The video is here: https://youtu.be/TxYi7J0vKC8

I created a simple Ruby library just about two weeks ago: https://github.com/yegor256/iri. I already have more than 60 GitHub stars there. How did I do that? I just published it where I usually publish my open source libraries. There is no secret. I just create them, publish and then some of them (!) become popular. You should do the same. Every time you see an opportunity to make a small piece of code open -- do it. And make them small. The smaller your open source products the easier they are to use and the higher the chance that they will be popular.

The video is here: https://youtu.be/jeflGHMpfDc

Most companies and project managers feel proud of spending a lot of money for finding programmers, training them, getting them on board. They tell me very often that programmers are their valuable assets and they don't want to lose them since they invested so much into them. That's a terrible approach, which is only disrespectful to us programmers. We are not your property or your assets. We want to be equal partners with your team. Change your attitude before it's too late.

The video is here: https://youtu.be/UFfJCRhLCZ0

It is a well-known fact that Lines of Code (LoC) is a very inaccurate metric for a software developer. It doesn't demonstrate anything and can't be used to measure the progress of a programmer or a number of efforts the programmer puts into the source code. However, there is another metric called Hits-of-Code (or Code Churn), which is calculated differently and perfectly indicates how much time or efforts the repository required to be created. There is a command line tool of mine, which can help you calculate HoC in your repo. There is also a hosted web service, to do the same.

The video is here: https://youtu.be/hTs_R0dFoFM

Most programmers think that writing code is enough to be useful for a software project. It's not true, especially now, when projects are becoming smaller and teams are more distributed. A modern programmer must understand all the processes and phases of a software development lifecycle. The best way to learn them all, if you ask me, is to study the Rational Unified Process (RUP).

The video is here: https://youtu.be/Af0E8Bn8qcw