Is it bad to admit mistakes you made as a SWE?

If that's the whole story I'd consider leaving. It took me a long time to realize that there are workplaces that are not "collegial" in the sense that instead of acting like a bunch of people trying to do good work, who are all flawed but support each other, you get situations like you describe where superiors or colleagues are looking for things to pick at you for. It's not a good place to be. Try and make sure there's not some legitimate blind spot you have that's causing you to do something unnecessarily dumb, but if it's just getting hassled for course-of-business mistakes, I wouldn't take it.

> "but I'm starting to wonder if I should keep my mistakes to myself?"

My take is that you should always "own your mistakes". In my experience, the people who never seem to make mistakes always have someone else to blame...

The important part is to try your best to prevent the "same mistakes" from happening again. This means improving the system and your own workflow to prevent mistakes from happening (creating bugs, accidentally deleting data, etc...)

Also, "not understanding a new code-base or language" isn't a mistake, it's part of the onboarding process and good management should be empathetic of that.

Perception is key, I wouldn't air your own dirty laundry.

We all make mistakes as SWE.

As a lead developer there are times I see mistakes that a Sr. or Jr. makes and it reveals the limits of their knowledge and skills.

This is concerning, as you lose trust in that developer and this affects what tasks you are willing to assign to them. Which makes them less valuable to the team. Causes you to spend more time reviewing their PRs.

These 'costs' do lose the company money through lost productivity.

It sounds like you're new to a code base and lang so take some extra time to learn and investigate as you're working on a task. Be curious, explore and learn.

Review your code before you setup a PR. Test your code locally. Does it meet all the requirements. Are tests passing. Did I add enough tests? Could I bulletproof it further? Are there any areas we could improve performance or make other improvements I could recommend as a future card/task to my mgr?

Every team has different levels of SWEs regardless of title or even experience.

So not everyone is going to perform as well as everyone else.

You just want to make sure you're not at the bottom.

Be curious, keep learning, be positive, get tasks completed and working properly and you'll be fine.

(edit) definitely own your mistakes, we all make them, make sure they are a learning experience.

Mistakes always cost money in terms of engineering hours spent fixing those mistakes. The feedback was poor and unacceptable from an engineering manager if the concerns are not backed by factual information and critical feedback to help steer you in the right direction you will not be able to grow.

In terms of your own self-improvement improve your internal processes for learning the code, and testing it before sending it off for a CR. Adding test cases for the work you do will help improve the quality of your work and enable it to be integrated easier into the overall codebase. If you need help or find issues with the code try to get clarification after spending time deep diving and learning and being curious (e.g., exhausted all other options).

Also note you can probably create your own dev pipeline so you can push to your hearts content and not break things, then only when things are working as expected submit a CR for others to review.

Your manager is building a case so they can fire you. I would start interviewing if I was you.

Maybe that's not what will happen, but it's good to have a backup.

You have to make mistakes to get better. It’s a good habit to say hey I made a mistake, here’s what I learned, here’s what I’m going to do differently. Not just for work, but life in general. No harm in mistakes as long as you learn and don’t make the same mistakes over and over again.

I'm pretty sure it's not good management policy to encourage employees to hide their mistakes.

I just recently experienced this as a head count trimming qualifier without severance. Fortunately, I have a side career, a plan B, that is capable of paying all my bills.

As an individual contributor (not management) you are at the complete mercy of the employer. If they are a mess, then you will be a mess. If head count trimming is about to happen there is nothing you can do. If not you then it will be one of your peers that gets pushed out but unless leadership (not you) radically shifts directions your time is ultimately limited.

My suggestion:

Recognize the symptoms. I saw the writing on the wall months ago and ignored it. I kept making excuses like how great their culture is and how this won’t happen. Stop making excuses. I have been writing software long enough to fully understand the economics of the situation and should have applied more common sense earlier.

The moment economic pessimism starts to creep in engage the planning stages of a back up plan. Once the signs of head count reduction start you are way behind where you need to be. At that point you should be ready to execute as fully explored plan B immediately.

Things to consider:

* Save money. Always have enough in savings for 2-3 months of unemployment.

* Be looking for a pivot. Consider getting a PMP or CISSP. Certs are irrelevant and ignored by your software career, but they make for a nice exit plan if you need it. Once you have those you just need to maintain them.

* Write. Start a blog, a personal diary, or anything else. Always be improving your communication skills. This can help you transition to the next stage in life when all else has failed.

* Build professional relationships. This is critical if you want to do other things later in life, such as business or consulting. This is my biggest failure as I have dedicated all my time to family and technical mastery. I have no regrets here, but I am limited by this.

* Consider more education. I am thinking about grad school and moving away from software towards business operations positions.

If the "you're not performing as well as your peers" stopped there, consider mentoring your manager on what it means to be a manager. Explain that they should help you with constructive ideas that will help you perform "as well as your peers" (what that means and how objectively it is measured is also important).

If you're feeling cynical, you can tell your manager they are not performing as well as you expected them as a manager. Leave it at that and ask how they feel about it. /s

Making mistakes is unavoidable, but isn't part of the job.

Learning how to reduce the chance of making mistakes in the future is part of the job. When you make a mistake stop and think why you made the mistake and if there was something you could have done that would reduce the chance of making that mistake in the future.

So if you made a mistake because you're new to the codebase and language then do more pair programming with the people on your team who really understand how it works.

Telling someone straight "not performing as well as your peers" is quite brutal and not necessarily conducive to your performance increasing over the future.

If that is said in public, I wouldn't be happy about the situation, in private, I might chalk it up to the person not knowing how to manage performance.

Don't keep your mistakes to yourself when you require additional help to get over them. If you notice these mistakes and can clean them up by yourself, then get them fixed and move on.

learn branding. Everyone needs branding. first, you need to fix mistakes and learn to improve your knowledge over time. second, you need to improve the perceptions of how other people view you (branding). You're the only one responsible for your own well being. Not every one will always get a good boss. it is a tech pipe dream. The real world is a brutal place. learn how to watch out for your own interests.

I think it is unhealthy to be in an environment where mistakes are weaponized.

But keep in mind that 50% of managers are below average, and that means a significant fraction of new managers have only experienced below average managers...and a significant fraction were selected by below average managers.

But also, it is possible that what you heard is not what was said...or what was meant.

Good luck.

If your manager is giving that feedback in /private/ and depending on how he is delivering it.. it might be OK.

If he is doing it in public, then that's not OK.

You shouldn't keep your mistakes to yourself, no. In fact go as loud as possible about them, and what you learned from them. Make a google doc and share so others don't do the same.

You should leave Amazon.

You said: "…[I] wonder if I should keep my mistakes to myself"

You know your code is buggy, that's not an honest mistake. So fix it, don't hide it.

---

BTW, I don't agree with how your manager told you that.