yegor256 podcast

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

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