As a new software engineer, you’re bound to make a number of tactical mistakes due to a lack of experience. Maybe you build some functionality on your own only to learn later that there’s a common design pattern for how to do it better. Or you accidentally push a bug to production. Or you forget to reason through scalability and performance issues until you’re already hard pressed against a deadline.

Mistakes happen, and these mistakes are just a normal part of learning.

It’s more important to make sure you get the big decisions right and avoid the costliest mistakes. And for new engineers, the biggest mistake that’ll cost you in the long run is not optimizing for your learning rate. Some new software engineers make this mistake because they’re too complacent with their current situations. Others make it because they’re too arrogant and think they already know everything. Even more fall into the trap because they’re afraid they’ll fail if they try something new, and yet, that’s one of the surest ways to fall behind.

Small deltas in your learning rate make a huge difference in the long run because investments in yourself compound over time. The knowledge and lessons that you learn today create a foundation for the opportunities that you find and seize in the future. And the earlier that you invest in yourself, the more time those investments have time to compound over your career.

Alfred Lin and the rest of the leadership team at Zappos were known for pushing employees to improve themselves by 1% per day. ¹ If you can do that consistently for 365 days, you get over 37 times better, not 365% (3.65 times) better by the end of the year. That’s the power of compounding growth.

The opportunity cost of missing out on chances to learn and grow is therefore very high. When faced with a decision, you should be asking yourself: which option would increase my rate of learning? The option that enables you to learn faster is the one that, in the long run, will lead you to greater success.

Focusing on your learning rate is valuable for another reason — it’s actually an actionable framework for making decisions and oftentimes arriving at engineering best practices. When your framework is to choose the option that increases your learning rate more, a number of other hard decisions that you face as a new engineer follow through naturally:

• How do you decide which job offer to take? Do you work at a startup or a big company? Work at a company or a team with a high growth rate, and find smart people that you can learn from.

• When should you ask for help and when should you struggle with a problem on your own? Ask for help when the incremental minute spent struggling isn’t contributing to your learning and when a little bit of guidance would free up your time to learn more.

• Who should you send your code reviews to? If your goal is to learn, you should send it to the harshest critics who can give you actionable and detailed feedback on how to improve your design and your code, rather than the person on the team who tends to quickly rubber-stamp his approval.

• What’s the right chunk size for your code commits? Since getting feedback sooner means that you’ll be able to incorporate that feedback into future code you write, you should make smaller, more incremental changes. When I first started out in software engineering, I made the mistake during my Google internship of submitting all of my code for my project during my last week. That landed a “Edmond has sent you a ginormous code review” into my mentor’s inbox. Not only did delaying that code review risk my summer’s work falling into oblivion if my mentor didn’t approve the changes, but I also missed out on opportunities to learn from and apply his feedback. You can be sure that my code commits were much more incremental after that experience.

• Do you pick tasks to do that you’re familiar with or that you’re less comfortable with? If tackling that uncomfortable task will teach you a valuable skill, perhaps in an adjacent discipline relevant to yours, then you might consider taking on that challenge rather than doing more on the same.

• What should you do after a project fails or when a feature you build doesn’t have nearly as much impact as expected? To maximize your learning from that experience, you should hold an open and honest post-mortem with your team about what lessons to take away and how to avoid the same mistakes next time.

• How should you deal with a difficult co-worker that you have to work with? You’re going to encounter difficult people throughout your career. Once that sinks in, you realize that being passive-aggressive or avoiding the co-worker isn’t going to help you get better at dealing with people in the future. Instead, treat every challenge as a learning experience. Be proactive about learning how to have difficult conversations, how to resolve conflicts, and how to make these relationships more productive. You might not succeed initially, but you’ll learn from each experience for future ones.

• If you’re planning on switching jobs soon, what should you do your last few months? Given that many people switch jobs every 2 years, all of those “last few months” add up over time. Simply coasting means you’ll be missing out on learning opportunities, so why not just find ways to learn as much as you can during those months?

There are countless other examples where the path that leads to more learning and growth will generally lead to better outcomes in your early years, particularly when you have fewer constraints and responsibilities to juggle.

A few weeks ago, I had dinner with a co-founder of a growing startup, and we chatted for a while about hiring. Each of us had done hundreds of engineering interviews, and we observed how a candidate with a positive, growth mindset generally makes a better hire than someone with stronger technical skills but who isn’t mindful of their own self-improvement. Even if your current skill levels aren’t as strong, if your learning curve is exponential, you’ll soon overtake other more senior engineers.

So focus on increasing your learning rate. Carve out 20% of your time to invest in yourself. Read books. Level up your technical and non-technical skills. Find a mentor. Attend conferences. Be mindful. If you avoid this one mistake of not optimizing your learning rate, you’ll be on track to become the best engineer you can be.

This blog post was based on an answer I originally wrote on Quora.