Jayant Bhawal for Middleware

Posted on Jun 10 • Updated on Jun 11

Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes.

#career #promotion #webdev #beginners

"I'm good at writing code. Just this month I shipped 11 PRs! I even updated most of my tickets on time. Didn't take that many leaves either! And I worked so many more hours than Sam, too! Why didn't I get promoted but they did?"

-- Some unfortunate person who didn't get the promo this time.

Does that sound relatable by any chance?

I've seen this before.

A LOT.

Sometimes the reason is office politics. 🤬

Sometimes it's simply expectations not being communicated well. That can suck. 🥲

Sometimes it's a mismatch between how you stood up to the defined expectations, and where the bar actually was. 🤔

You may not be able to control or change what your office environment is like. But you're certainly in control to ensure there's nothing on your end that prevents you from rising up the career ladder.

Cool! Could you speed-run me through what I need to do?

The first thing is to know what your responsibilities are as a software developer. I don't mean your responsibilities in your current org, I mean it as a holistic and individual dev.

I see there's 5 broad areas that a dev should aim to cover.
Click on the links to jump to that section.

Technical (code quality, lang. proficiency, testing, perf.)
Productivity (reliability & efficiency)
Collaboration (communications & reviews)
Ownership (responsibility & initiative)
Impact (system/product improvements & innovation)

"With that, we're halfway to making a D&D character sheet. Roll Nat 20! 🤣"

I'm going to only cover things that ARE in YOUR CONTROL.

I'm specifically mentioning this because one thing I've seen many orgs get wrong is, various areas of evaluation end up including things that you may not have control over.

Such as, you may not have control over how impactful your work was to the company. In most cases, you'll only get to work on the things you've been directly asked to do.

Alright! Let's go! I'm ready to get promoted!💰💰

The 5 areas I mentioned above aren't specific to SDE1's. It's something every dev needs to be on top of. But the bar and expectations from each of those areas change.

Let's talk about what the baseline expectation is from each area, and what you need to do to get to the next level.

Hold your horses. This is going to be long.
But remember, there's only 5 sections below... 👇

1. Technical Skills [🔝]

At SDE1, no one expects you to make a major splash, change the world, save billions!
They expect you to do your job in a way that needs minimal, or at-best occasional hand-holding, and for your delivered work to not need revisiting or fixes (as far as reasonable).

tl;dr
Write decent code that others can read, and doesn't break every 2 seconds.

There's a few ways to do that.

Write dumb code. Not "smart" code.

You might be the wizard of Leetcode, Hackerrank, or something similar. But unfortunately these sites encourage juniors to pursue performance so hard that it often comes at a cost of readability.
It's NOT a bad idea to use a nested loop, if you know both loops run only for small values of i and j.
It's NOT a bad idea to NOT use a map/dict instead of an array if that array is guaranteed to only have a few items at max.

Learn about all the tools the language offers you.

