Raul Junco

Knowledge doesn't come from YouTube hours but from problems solved. There is nothing wrong with tutorials, but you need to go beyond. Try to implement the concepts you just learned but solve a different problem. Solving problems forces you to understand edge cases. Every bug you debug, every error message you decipher, and every solution you architect from scratch strengthens your problem-solving muscles in ways that passive learning cannot. Pratice makes the master.

Pair Programming is undervalued. - You get to swap knowledge on the fly. - You learn how I navigate through this massive codebase. - Increase the Code Quality - It's a two-way street. You get someone else's experiences and also get to share your own. Even explaining your logic helps solidify your understanding. - Make your team more resilient since more than one person is familiar with each part of the codebase. Pair Programming goes beyond simple teamwork; it is about sharing knowledge.

What are the most common software engineering roles in startups? I tried to answer this question, and it took me a day. I have spent most of my professional life working for startups. In startups, the team is small, so we often wear many hats: • backend/frontend • WinForms/Web • Mobile • DevOps You'll become something of a tech expert; you'll get a slice of everything. There is no time for many formalities and ceremonies; I often write tickets and draw diagrams. I was never bored; I was always solving problems without getting stuck, jumping from one fire to another. A startup is like a Bootcamp, a university, and a real-world lab all in one. The official answer is maybe the famous "Full-Stack." But my answer is: A Problem Solver!

How do you become a lead software engineer? The easiest way to do it is by taking Initiative. - Go and help lead a small project - Go and mentor a junior on your team - Go and refactor that old project causing many problems but is the one every customer uses and makes money. This will help you to develop all those skills that you need: - communication - problem-solving - articulate complex technical concepts in simple terms - make decisions - learn from your mistakes. There is no shortcut you have to take more responsibility.

The most important thing a senior software engineer can do is be available for the team. Here's why: Senior engineers provide mentorship. They help in solving complex problems, often because of their experiences. They maintain code quality through reviews, but most importantly, they teach how to keep the quality in place. They help in choosing the right technologies and strategies for project success. They are often the go-to persons for troubleshooting and resolving critical issues. They have seen a lot, so they are better at planning, estimating, and risk assessment. They are responsible for shaping the team.

Documentation is tricky. These are the steps I follow to build useful documentation: 1- My Audience: If it's for developers, focus on technical details like code snippets and API references. For project managers, include overviews, timelines, and resources. 2- Define Purpose: Is it to guide development, facilitate maintenance, or provide a reference? 3- Complexity: Complex projects with many dependencies require thorough documentation, and simpler projects need high-level overviews. 4- Maintainability: When documentation becomes a burden to maintain, it is dead. 5- Use of Visuals: Diagrams reduce the need for extensive written explanations. The key is to provide enough information to be useful without overwhelming the reader.