Reading time: 3m 43s


Hey ,

Before our letter for today, I'm excited to share with you The Software Engineer Growth Tracker.

It is a powerful and flexible template to track your growth as a software engineer in 2023. It also has 100% free resources, projects and everything you need to level up. I've included a video in the template to walk you through.

Get the Growth Tracker here for free




Two years ago, I joined a Canadian company as a lead software engineer.

My role included leading and managing a team of six engineers.

As part of my job, I needed to understand the strengths and weaknesses of each team member.

So I got on a call with the product manager and VP of engineering.

During the call, they kept praising a team member named Lee and said nothing but great things about him.

I was curious. What's so special about Lee?

Does he contribute more code and finishes his tasks faster?

So I checked Github. From the insights, Lee didn't have more commits than the other team members.

I then searched through messages on slack and found something interesting.

message from lee lowe on slack

Wow. I loved this message. I finally had my answer.

Lee was value-driven. That's why he made a great impression. That's why other stakeholders thought he was exceptional.

Some engineers get assigned tasks, focus only on their task, get it done, and move on to the next task. This is meeting expectations, and that's great.

But, value-driven engineers want to do more and exceed expectations. They want to think of ways to provide more value to their team and company.

Being value-driven has taken me places in my career.

In today's letter, I will give you 3 simple steps to becoming a value-driven software engineer.


1. Think in problems and solutions, not code and languages


There's a statement I tell my mentees every single time we get on a call:

you are paid to solve problems, not just write code

Before you write a single line of code, even in practice projects, ask yourself this question:

How am I creating value with the code I want to write?

What's a real use case for the work I'm about to do?

Let's say you're on the job and your task is to create the sign in page for a user.

Your implementation and how you work on that task becomes drastically different if you begin to use a problem and solution mindset.

I interviewed hundreds of developers during my time at Turing. I was able to tell those that think in problems and those that think in code.

I challenge you from today. Before you write a function, start a new task, or learn anything new, ask yourself these questions:

  1. What job do I need to get done?
  2. What value am i provided?
  3. How can I provide the best possible value?

Once this becomes second nature, you'll talk differently, speak differently and interview differently.

Once this becomes second nature, you'll talk differently, speak differently and interview differently.

2. Genuine care for your company and team


When I saw that message from Lee, just one question came to mind. Every engineer on that team had been using Create React App for months. They all saw how slow it was, and they all accepted this outcome.

No one thought about suggesting something faster.

No one felt maybe we should switch Redux for state management.

But Lee did. Because as a value-driven engineer, everyday at work, you spend time thinking about how you can provide more value to your team and your company.

Think about those things you can do to improve everyone's lives. Your team, your company, your customers.

How can I help my company make more money this year ?

Can I make our website 2 times faster ? Can I take on the QA role at the company without anyone asking me? Can I do a deep study and improve the Search Engine Optimisation of our entire brand online?

These are the thoughts I encourage you to think. And these thoughts can only come if you have a genuine care for where you work and the team you work with.


3. Don't stop growing


Every month there's a new framework. Many developers think to continue growing means to learn every new framework that comes out. No.

To continue growing as a developer is to do 2 things:

1. Better use the technologies you already know

Back in 2016 when I learned React, I knew there was a better way to write code. I had a great desire to learn even better ways to write.

And every week, I learned a new design pattern. I learned a new performance optimisation.

And I kept doing so. This is how I grew.

Every week, I pushed my limit.

And got better with the technology I already used everyday.

The more value you add to yourself, the more value you can add to others and the company you work with.

2. Understand the new solutions released every week, the problem they solve, and how they solve it.

I've never used Svelte before. The week it came out, I immediately went to Youtube and watched a long talk from its creator that talks about the reason it was created, and how it solves the most common frontend problems.

Now I know that a shadow DOM is one out of many ways to create a frontend framework. I understand how other engineers think about this problem and how they are solving it.

I did the exact same thing with Qwik.

Thank you for reading to this point.

If you loved this newsletter, please reply this email and tell me what you would love to read about next week, and where you'd like to grow.