yegor256 podcast

Most people ask me why exactly I think it's important for a software developer or an architect to be a blogger and stay active on Twitter, for example. I believe, and most recent practical cases prove that a well-connected and "visible" software architect would bring a lot more value to a project than someone who just knows how to write code. The video is here: https://youtu.be/l-bM2XyhlkQ

Risk Driven Development is a powerful concept, which may help you prevent many bad things in your project. Unfortunately, many teams don't know how to do it right. I'm going to publish an online tool for that soon, which will be used by Zerocracy and for anyone since it will be free and open source. The book by Rita Mulcahy: http://amzn.to/266pAYB (you must read it!) Zerocracy is here: https://www.zerocracy.com The video is here: https://youtu.be/WlI6IZ6M7vY

Microtasking, in order to work properly, requires a certain amount of discipline. First of all, all tasks and communications about them have to happen in tickets. However, our customers are far from being disciplined enough to use tickets for every requirement they have. Instead, they make phone calls, chat with us online, and send emails. I believe that is the responsibility of an architect to make sure each request that is coming from a client turns into a ticket. If you, as an architect, don't do that, you are doing a very bad favor to the project.

Very often our investors and users ask us why Zold has master nodes, even though it claims to be decentralized and anonymous. I answer that I can't imagine a serious cryptocurrency without a certain amount artificially created master nodes, which help it survive when it is still young. Without them, it will be possible to destroy us easily, just by a majority of hardware, which is not that expensive, while we are young and small. The video is here: https://youtu.be/kNqKLCWFzbY

Many startup founders think that by sharing equity with programmers or giving them annual bonuses according to the overall result of the company, they can motivate them to work better. This is a wrong idea because programmers can't control those things. They can control the quality of their code, the speed of its delivery, their unit tests, their build pipeline, and other technical things. By rewarding them for things they don't control, the business only demonstrates that it doesn't understand what it is doing. The video is here: https://youtu.be/MyBbtwKgc9k

Every time someone comes to me for a piece of information, I ask myself: "Why? Isn't this information available in our documentation?" And if the answer is "No," I try to improve the documentation, to make that piece of information visible and accessible, to avoid future requests of the same kind. You should do the same. Don't train anybody, don't teach anybody. Instead, write tutorials. Help yourself and your project. The video is here: https://youtu.be/QzU2Fbr3xuI

Very often my readers complain about me saying that programmers must be in conflict with testers, or code reviewers in conflict with programmers, and so on. They claim that a good software team must have everybody going along and share the same set of objectives. They say that we should work "together," not against each other. I strongly disagree with that. I believe that good management means organizing conflicts and giving people explicit rules for resolving them. That's how quality can be achieved. The video is here: https://youtu.be/DUWiy7fvVzk

Being a freelancer and charging $100 per hour, switching projects every few months and living in Bali, sounds like a dream for many programmers. But the question is, how to get there? Where can one get experience and training? Does it seem that the only way to learn to programme is to work somewhere as a full-timer? Yes, why not. Most of you will remain full-timers, but some of you will become freelancers. Those two categories will co-exist on the market. The video is here: https://youtu.be/sJRM4VWkzSM

Building teams that were supposed to stay together for many years, was a good strategy, many years ago. Not anymore. The reality of the modern software development market demands us to work with remote programmers, who in most cases will be individual contractors or freelancers. They will not be emotionally attached to the team or to the company. They will be looking for the most interesting projects on the market and will quit the moment they will realize that your project is not the one they fit well with. That's why, if you want your business to be ahead of the market, you should start learning how to work with freelancers and how to manage projects. Instead of building teams. The video is here: https://youtu.be/5GfGXhzQb4Y

The current situation on the software development market it terrible: programmers are spoiled by large salaries and very high demand. They know that their managers can't really do anything with them, can't make them work faster or better, can't fire them, and can't enforce any discipline. Large companies, like Google or Facebook, have the luxury of buying 10 times more programmers than they really need, that's how they solve their productivity problems. However, if you don't have that amount of money, you must not manage your programmers the way Google does it. You need a better management formula. Which one? Microtasking from Zerocracy is one of the options. Use it or invent your own one, but don't copy Google. The video is here: https://youtu.be/XQQoaBZEs38