TL;DR: Want to advance your career as a software developer? Putting all energy into learning technical topics is not enough. You need to think outside-in.

Finally, you landed your first software development job. It felt like a dream came true. Or at least it's one step closer to your dream. Your career as a software developer just started. You are super excited and eager to learn and grow as fast as possible. You want to be like that ninja developer on the team who seems to know everything about programming. You are ready to put in some extra hours after work to read books and study. Your next goal is to write better code faster and to become the next ninja developer on the team.

As a developer, caring about your craft is great. Code readability, test coverage, TDD, and software designs, all these are important topics of software development. But to truly become a ninja developer and to really take your career to the next level, improving your technical knowledge is not enough. You need to stop thinking like a developer.

The rest of this article answers four questions:

What does thinking like a developer mean?

Thinking like a developer means ALL you care about is your code. All of your energy and effort go into writing the best code possible, improving your programming skills, and learning different programming languages, frameworks, and techniques.

I am NOT saying this is how all developers think.  But it's quite common for junior developers to channel all of their energy and attention to technical topics in the early stage of their careers. I was one of them.

I am NOT saying you shouldn't do any of these. All these are great things worth your time and effort. They are necessary to advance your career. But they are not enough.

Why do you need to stop thinking like a developer?

You need to stop paying all of your attention on technical topics because you are not hired to write code. You are hired to provide value to the company, to help the company succeed. And writing code is the way or one of the ways you provide value.

You need to stop putting all of your energy into writing the best code possible because there is no such thing as "the best code". The definition of the best code depends on the context. If the code you write is mission critical, like handling people's money, then the best one is the most robust one. If the code you write is likely to be changed often, then the best one is the one that's most flexible for changes. If the code you write is time-sensitive, then the best one is the one you can write out fastest without major bugs. The context determines how you should write code. But thinking from a purely technical perspective won't help you obtain that context.

You need to stop spending all of your time learning only technical stuff because you won't be able to use them correctly. Frankly, your customers don't care if the app is written in Ruby or C#, if you use TDD or BDD, or if you refactor your code or leave it as a mess.   Since you are hired to provide value to your company, mostly through writing code, all the techniques you learn have the same purpose: to help your company and the customers of your company. When all you care about are the techniques, you are missing the big picture. You need to spend the time to obtain the big picture so you can use these techniques at the right time for the right reasons. Learning technical stuff is necessary, but not enough.

What does thinking outside-in mean?

Why would someone buy the product or service of your company? To think in this way, you need to at least learn the value your company provides. If you want to take it one step further, you should also study the addressable market of your company and competitors on the market.

Where does the company currently stand and where is it going? You should try to figure out the direction the company is going. This should be pretty easy to find out. If you work at a large public company, there should be many articles covering that. If you work at a startup, it should be relatively easy to find out by simply asking your colleagues.

What's the focus for the team this quarter? What are the major projects and how important are they? You can learn that by simply asking your manager and your teammates.

How do you fit in these big pictures? How does the code you write contribute to your project, your team, your company, and the customers of your company? Everything you do and every task you get assigned to should be a contribution at all these levels. Your job is to figure out what is the value of your task and based on its value, what is the best way to do it.

How can thinking outside-in help you advance your career?

You will learn about the industry your company is in. What is the status quote for the market and what are the trends? You will learn a bit about how your company functions. How does it decide on the current marketing strategy? How does it come up with the product roadmap? You will learn about the dynamic of your team. What projects are more important and have more impacts? Who has more experience in which area?

For each task, you know exactly how important and how urgent it is. If it's mission-critical, you better think very hard about all corner cases, make sure you cover all cases with tests, and maybe have more than one senior engineers look at it before landing. If it's time-sensitive, like fixing a bug in production, you might want to focus on the correctness of the code and put aside maintainability for a moment so you can ship the fix as soon as possible. For each meeting, because you know the purpose of it, you can follow and contribute to the conversation easily.

Because you can see the big pictures, every time you present your idea, either a code review comment or a new technology to adopt, you can tie it back to how it provides value to your team/company/customers. That makes your proposal instantly more convincing if your reasoning is sound.

All the extra things you learn by thinking outside-in will help you see different opportunities. This knowledge is at your service no matter what you later want to become: an engineer manager, a technical leader, or employee #1 of a company.

You still need to learn all the technical stuff when thinking outside-in. But thinking outside-in brings you closer to users of your code which will, in turn, help you wite better code. You now care about your code not only because you want to be a ninja developer, but also because you know how it's touching others' lives.

Next time you put your hands on the keyboard, try to think outside-in first. 🙂

Related article: The other side of technical skill: Domain Knowledge and Long-term Vision.

Thanks for reading. I hope you enjoy the article. Please share things you learned early in your career. I’m eager to read about your experience.

Don’t forget to subscribe!

Related Posts

• Seeking Approvals at Work Exhausts Me

• Three Lessons from A Frustrating Meeting

• Project Planning: A Spike with First Principles Thinking

• Fear No Awkwardness — Chatting is Good

• The Power of One-on-One Meetings and Personal Connections