If you're a software engineer, your main job is maintaining legacy code. Why? Because building a system doesn't take long, in comparison to how long code will last, assuming the code/business are successful. Here are the 10 commandments of maintaining legacy code. 🧵

Absolutely love the “toilet paper roll test” from @scarletinked’s latest article. If you are at someone else’s house and notice the toilet paper roll is backwards - would you fix it? The very best employees are the ones who would fix the roll.

So while suck it up buttercup isn't particularly nice, it's more catchy than "Focus on your goals, and what you can do to achieve them." Love you all. For more, read on! https://t.co/1XQBOooBw8

When you focus on what other people are doing, you're spending your energy on something you can't change. When you focus on what you can do, you're spending your mental energy on finding paths to success, opportunities, or choices you can make.

Two - Maintain an internal locus of control. Identify what you can do, not what others should do. Instead of: "My boss should recognize I do better work!" try "What can I do so that my work is recognized?"

One - Focus on what you want, not what happened. Instead of: "It's unfair my co-worker is paid more!" try "How can I increase my pay?" It feels obvious, but I don't know how many times I've heard people rant while not taking the simplest steps to achieve their goals.

The world isn't fair. We've heard that often enough. But beyond the "suck it up buttercup" sentiment, is there something valuable to be gained here? I think there are two things to think about.

When you try to verify what others believe are facts, you're slowing them down. You get pushback and dragging feet. What you also frequently find is that things aren't what they seem. For some great anecdotes from Amazon on this topic, read on! https://t.co/ARZMcC2eBA

However, everyone is busy. The easiest thing is to just trust and skip the verify step. I believe those metrics are telling us the right story, so we should do X. I'll just execute on our processes to achieve Y. I'll assume these few things, so I can make progress on Z project.

One of Amazon's frequently quoted mottos is to trust yet verify. You assume the best intentions from people. You assume that they're competent. Yet, you still verify because everyone makes mistakes. You never want a great excuse for a failure.

It increases the number of high-quality hires, improves the experience for candidates, and trains the next generation of interviewers. For much more on the process, read on! https://t.co/UYnzvXbEXa

The Amazon Bar Raiser process is how one of the world's most prolific hiring pipelines scales. And unlike Amazon's performance management system, I think most employees love the bar raiser process.

5. Significant disagreements rarely revolve around code. Managers make a group of individuals a team. If anything, being deep in the technical details would make you less capable of being an impartial leader. I love this topic. For more, read on! https://t.co/lk3xSJMDbq

4. The manager needs to be the interface between engineers and the business. Managers need to create the highest business value with their team's work. They turn product and engineering requirements into optimal value. Hard to be an arbiter if you're working on implementation.

3. What you build is more important than how you build it. It's hard for managers to focus on both execution and the why. Those managers overly focused on detailed engineering are the ones without the time to ask critical questions.

2. Managers must grow their team members. If the manager is leading implementation, what do the senior engineers on the team lead? How do they grow?

1. How you build something is rarely how you fail. How do projects fail? They misunderstand customer needs, or they fall drastically behind schedule. This isn't due to coding speed, it's due to leadership issues.

As a junior manager said to me at Facebook, "How could you earn the respect of your team if you weren't the best coder on the team?" That alone should be a warning sign. Why shouldn't managers code?

When I interviewed at Facebook / Meta years ago, I had to take a coding test as a part of the hiring process. Thankfully my rusty coding skills didn't prevent me from getting an offer. But the idea persists in places that engineering managers should code.

Amazon expects their engineering managers to run projects, mentor employees, design systems, architect platforms, manage operations, communicate with customers, and evolve products. But they don't expect them to code. However, that's not true of many companies.

Instead, unravel the complexity and find root fixes which solve the root causes of the issue. For more, read on! https://t.co/DTed7uQyCE