SHIPPING

A few days ago I have watched one of the best direct video of all times. By Anthony GG — Why You SUCK At Programming. Basically, he criticizes the tech community’s excessive focus on superficial aspects of coding, such as naming conventions and code appearance, and the resulting culture of criticism rather than collaboration and problem-solving.

I believe the most important part of this video is about problem-solving. We are producing software because we want to solve problems in the most efficient way and with the least amount of effort possible. To solve a problem, you need to know about the problem domain and have software engineering skills.

Even though most engineers have these skills, many don’t actually ship their work. Instead, they jump from one new thing to another and don’t solve any real problems. Knowing how to code isn’t the same as understanding the whole product. People can get too caught up in making their software perfect, forgetting that the real goal is to solve the user’s problem.

That’s why shipping is important. It’s about finishing and delivering. Your software doesn’t need to be perfect; it should be good enough to address the problem, then you can improve it based on feedback. This cycle helps you figure out what works and what doesn’t, enhancing your software over time.

Don’t get too hung up on choosing the latest technology unless you really need to learn something new. Pick a technology that you know well. Ask yourself: Can this technology solve my problem? If yes, stick with it. Don’t switch gears until you’ve finished. Spending time on something doesn’t always mean you’re making progress.

Remember how you feel when you look at your code from six months ago? You might think, “Wow, that’s not good.” But that’s okay. It shows you’re getting better. Your old code might look bad to you now, but it was your best at that time. This is how you learn and improve. It’s not about writing perfect code. It’s about evolving and making software that helps people.

When the right time comes and you really want to learn something new, you bring your knowledge with you. Nothing goes to trash when you switch things up. You always going to build something with everything you know. If you are a PHP developer and suddenly you wanted to learn Go? All the backend knowledge is applicable to Go as well.

Keep your eyes on the real prize: making something that works and solves problems. Don’t worry if it’s a bit rough around the edges. What matters is that it’s out there doing its job, not sitting on your computer because it’s not “perfect” yet.