I’ve spent the last few months mentoring a number of junior developers – some who have just started their first job, and some who are still looking for it – and one point keeps coming up in our conversations. It seems general enough to warrant a blog post yet controversial enough to get that social media engagement, so here we go.

(I’m going to describe relationships between businesses and customers and employees, which is going to sound more clinical than my typical blog posts. What follows is just one perspective on the world, and while it is a useful perspective, I encourage you to seek a meaningful life through more than optimizing business relationships.)

Here is my advice:

Software developers aren’t paid to code.

Controversial statement, I know. But let me explain. Programming is fun, which is why a lot of us got into professional software development. Getting paid to do something you enjoy sounds great, right? But you’re not getting paid to code just anything; you’re getting paid to code what the business needs. Bug fixes, new features, etc.

Businesses exist to make money. Technology businesses pay programmers to build products which the businesses then sell to customers at a profit. (The same roughly applies to venture-backed companies.) As a software developer, it’s really useful to keep in mind because the sooner you can start thinking about your work in terms of your employer’s business success, the more valuable you’ll be to your employer. This means attaining a bigger impact, sooner, which translates to promotions and raises and professional esteem. Cool!

Software developers aren’t paid to code. They’re paid to build products that help the business succeed.

Early in my career, I focused on coding for the sake of it. I was just happy that I got paid to program! And I didn’t always take the company’s needs or goals into account when I was deciding what to build or how to build it. This led to some expensive mistakes. I wish I could go back in time and explain to myself how important it is that I understand how my work impacts the business’ success.

For example, in 2014 before Swift had even reached a third beta, I started building a new app in Swift. Using a brand-new and constantly-changing programming language slowed the project down significantly. We actually nearly missed our deadline. Even though I was excited to use the new programming language, it wasn’t the right decision for the business. The company-wide “we don’t think we can finish this in time” email will haunt me for a long time, but it also still motivates me to think carefully about the foundations I build.

So my advice for juniors is that you should be able to describe how your work helps your team meet its goals, and how your team’s goals move the business towards success.

Talk with product managers, designers, and other stakeholders. Find out why your team is working on its current project. Why is this project the most important right now? What is next? Why? Just asking these questions shows your team that you’re interested in something bigger than just coding; it shows that you’re interested in helping the company succeed, which is what matters most to the company.

I’m not saying you shouldn’t be excited to code. Hang on to that excitement, do not let go of it. What I’m saying is that if you understand your employer’s business, then you can identify the overlaps between “doing cool computer programming” and “providing business value.” It’s a win-win!