You might be used to using for-loops for everything, but arrow/lambda functions could make your code a lot more readable.
[JS example] you might be used to storing things in an object {} for O(1) lookup every time, but set.has(thing) is a lot easier to read than !!obj[thing] (or even Boolean(obj[thing])

Understand why tests are valuable, and THEN write tests

Too often people just write tests because it's a "best practice".
Without understanding the WHY behind it, you may write ineffective or pointless tests.
The idea is, do whatever you need to, to increase confidence in the stability of your code. You need to use types? Sure. You need to hire a QA person? A bit inefficient, but cool. Maybe you need to write... TESTS? Okay, but... what do I aim for?
This can be a separate blog on its own. But here's a quick brief...
- It doesn't matter whether you need to write Unit tests, Integration tests, Acceptance tests, whatever you call them. People can get "religious" about it. But none of it matters as long as your test does the one fundamental thing... improves your confidence that your code will not break.
- Sometimes you may need to refactor your code so it's more testable, but once you do it a few times you'll begin thinking about code from a testability point of view.
- It's also a great idea to write the tests for your expected implementation before you've implemented anything at all! Resulting in a testing suite that completely fails at the start, and as you've implemented things it gradually keeps passing! This is basically what Test Driven Development (TDD) is btw.

Care about performance

No one's expecting you to run everything at 60 FPS all the time or sub 100ms latency for everything.
But be mindful of when your code may cause too many requests to the DB, or loads too much data. Don't let your component render 5 times because you couldn't figure out how to use useEffect and useState right. Ask for help where you need to, but care enough to not let this stuff reach production.

⏫ To get to SDE2:

Dive deeper into the internals of the languages and frameworks you use. 🧠 Know how React actually renders things. Understand how a browser handles multiple requests from the browser to a server. Learn how Postgres chooses to optimize a query or doesn't. Get into how your applications deployment pipeline is configured.
Ask questions about how the project, components, APIs, etc. were architected the way they were. Learn what these design patterns are called, and what their pros and cons are. Start contributing to architectural discussions and suggest improvements. Who knows? You might have ideas that more experienced people didn't consider.
Mentor others on best coding practices. You will often have people junior than you on the team. Review their code. Get your code reviewed by them and share what they should focus on. Like Yoda, your wisdom you should share. 🧠

2. Productivity [🔝]

As an SDE1, your productivity is measured by your ability to reliably complete tasks on time, manage your workload efficiently, and maintain consistent progress on your projects. You should also be able to handle minor disruptions and dependencies without losing focus or needing constant guidance.

You may often need to rely on tools or apps or scripts to do certain things more effectively. Sometimes you may need to MAKE these tools yourself.

It's okay if this feels like too much. It won't always be perfect. Even far more senior devs don't always nail this down.
You'll get there. The important part is, if you're not able to live upto your commitments, then communicate as early as you can.

tl;dr
Aim to get your tasks done well and on time. When you feel that you can't, let people know asap.

Know when do to what, and when to say NO 🙅

Learn to distinguish between what's urgent and what's important. Use tools like Eisenhower Matrix to prioritize effectively.
Focus on high-impact tasks, but don't ignore the small ones that keep the wheels turning.
LEARN TO SAY NO. Oh goodness this is a BIG one. This is so important that this could be a blog on its own. I got stories.
- You'll occasionally find yourself being overloaded with work if you're not good at saying no. People will often find it acceptable if you can simply and clearly explain what you're occupied with, and instead when you'll be able to pick up the next thing.
- If you find yourself pressured into a corner, you NEED to rely on your manager to prioritize things for you. Just ask them what's most important according to them. You saw this one coming, didn't you?

Manage your time, and don't burn yourself out

Use techniques like Pomodoro to maintain productivity without burning out. I've had many friends that use some kind of a digital or physical Pomodoro timer to manage their workday.
Track your time on different tasks to understand where you might be spending too much or too little time. A common pomodoro timer used by my friends back in the day

Automate boring work, by making your own tools if you must

Automate repetitive tasks to save time. Scripts and tools can handle a lot of the mundane stuff. I've created a whole bunch of scripts, Slack commands for internal debugging, etc. that has saved me and the team countless hours already at Middleware.
Familiarize yourself with IDE shortcuts, plugins, and other tools that can speed up your development process. If a majority of your team uses VSCode for dev, you can even agree on a common IDE config, and share that for that codebase by committing the .vscode directory to the repo!

⏫ To get to SDE2:

Start managing your projects more independently. Create realistic timelines and meet them. An SDE1 might miss timelines every now and then. An SDE2, less so. The higher you go, the more likely it should be that you finish your projects before time even!
Proactively identify and address bottlenecks in your workflow. Suggest process improvements to the team. Often you may not get the time or support to implement such improvements. A solid SDE2+ move is to just do it yourself in the bits and pieces of time you find between other work, and suddenly one day the team has some key workflow pain-points magically resolved! All because of you.
Balance multiple projects and tasks without losing track of deadlines, and understand that you don't always just meet deadlines by working 28 hours a day, you figure out ways to do the same thing more efficiently. As such, show that you can handle increased responsibility with the same level of productivity. Level up your multitasking game like Tony Stark managing his suit tech! 🦾

3. Collaboration [🔝]

At SDE1, you need to communicate clearly, share your progress, and be a helpful team member. Your ability to collaborate effectively with others is crucial to the team's success.

There are a lot of people relying on you to deliver things on time. They are your engineering manager, product manager, perhaps other managers they report to, and also your peers who are waiting for your piece of the project to be done.

People may often be understanding of something running a little late, especially if it's informed as early as possible. But what really causes issues is:

Not telling you'll be late till the last minute.
Not being clear or being VERY inaccurate about your estimates.

I still mess up on some of this. But overall things do get better. 👌

tl;dr
Be a good teammate and communicate well.

Speak early, speak often, but most importantly - listen

Keep your team updated on your progress. Regular updates in stand-ups and via project management tools like Jira or Trello help everyone stay on the same page. (I know, Jira sucks, but you have to understand that it's a pretty decent tool for your managers and higher ups to keep track of how things are running.)
Listen actively during meetings and discussions. Understand what others are saying before you respond.
Being a good listener will also get you a girlfriend/boyfriend sooner 🤣. If you don't, let's hope you pass Rule 1 & 2. 👀

Guard your production, review the code

Participate actively in code reviews. Provide constructive feedback and be open to receiving it. Care deeply about not letting poorly readable, or potentially risky (perf., UX, or security-wise) code from ending up in prod.
Learn from the feedback you receive and apply it to your future work.

If you need any convincing about why code reviews are critical, and how to do it right, maybe this will help:

The Senior Engineer's Guide to Code Reviews

Jayant Bhawal for Middleware ・ Jun 3

#codereview #productivity #learning #testing

Keep your team up-to-date with your learnings

Share what you learn with your team. Whether it's a new tool, a coding trick, or an interesting article, keeping your team informed helps everyone grow. If you're on Slack, a #engineering channel is a great place for something like this. So is #memes. 😄
Write documentation and create guides for complex parts of the codebase or processes. This helps others understand and use your work more effectively. It's SUPER IMPORTANT to remember that this documentation needs to be searchable. Documentation that can't be searched for, doesn't exist. Glean could be a great tool to help with that, but it's a paid (and expensive) thing.

⏫ To get to SDE2:

Take on a mentoring role. Help junior developers navigate their tasks and challenges. Help them plan, estimate, document, etc. Help them write their first ERDs (Engineering Requirements Document)!
Lead small projects or initiatives. Show that you can coordinate efforts and bring a team together to achieve common goals.
Facilitate communication within the team. Help resolve conflicts and ensure that everyone is heard. Every team has introverts, and it's usually them that have the hardest time communicating, help them as you can. Be the Captain America of your team, uniting and leading by example! 🛡️

4. Ownership [🔝]

Taking ownership means being responsible for your work and its impact. As an SDE1, this means you should ensure your code works as expected, handle your tasks diligently, and follow through on your commitments.

Just as a founder, or CEO must do whatever it takes to ensure the company survives, thrives, and is profitable, you must do whatever you gotta do to ensure that your work meets the timelines set upon in, and is delivered in a way that not just meets, but exceeds the bar.

Understandably, there may be times when the set timelines or expectations are simply unrealistic. That's where your communication skill needs to shine.

tl;dr
Own your work, and its quality. Finish what you start.

Maybe not like... THAT.

Learn to commit

If you commit to a task, see it through to completion. If you encounter obstacles, communicate them early.
Don’t pass the buck. If there's an issue with your code or task, work to fix it rather than blame others.

Be proactive: See something, do something

Don’t wait for problems to be assigned to you. If you see something that needs fixing, take the initiative to address it. Of course you'll need to prioritize appropriately. Not everything that needs fixing requires you to park whatever you're working on and fix it first either.
Think ahead. Anticipate potential issues and address them before they become problems. For technical or engineering related work, ERDs (Engineering Requirements Document) can help tremendously with your work planning.
Your managers may be keeping an eye on your teams productivity from their point of view, but as a proactive dev you can do the same. After all, YOU are the one who truly understands what makes YOU productive. If you can come up with a way your productivity analysis to your managers, show them that your team is actually doing well, or is blocked on things that need their attention, that gets you some serious points. DORA metrics is a fairly popular way to measure team productivity among dev teams. If you're not sure how to start measuring something like this, maybe this blog would help: What are DORA metrics?

Everyday, be better than you were the day before

Reflect on your work. What went well? What could have been better? Use this reflection to improve continuously. This would be a more personal version of the Sprint Retrospective your manager would (or should) do.
Seek feedback actively and apply it. Strive to be better with every project you undertake. Sharing feedback is also a lot of work for the one providing the feedback. It might be a good idea to block some time quarterly, monthly, etc. if your org doesn't have a process defined for this.
Try and follow the Boy Scouts rule, which basically states that you should leave a codebase better than you found it. Read more here.

⏫ To get to SDE2:

Drive projects from start to finish. Take on tasks that require you to plan, execute, and deliver with minimal supervision. If you prove yourself to be self-capable enough, your manager might let you supervise a couple more devs to execute the project. Now THAT is some Senior Dev stuff. 💪
Identify and implement improvements in processes, tools, or codebases. It's been mentioned before too, but here the focus is slightly different. Show that you’re looking out for the bigger picture and contributing to long-term success of the org.
Advocate for best practices and ensure they are followed. Be the Batman of your projects—reliable, vigilant, and always delivering excellence. 🦇

5. Impact [🔝]

As an SDE1, your impact might be limited to the tasks and projects assigned to you. However, demonstrating a broader understanding and contributing beyond your immediate responsibilities can set you apart. Impact is not just about what you do, but how your work influences and benefits your team, your project, and the organization as a whole.

tl;dr
Make a difference. Don’t just do, but improve.

Don't be limited to "your job"

Learn about the business and the industry you’re working in. Understand how your work fits into the larger goals of the company.
Identify opportunities for improvement or innovation. Suggest enhancements that could benefit the team or product.
Pay attention to the end-users of your product. Understanding their needs and pain points can guide you in making more impactful contributions. Don't just build whatever you're asked, but also analyze how successful your efforts have been for the users, and the org.

Contribute to the Community

Participate in internal and external developer communities. Attend meetups, contribute to open-source projects, or write technical blogs.
Share your knowledge and expertise to help others grow and learn. Organize or speak at tech talks, webinars, or coding bootcamps.
Engage with other teams within your organization. Offer help and collaborate on cross-functional projects to broaden your impact.

You may not be "asked" to help your community at your job 🤣

Be Proactive in Problem-Solving

Look beyond the immediate requirements of your tasks. Think about how your solutions can benefit other projects or future work.
Develop a habit of thinking critically about the tools and processes you use. Propose and implement improvements that can save time, reduce errors, or enhance performance.
Don’t wait for someone to assign you impactful work. Seek out opportunities to contribute meaningfully, even if it means stepping out of your comfort zone. Sometimes you may have to rely on third party tools to identify problems in your processes. Tools like Middleware would let you spot issues in your software delivery. Now THAT is a senior dev move.

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Join our Open Source Community

Introduction

Middleware is an open-source tool designed to help engineering leaders measure and analyze the effectiveness of their teams using the DORA metrics. The DORA metrics are a set of four key values that provide insights into software delivery performance and operational efficiency.

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

View on GitHub

Innovate and Improve

Stay updated with the latest trends and technologies in your field. Experiment with new tools and approaches that could benefit your projects.
Think about scalability and maintainability in your work. Design systems and write code that can grow and evolve with the needs of the business.
Encourage a culture of innovation within your team. Promote brainstorming sessions and hackathons to generate new ideas and solutions.

⏫ To get to SDE2:

Start thinking strategically. Identify ways to make a significant impact on your team’s goals and the company's success. Look for patterns in your work and the work of your team, and suggest improvements that could benefit everyone. Most people aren't too good at this, so if you can pull this off it'll absolutely set you apart.
Lead initiatives that drive innovation and improvement. Show that you can think creatively and come up with effective solutions. This might involve proposing new features, optimizing existing systems, or improving development processes.
Champion new technologies or methodologies that can enhance productivity or quality. 🚀 Take the lead in integrating these technologies into your projects and mentoring others on their use.

Remember, levelling up from SDE1 to SDE2 and beyond is a journey. Focus on what you can control, seek feedback, and keep improving. Your growth as a developer is a combination of technical skills, productivity, collaboration, ownership, and impact. With dedication and effort, you'll not only level up but also enjoy the process of becoming a better engineer and a valuable team member. Game on! 🎮

P.S.: Senior engineers are good at identifying all kinds of problems that prevent their teams from delivering on time, without compromising on their output quality.

Some of them use tools like Middleware.

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Join our Open Source Community

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

View on GitHub

Top comments (10)

Amogh • Jun 12

I think this should help someone get some metrics but should also provide a guidance on what should be probable actionables.
I am like ok, these are my metrics but now what? I think showing metrics is good as it saves time in gathering information and build data on them but real goldmine would be insights along with actionables, if one can provide.