What are the tangible differences between a junior developer and a senior developer?
How is an engineering manager supposed to help developers find their path and grow into a more senior engineering role?
It may seem trivial at first glance, but you realize in the trenches that the answers to these questions are far from obvious.
We bring you insight from Farhan Thawar, VP of Engineering at Shopify on how to help your junior developers reach senior level and how to help them move their career forward. Farhan shares exciting internal stories from Shopify you can learn a lot from.
I’m all for recruiting software engineers of all levels. Some companies only hire senior engineers, and they tend not to have the system in place to support the creation of an internship program or working with junior engineers early in their career. I barely look at the employees' backgrounds; I only care about their competence.
Many aspects contribute to the difference between a senior developer and a junior developer.
Obviously, you learn by working in an area, and the number of hours you put in earns you experience. It counts even if it comes from different domains. Software engineers moving from backend to frontend engineering will carry valuable experience with them by looking at different problems in different ways.
I often see a key separation between senior and junior engineers in product development. When a product manager explains what problems they have and what solutions they want engineering to build, the junior developer says, “This will take six weeks.” In the same situation, I often hear from an experienced developer, “This will take six weeks. But, if I make this change, I can do it in 3 days.”
It’s not that the junior engineer doesn’t know how to build that solution. The difference is that the senior engineer acts out customer obsession: understands the customer’s problem and comes up with alternative ideas to solve it. The customer owns the problem, the product team owns the solution, and engineers try to help by framing alternative solutions to guide us down the direction we want to go.
Senior engineers with a business mindset understand that the name of the game is solving the problem. They can put the customer first, even if the way might be more elegant or more interesting to build. The product and UX people might disagree, and there will be a back and forth, but this is the way of constructive feedback.
Senior engineers look at a different level of abstraction. They know enough to realize they don’t know enough about the problem, and this drives them to ask more questions. They realize that more work may not have a bigger impact, so they use their curiosity to better understand the context.
They tend to dig even deeper and ask questions like, “Are we even looking at the right customer?” It’s the same approach as a kid constantly asking, “Why?” I like to cultivate this approach.
A senior developer needs to go deep into the technical skills, but it doesn’t stop there. You mustn’t forget about soft skills and the product, the UX, the customers, and the need to cultivate a holistic view on your work. A broader focus and refined soft skills will give you a bigger impact.
There are lots of ways to learn, but I’m going to give you the one that I have found to be the most effective.
Extreme programming, a.k.a. pair programming, is the most effective way to level up your coding skills. It’s two keyboards, two mice, two monitors, and one computer with two people working on a problem. In today’s Covid-19 world, we have remote programming tools to be able to do this.
This level of discipline, intensity, and instant feedback is so powerful that it’s next to impossible to walk out of pair programming sessions without both sides having learned something. Peeking inside a senior developer's mind all the way down to the keyboard shortcuts they use is extremely helpful to a junior. The more experienced engineer will take something away too because they work with a person with a different way of thinking.
If I only had one tool to level up on the engineering career ladder, I’d pick pair programming. You can use the same strategy to improve in any other domain as well. If I had to retire, I’d pay some of the best developers in the world to pair program with me, because I can’t think of a way to learn faster.
In my experience, different types of people enjoy being at different levels of impact.
The famous dilemma is whether you should turn your best engineer into an engineering manager. The right answer always comes from the context. Your senior programmer may want to be a manager and use their skills to develop others, or they may want to have an impact by writing more interesting code.
We have both a principal engineer career path and an engineering director path at Shopify. Our senior engineers get the option to remain individual contributors and still have impact at the director level. It’s about deciding where you want to go as a person.
I was talking to one of our senior developers about a promotion. The next career level from there is either staff engineer or engineering manager. This person was interested in the staff engineer route.
We figured out that to move up the ladder, this person at this time needed to have an impact beyond his group. Helping with building software for Shopify in a broader context is the job of a staff engineer. So he shifted his focus toward that.
We checked in again after six months. He was doing well, and he was about to receive the promotion, but it turns out that he didn’t enjoy the staff engineer work. He saw how it would broaden his skills, how he’d work with other groups, and he didn’t want to do that.
On paper, an engineering career ladder may look straightforward, but I prefer using the jungle gym metaphor.
This senior engineer wasn’t interested in stretching his craft in that direction, but wanted to focus on one specific area. We ended up moving him from a feature team to a tooling team. He loves that role.
He didn’t have to move up the career ladder. He ended up going in a lateral direction, and he enjoys learning new things and facing different challenges. We showed him what moving up looks like, and he realized that he doesn’t care for that type of work.
The same thing can happen in engineering management. I promoted a person to engineering director, and it turns out he didn’t like the switch to engineering management, so he wanted to move back to an individual contributor role.
I like the jungle gym metaphor, because a career doesn't have to be all about joining a big company and climbing the ladder. You can go to different companies of different sizes, get into engineering leadership and different areas in software engineering. I advise everyone to try different things and to broaden their perspectives.
I start delegating some of my tasks to them. I take a task - preferably one that I like - and say, “I was just about to start reallocating this team and figuring out for 2021 what the team structure should look like. Is that something you would like to do instead?”
Of course I don’t just drop it off; if they’re interested, I do it with them. They get an opportunity to do something that’s normally my job. I do this all the time.
I’m VP of Engineering, so I do this with management tasks, but the same principle applies to all levels of the engineering career ladder.
If there’s a project in the company that would normally be a staff engineer’s job, I sometimes offer it to a senior engineer as a stretch project. “I was going to take it to someone else, but this is a good stretch project for you. Are you interested in collaborating with other teams and building this?”
When engineers do a stretch project like this, they get to see if they enjoy that type of work. They may do a good job but realize they want to do something else. This beats only realizing this after getting a promotion; stepping down is bad for them and replacing them is bad for management.
Ideally, people do a good job and enjoy that role. If they sustain that performance level for six months, it’s obvious they should get the promotion. You can present the facts of their work, and you get to make an easy decision without any pushback.
We have an entire learning and development team at Shopify to help engineers get up to speed with the tech stack, the codebase and the development process. We hold a developer summit, and we have developer talks every week.
We hold hack days internally. Engineers get to work on something completely different from their normal job at these events, with the goal to ship it in three days.
Shopify also supports traditional types of development. We provide opportunities for our engineers and engineering managers of all levels to take courses or to buy books using company resources.
Figuring out training methods is a struggle for me, because I tend to be more academic in my learning, while others often learn more effectively by jumping into the work at the deep end. I like to read up first and focus on gaining real experience after. There is no right way; people are simply on different parts of the spectrum.
The pendulum swings towards learning by doing at Shopify. I like the Abraham Lincoln quote, “If I have to chop down a tree in six hours, I’ll spend the first four hours sharpening the axe.”
We use a phrase, “Own your own development.” It doesn’t matter what company you’re at, how much training you’re offered, or how much money goes into your professional development. It’s all about you taking advantage of it.
Your company can help you by giving you a professional development budget. Providing training, resources, books, opportunities to attend conferences, and so on. As an engineering leader, I try to help by frequently asking my reports these questions:
We provide all this at Shopify, but you have to take advantage of it. You can ignore all this and still do well. You can do all this and not apply the stuff you’ve learned to your craft.
The company can make it easier for the employees and reduce the friction. When I see that someone is looking to read a book, I often just buy it for them. It’s quicker, and it’s low investment for me, but they still have to take advantage of it.
It’s also on you to realize if you’re stagnating. The senior developer I mentioned earlier, who wanted to move up to staff engineer had it in him to aim to move up. He came to us, he earned the opportunity, took it, and together we got to the conclusion that a lateral move was best for him.
I know people who have a clear career plan. A VP of Engineering at Microsoft always told me, “In order to run your own business, you have to spend time in sales, operations, marketing and product departments.” This is how he viewed his career, and he made sure to hit every milestone.
I’ve never treated my career that way.
I worked with an engineer who was so into machine learning and AI that nothing else mattered. He didn’t care about title, compensation, or the size of the company. He was happy as long as he got to work in his domain, and that’s great.
I met another engineer who had a family member in the hospital. His framework was making the most money possible, because he had to pay for medical bills. He didn’t care about title or career progression; he only cared about being a highly paid contractor.
My career framework is that I want to work with smart people on hard problems.
I sold my company to Shopify based on this. I was happy with the way things were going at my own company, because I got to work on hard problems with smart people. When Shopify made the offer, I realized that by merging with them, I’d get to work on even harder problems with even smarter people.
Your career framework might change, but even if it doesn’t, it can lead you to different answers in different stages of your life. I recommend everyone to articulate their own framework. I don’t use any career plan beyond this.
I ask myself these questions:
How can you win even if you (or the company) lose? Can you push through difficulty and discomfort?
There are times when an engineering manager can help a developer do more than they think they can.
Steve Jobs is famous for doing this by yelling at people, “This is not good enough!” This works for some people.
You can also try to inspire your engineers by painting a picture of the future to get them to push forward. You can pick up valuable advice from Dan Pink’s work, the Mastery, Autonomy, Purpose framework on how to do this well.
Offering your engineers stretch projects is a great way to push them towards development. You can’t just drop it on someone to get it done. Offer them to help you out with it, and see if they want to do it with you or alone, only getting feedback from you along the way.
I’m a fan of putting people in a sink-or-swim situation. In my experience, software engineers rise to the occasion more often than not, even at a junior level.
We were running a hack day project, and we had an intern who had just turned into a full-time junior programmer to take the lead developer role on the project. Everyone questioned that decision. But he was very interested in trying the role, and it was a great opportunity to learn, so I gave him the chance.
The project ended up failing, but not because of him. We simply decided that we didn’t want to invest in that area.
The only way to lose in this case is by not learning something from the experience. He wrote up notes with his takeaways on how to commercialize a product, and he shared it internally. We all learned a lot.
The bottom line is, you can’t make anybody do anything. You can give them opportunity and space, and you can mentor your developers on how to get things done. You can give them context about things they don’t see and share ideas.
Even if you do everything, it’s up to them to say, “This is what I want.” An engineering manager can say, “I think you can do this one,” but they have to be willing to take it.
There are very few things in life you must learn. When it comes to the software engineering craft, someone can easily ignore Java, Ruby or any programming language and still become exceptional. But weak communication skills will hurt you for your entire life.
Whether it’s written or oral communication, you have to have at least some skill in it.
If you don’t enjoy playing a sport, it’s okay not to spend time learning it, but you can’t afford to score a 1/10 in communication. You have to be at least a 6/10, or it will hurt you in everything you do ever. I encourage engineers to learn to write and speak well, because hard skills only take you so far.
Just this week someone sent me a draft of an email that was supposed to go out to 300 people, and it was four pages long. I told them to cut it down to half a page.
Even at my experience level, you’re still getting better at communication.
Recently, I was writing an email to the whole company, and I sent the draft to the CTO of Shopify. He told me on Slack, “This email is terrible.” A common response to this would be to think, “He hates me, and I hate my life.”
I went for a walk, and when I got back to my table, I said, “I’ll write a better email.” He gave me some tips, I took them, and made it better. The CTO approved my second draft, and I sent it to the whole company.
Everybody should get feedback on their communication skill constantly and adjust. The point of this interaction was to make the email better.
Write more, speak more, and improve at it. It makes you a better software engineer at any level.
As a manager, you can fill your developers’ lives with friction. There are many ways to hurt them. You should think about the bad behaviors you may engage in and try to figure out how to do no harm.
This makes everybody better. It makes you better, as an engineering manager, and it helps your reports develop. Once you stop doing everything that may be wrong, you can start building up ways to help your junior engineers move forward.
Everybody can learn; I’m learning right now. I have thick skin, so I’m happy to get feedback on anything. When you get feedback, it’s not about you but your product.
A terrible email doesn’t make you terrible; it’s just a terrible email. If you can take the feedback in stride and make your work product better, you win!
Farhan Thawar has worked at companies big and small, which gives him a unique perspective on engineering management and engineering leadership.
He started at a small company that grew to 1,500 people. Later, he started his own company with 0 employees, and he learned a lot from that. He has also worked at giant companies like Microsoft.
He lives by his rule to always look for smart people and hard problems. Even when he invests into companies, he isn’t looking to make money but to learn something.
He is currently VP of Engineering at Shopify.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.