Dave Cutler, at age 74, still goes to his office at Microsoft every day to write code.

I first heard of Cutler when he was honored as a Computer History Museum Fellow for his five decades (!) of work in the computer industry. ¹ Based on his lifelong dedication to engineering alone, many would consider him a “hardcore” programmer.

What’s even more awe-inspiring than his long tenure, however, is that his work has influenced the computing experiences of over 2 billion people. Among his many contributions, Cutler built critical pieces of Windows NT — the basis of all major versions of Windows in the past twenty years — and gave Microsoft a huge market advantage in its early days by making the operating system backwards-compatible with earlier software. He’s been called the “key technical brain behind the Microsoft Windows operating system.” ²

So what makes people like Cutler successful programmers? And how might we aspire to achieve even a fraction of his level of impact? What separates the strongest programmers — and those who bring about the greatest positive impact on people’s lives with their software — from everyone else?

This last question in particular is one I wondered while doing research for my book, The Effective Engineer. While programming isn’t the only activity engineers do, it is one of the primary ones. And from interviewing successful engineering leaders at top tech companies across Silicon Valley, I’ve found that the most effective engineers — the ones who get things done and create a big impact — share at least these five programming mindsets:

1. Be fearless in diving into code you don’t know.

Jumping into an unfamiliar codebase can be uncomfortable and scary — many people give up without even trying. This critical skill gets easier as you do it more often, and in the process, you become a significantly better programmer. If an open-source library or a library from another team doesn’t work as you expect, it gives you the flexibility of jumping into the source code to debug why.

Fear of the unfamiliar goes beyond code. Every time you change jobs, there might be a lingering concern that maybe you won’t be able to replicate your strong performance from a previous role. Few people talk about imposter syndrome publicly, but I’ve even had CTO’s tell me that they feel like they’re frauds.

The reality is that we all start somewhere. Cutler attended a small liberal arts college and didn’t even have a formal computer science education. So in many ways, he started behind his peers and had to learn many things through trial and error.

To get better over time, we have to adopt a growth mindset and optimize for learning. Any skill, whether it’s programming, communication, networking, small talk, or something else, is learnable if you invest the time. Read books on the subject. Ask for help. Know that with time, dealing with the unfamiliar gets easier.

2. Master debugging.

“Why isn’t my code doing what I expect?” That’s a question we ask ourselves every day as software engineers. The ability to debug effectively has a disproportionately large impact on an engineer’s ability to get things done, and yet tends to be under-taught in college and under-evaluated in technical interviews.

How do you debug effectively? At its core, it distills down to the scientific method:

• Make a guess about what’s going on.
• Assuming the guess were true, identify what the consequences of that guess would be.
• Try to make observations that contradict those consequences.
• If you find a contradiction, your guess is incorrect, so make another one. If not, you have one possible explanation.

To get faster at debugging then, you have to learn to make better guesses, and you have to get proficient at tools and techniques that help you make better observations.

Making better guesses comes with practice as you solve more problems.

Making better observations depends on building up your technical skills. Start with the assumption that everything is observable, and figure out the tool or the mechanism that lets you make a given observation or make it faster. Don’t assume that you can only observe things based on the limited tools you’re familiar with. Chances are that someone has already developed a tool to understand what you want to know.

3. Invest in time-saving tools.

When computers were first available, computing resources were limited and expensive, so programmers had to be very resourceful in how they used them. Today, an hour of computation on Amazon’s cloud costs under a penny. ³

On the other hand, we’re still all limited by the same 24 hours per day, 7 days per week. This means that any manual work we can offload onto computers is extremely high-leverage. We do that by investing in time-saving tools and automating workflows. Tools let us amplify the output we create with the time we spend. Automation enables things to get done in our sleep or while we’re focused on other problems.

As I was writing The Effective Engineer, I sat down with Bobby Johnson, a former engineering director at Facebook who grew the infrastructure team from 6 people to over 100. One of his observations that’s stuck with me is that “of people who were successful, almost all of them write a lot of tools.”

It might seem obvious to some engineers that tools are a great investment, but when we actually break down our work day and think about what fraction of our time is spent on building tools, we may find that it’s not that high. But many of the best engineers on Johnson’s team actually spent a third of their time on tools — tools for deploying code, for monitoring systems, and anything else that enabled them to get more done in less time.

Don’t keep doing what a machine could have done for you.

4. Optimize your iteration speed.

Say it takes you 12 seconds to search and navigate from a function call to where it’s defined. And suppose you have to do similar navigations 60 times per day. That’s 12 minutes per day spent navigating files. If you learn enough keyboard shortcuts in your text editor to navigate to a file in 2 seconds instead of 12, then over the course of a day, you’d save 10 minutes. Every year, you’d save an entire 40-hour work week.

Find 3 more similar optimizations, and you’d save a month. Imagine what you could do with an extra month per year.

Or suppose that you’re fixing a bug that requires you to start the app and then navigate through five screens to set up the right conditions to trigger the bug. Could you spend 10 minutes to wire it up so that it goes to the buggy screen on startup? You’d be able to iterate significantly faster on that bug with a small initial investment.

Systematically ask yourself, “How can I iterate faster?” The payoffs will be enormous and compound over time.

5. Develop system-level thinking.

When you’re programming, it can be easy to consider your work “done” once you’ve implemented the code according to some specification. But that’s really just the tip of the iceberg. Any work that’s just sitting idle in a code repository and not running in production is work that’s not producing any value.

To build and ship code that actually matters, you need to elevate your thinking beyond your code to the level of the entire system:

• How does your code fit in with other parts of the codebase and features other people are building?
• Have you sufficiently tested your code, and will the quality assurance team (if any) be able to exercise the functionality you’ve built?
• What changes need to be made to the production environment for your code to be deployed?
• Will this new code adversely affect the behavior or performance of any other running systems?
• Are customers and users who interact with your code behaving as expected?
• Does your code lead to the desired business impact?

These are hard questions, and answering them well takes effort. But you need a clear mental model of where your code fits into the big picture to know how to direct your time and energy toward the work with the greatest positive impact.

These five programming mindsets will help you get started, but just remember that there is more to being a successful programmer or engineer beyond the lines of code you write. If you want more tips from some of the best engineers at Google, Facebook, Twitter, LinkedIn, Airbnb, Reddit, and other top tech companies, get a free two-week email course on how maximize your impact when you sign up for the newsletter or check out the book.

Happy programming!

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