yegor256 podcast

Many customers, who pay for software development, think that some programming languages are fast, while others are slow and when they need a great/fast/awesome application, they need to use the language some other team has been using before and managed to create some other great application. This is the wrong approach. Instead, when you choose the language pay attention to how it matches your business objectives. Whether your project is going to be alive for a month or a few years, how big will be your team, how much money do you have to hire experts, how disciplined is your management style, etc. Almost any language can create a fast application, but not any language is suitable for disciplined management. The full video is here: https://youtu.be/Pz256gcyuHs

I've heard it very often that people don't like the word "control" being applied to a group of programmers. They find it abusive, offensive, and de-motivating. I absolutely disagree with this. Control is abusive only if it's implicit, hidden, and not obvious. However, if the rules of work are well defined, accepted by everybody and applied strictly, just like those laws we all know in civil life, control is not abusive at all. The video is here: https://youtu.be/ezE0hRH9BnQ

Agile, as a software development methodology, was invented by programmers and for programmers, to make things easier for them and to get a perfect excuse when things go south. In Agile the management is not in charge anymore, can't control things, can't really predict anything, and can't blame programmers for mistakes. If you are a programmer, Agile is your perfect shield against most of the problems in the office. If you are a project sponsor, it's your ticket to failure. The full video is here: https://youtu.be/OOAMNOso46g

In order to isolate your production from the "dirty" master branch, I'm suggesting to use a simple release/delivery model. First, you let everybody commit to the "master" branch, of course, after they pass all unit/integration tests and the entire merge pipeline. Then, you create a candidate branch, which you deploy to the staging environment and let your testers break it as much as they can. Then, when it becomes obvious that testers can't find anything critical there, you the "candidate" branch into the "live" branch and deploy to production, via the deployment pipeline. You may have a number of release candidates, staying in testing simultaneously. This model proved its validity in many projects I've been doing over the last years. If you tried it and there were problems, please let me know in the comments.

Most big websites I work with don't show their error details when something goes wrong. Here is an example: my account with Amazon is in trouble and I see nothing except the "We are sorry" message from them. Instead, I believe, would be much better to show me much more technical information and make me part of the development process. That's what we do in our projects: making our technical defects as much visible for end-users as possible, in order to make them fixed faster. The video is here: https://youtu.be/t1locjBAXYY

The biggest problem of modern software testing is that neither testers, nor programmers, or their managers understand the role of a software tester. A tester is not someone who confirms that the software works as intended. Instead, a tester is the one who confirms that the software has bugs and who knows how to discover them and document. I will be speaking in JPoint in a month, exactly with this topic. Here is a short rehearsal of my presentation for them. I'm interested in your comments, criticism and suggestions. The video is here: https://www.youtube.com/watch?v=D5RtdHicCXE

There are many cryptocurrencies on the market, while 99.9% of them are based on the Blockchain architecture, with some modifications. About a year ago we decided to try to create our own solution, which would be a true alternative to Blockchain. It seems that we managed to achieve what we planned and now it's the right time for you to join us and convert your bitcoins to zolds. This is how you will help Zerocracy and will make yourself a profit. The video is here: https://www.youtube.com/watch?v=5A9uBwMow0M

If I would need to create software for a nuclear power station, who I would work with: freelancers or full-time employees? Of course, the first intent is to get a team of full-timers who we can "trust" and who will care about the business, will be committed to it and will feel personal responsibility. However, this is a very wrong idea. The business will eventually suffer because of lost control. In order to stay in charge of the quality the business should work with people who care mostly about themselves. Freelancers are exactly that type of people. If you manage to deal with them and keep them under control, your business will be strong and successful. The full video is here: https://www.youtube.com/watch?v=12SEpsOH7CE

Very often this question is asked: how Zerocracy can be compared with Upwork and similar platforms for freelancers. Long story short, we are not competitors and can't be compared directly. Upwork provides unmanaged teams of freelancers, while Zerocracy turn them into managed teams. You may and should find freelancers in Upwork and then come to Zerocracy and let your team work under the management of our AI and according to our policy of work. Hope this helps. The full video is here: https://www.youtube.com/watch?v=A6AC2Tgyhzs

When your objective is to put programmers together in one office and make them look like hard working slaves, spending the money of your investors, you definitely need full-timers, with good salaries and benefits. However, if you need to achieve results, and you know how to manage programmers, you need freelancers, who work for results, for money, and for themselves. You don't mix those two categories, they are absolutely different. And you don't apply the same selection criteria to those two groups. The video is here: https://www.youtube.com/watch?v=hDsy-D5zaVs