Ask HN: Is it bad to admit mistakes you made as a SWE? | Hacker News Reader

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

15 pointsnumbers24 comments

Recently, my manager has been using my basic mistakes (like not understanding a code base that I'm brand new to in a new language) and using that as a talking point of "you're not performing as well as your peers".

I thought making mistakes as a SWE is part of the job. We can fix things relatively quickly and in most cases nobody gets hurts or loses money, but I'm starting to wonder if I should keep my mistakes to myself?

Edit: I should explain my manager is relatively new to the role.

View on HN

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.

Before posting this question, I was seriously doubting my own abilities but over the last day or so I’ve been thinking over this and it does seem like it’s time for me to look for a different place to work.

I have worked at many other jobs where what you’re describing has been the culture of the team, helpful and understanding teammates who want to do good work. My manager has been overly aggressive about pointing out mistakes.

> "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.

Thanks, I am going to work on creating clear steps to avoid making the same mistakes. I am already taking advantage of unit tests are built in type checking but will look for other ways as well.

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.

this.

your superiors are either fighting to keep you or fighting to fire you.

your gut feeling may speak a lot on where your situation is heading.

also, it may not be your code that is the problem, but other things too like office politics.

there are just many nuances to consider to give a well informed advice over the internet, but being prepared on any outcomes helps a lot, and reflecting and seeking feedback from other people (like this thread) to explore your options is great too.

i wish you well in your journey.

Thanks Joshxyz and throwaway, this has been a feeling I’ve been having recently. My manager has been taking steps to write out any interaction we have so I’m sensing something bad brewing.

My assumption is there's a PIP or PIP-like event coming up. When that happens do your best to satisfy the requirements but also look for a new job. They're going to want you gone if they PIP you.

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.

It depends on your knowledge level, I wouldn't be loud about mistakes that are part of your learning experience, especially on your local, and about things you might not fully understand. This could be more problematic.

If you find a mistake that is committed to the repo, own it, make a PR to fix it and document it in the PR, if it's knowledge that can help other add to wiki.

Same if someone else points out a mistake or recommended change. Explore the issue, research it, understand it fully so it doesn't happen again. Fix it, setup PR.

If it's not in the repo yet make the fix as part of your PR for that feature but I wouldn't air my dirty laundry. Adding something to the wiki or documentation to help others would be a good idea but you don't have to spell it out as a mistake.

You should leave Amazon.

Funny you say that, my manager is from Amazon!

"motivating" employees by negging them is apparently in the amazon managerial playbook. And they normalize the behavior by saying "Well... Amazon is a place smart people go to feel bad about themselves."

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.

Reply on news.ycombinator.com