yegor256 podcast

Changing jobs frequently is usually considered to be a sin for a professional programmer. Recruiters don't like that and to leave just a few places in the resume, to look more "loyal." However, this is not true for freelancers, who by definition change projects frequently. That's why their resumes have to look very different and recruiters and project managers have to be ready to read them differently. The full video is here: https://www.youtube.com/watch?v=31xOLs-DqTo

Being a senior developer doesn't mean getting a large salary or being appreciated in the office. It means belonging to an elite group of developers who know how to do certain things and can do them. If you want to be senior, think again about open source contribution, about StackOverflow participation, about conferences and certifications. Without that, you are just yet another programmer, one of a million. The full video is here: https://youtu.be/Y_IUzt-Oyww

Most software teams interview programmers before getting them on board. Later they get surprised how was it possible to hire someone who doesn't understand programming. Those so-called "fake interviews" would not exist if we would let the market vouch for programmers, instead of us relying on the information we manage to collect at those Skype calls. We, in Zerocracy, pay attention to five things that are important: 1) GitHub reputation, 2) Stackoverflow history, 3) certifications, 3) conferences, 4) blogging experience. Once a programmer has all of those, we know that he/she is senior enough for us. The full video is here: https://www.youtube.com/watch?v=gVs9NKSlOVc

The first thing you should worry about when you start a software project is how your product can be delivered to end-users in an automated way. Right after you managed to create a skeleton and make it "work on your laptop," start configuring the deployment pipeline. Only after it's done, demonstrate your product to your testers, partners, investors, customers, etc. Don't tell them that your product is in GitHub and if they want they can check it out themselves. This is very unprofessional. Make sure they can touch the product where its end-users will see it when it's fully ready for the market launch. The full video is here: https://www.youtube.com/watch?v=p-Hv-TC0JHc

I'm being asked about English speaking skills very often, that's why this video. You want to improve? Here is hot-list: 1) read English books; 2) watch movies in English, with subtitles; 3) find someone to chat with online, not about work; 4) go to the United States of America and stay there for a few months; 5) make lectures or presentations in English; 6) write in English, like blog post or anything that someone else will have to read. This is what helps me to practice and not to be afraid of speaking English. The full video is here: https://www.youtube.com/watch?v=6de0RNdIIFk

Quality management, if I understand PMBOK and ISO-9001 correctly, is all about the Plan-Do-Check-Act cycle, where we 1) plan what quality objectives are important for us and how they can be numbered, 2) let the team produce the results, 3) collect the numbers, and 4) compare them with our expectations and take corrective and preventive actions. In order to make this all happen, you need to turn your human resources in numbers. How do you do that in your software team, depends on many factors. But software business is the easiest one for that: most of our activities are easy to measure. The entire video is here: https://www.youtube.com/watch?v=euEOroFEHWM

Meetings are a great solution for lazy, immature, stupid, and non-professional software developers, architects, and their managers. The more you grow, the more professional you become, the bigger will be your frustration from those meetings. What is the alternative? How can we make technical decisions without sitting together in a room and talking? The alternative is a strict and disciplined process of decision making, which has to be based on ... guess what ... microtasking. The full video is here: https://www.youtube.com/watch?v=KUUzUb9arNg

When you are ready to delegate your software project to Zerocracy, you will need an architect, who will guide you through the bootstrap steps, will understand the requirements, will build the team of freelancers, and will supervise it, with the help of Zerocrat, our AI-powered chatbot. To find that architect you have to submit a Request-for-Proposal (RfP), which will be "purchased" by one of the most active and reputable programmers and you will get a chance to discuss your project with him or her. Then, if you both like each other, the project will start and you will be the Product Owner and requirements provider. If not, you will have to try again or ask help in our Telegram chat. The full video is here: https://www.youtube.com/watch?v=QsxwHdKoWEI

It happens very often: the requirements we have to work with are not clear. Customers, requirements providers, product owners, managers, architects, and other programmers are simply too lazy to specify them right and they just drop those feature requests and bugs on our heads. We have to deal with them. The most enthusiastic of us dive into those unclear problem descriptions and attempt to clear things our on their our, attempt "to figure it out themselves." This is a very unprofessional behavior. Instead, you should always try to push back those requirements providers and make sure the requirements you work with are unambiguous, clear, and easy to understand. The full video is here: https://www.youtube.com/watch?v=z59jkRAeBDg

You remember my recommendations for a programmer if the management is weak and stupid, right? Don't be loyal. Instead, use their resources for your own good. But what do you do if you are the architect and the tech lead of the project? In that case, the situation is more complicated, but it's solvable. You just need to be more careful, here is how. The full video is here: https://www.youtube.com/watch?v=_Y2lZsRLwlk