I deleted work I was doing and I didn't add it to SVN, I have a performance review tomorrow and I already mentioned that I am stressed, thus slow progress. Now with this problem, should I tell my manager? I can do it, but if I cannot, do I have to report it in the daily scrum? How do I explain to the manager what happened?

  • 3
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    May 4, 2018 at 9:44

10 Answers 10


This is a very unfortunate situation but since you can't change it anymore, make it a valuable experience.

Do I have to report in daily scrum?

Yes! If you are scared of telling this to your team, start with your scrum master or product owner. Transparency and honesty is one of the key elements of scrum. You are responsible for the team and the team is responsible for you. Discuss the issue with your team, they need to re-evaluate the schedule and story points and can help you clean up the mess.

Do I have to tell my manager?

Never lie to your manager. If she/he asks, give the honest answer. But make sure you have a follow-up answer ready. How are you (and your team) going to fix this? How will a similar problem be avoided in the future?

  • 67
    If it helps, you can start with 'I learned a very valuable lesson today' . . . Then try to recreate the work as efficiently as possible and start with adding the files to version control instead of waiting to do it towards the end of your effort.
    – LeLetter
    May 3, 2018 at 18:27
  • 4
    Also, if there is a need for central backup organised by IT (not just of your machine but others), this might be a good time to take lead and address that need. May 3, 2018 at 21:13
  • 4
    @Paul in addition, once you know what you're doing it should be even faster to recreate it. Some even suggest you solve a task and then start again and re-solve it because you'll be more efficient (you know how to do it already) and more careful (you have spare attention to watch out for bugs or problems). Although the recommendation is usually for small scale stuff, not two days of work but it still holds some water.
    – VLAZ
    May 4, 2018 at 0:33
  • 1
    @rackandboneman maybe, but OP should tread carefully. They may be perceived as trying to shift the blame, which rarely goes down well even if it's a fair position. I'd say it's a conversation best left for later. May 4, 2018 at 6:48
  • 3
    Indeed..Never never lie..i worked with a develop on a project before who lied about bugs,etc.. horrible team mate. folks will appreciate the honestly.
    – Jeryl Cook
    May 4, 2018 at 15:30

I find it usually best to own up to your mistakes, both to your team in the daily standup meeting and to your manager. The performance review has a little bit of a bad timing now, but if this is the first time you made a mistake like this, I don't think it will be a huge problem.

I would do my best though (and communicate) to make up for lost work asap since it is your fault and make a habit of saving to SVN regularly


A couple things....

First, at least in my experience, your performance review was probably completed weeks ago and there is a reasonable chance it was reviewed with other people before you'll even get to see it. Particularly if it's tied to a salary adjustment. If you are worried about this ruining your review, you are probably in the clear (though, it might come up for the next one).

Second, deleted files aren't necessarily gone, the data is likely still on the disk. At the very least, I'd run some recovery software. If you are more technically inclined, shut down, boot from some external media and use a tool to scan the disk for lost files. I mean, depending on what level of access you have to your workstation. If you are in a situation where you can't or you don't know how, it might be worth reaching out to the IT folks who have probably dealt with this before.

Finally, as a former manager, the worst thing you can do is try to hide it. People make mistakes, not communicating it makes it a bigger mistake. As soon as you can have an uncomfortable talk with your manager. Explain what happened, explain how you understand your mistake and how you will ensure this will never happen again.

Hey Boss - it looks like I made a mistake and accidentally deleted about two days of work. I failed to commit/backup/stash any of my changes to source control; I know I should have and I'm truly sorry. In the future I'll be a lot more careful and make sure this doesn't happen.

I know we have a tight timeline and I want to do everything I can to improve this situation. There is a chance the deleted files are recoverable, would you like me to try and recover them using 'undelete' software, or talking to someone from IT? Otherwise, I'll do my best to redo my work, it shouldn't take me two days since I just worked through it, but it will add (however long you think) to my timeline.

  • If it's text files, they'll be difficult to locate, but grep will do the job on a raw block device. May 4, 2018 at 16:00
  • +1 for the "deleted files aren't necessarily gone"
    – Nav
    May 5, 2018 at 14:29

It's time you learn one of the most powerful tools any employee can ever use.

Asking your co-workers for help.

I understand the fear - you made a big mistake, and you're worried about the repercussions. And you don't know if there's any way to recover from this mistake.

Which is why you absolutely need to report this issue as soon as possible - and thoroughly as possible - to your supervisor, and ask for assistance.

Don't just say "I made a mistake and now the work is gone, help!" because that looks awful. Instead, lay out exactly what you did, and don't make excuses.


  • What you were doing (whatever work you were attempting to do)
  • What you did just before you lost the work (this is Very important)
  • The steps you took to try to recover it (You must state these so that you can show you made a good faith effort to resolve this yourself)
  • A request for help (If you know someone who is 'good' with this sort of thing, you could ask for their help by name)

By explaining what happened and how, you're also helping to solve the issue by giving that information to whomever is going to help you solve it. And by explaining your steps to fix it yourself, you're showing that you made an honest attempt to correct it.

Most importantly, by admitting you made a mistake, you show that you are mature enough to look past embarrassment about mistakes and seek out the answer to the problem. That's not just good work ethic - that's the essence of maturity.

  • 5
    That was not a big mistake, but a middle-size one. Losing two days of your own work is annoying, but it happened to all of us perhaps once. May 4, 2018 at 15:08
  • @BasileStarynkevitch The first mistake of this size always seems like a big mistake - but it's important to learn how to recover from a mistake of any size, big or small.
    – Zibbobz
    May 4, 2018 at 15:19

As someone who has done this in the past, here's what I now do to mitigate the chances of it happening again.

  • First off, tell your manager, and explain what you're going to do to prevent it in the future. They have the right to know what happened, and while they won't be pleased about it, if you've got a solution to prevent it in the future, they (should) look upon it as a valuable lesson learned.
    Going to your manager with a problem but no solution in mind is largely wasting their time. Their job isn't to solve your problems, it's to remove obstacles so you can solve them on your own.

  • As others have noted, commit your changes frequently if you can. However, my company has a rule where you can't check in code that doesn't work, so what do you do when you have intermediate/interim code that you don't want to lose? Backups. I have a spare drive in my machine that I have an automated backup running to. It basically takes a snapshot of my working drive nightly. I also manually back up to a network drive (that itself gets automatically backed up each night). I run a little backup script as I leave each day, and it does an incremental backup to my existing files. Then I carry a USB stick with me that I also back up to about once a week.

  • There's some truth to @James answer even though it's been heavily down voted. It is (generally) far easier and faster the second time around. You know what you want to write, you've gone through the thought processes to get to where you were going, so it's easier to remember than it is to do it the first time from scratch.

  • That said, I completely disagree with "These things happen all the time. Don't worry about it.". It really should only happen to you once, which is your learning mistake, then never happen again because you now have a mitigation plan in place. Continuing to make similar mistakes is the sign of an amateur, as a professional, you have a duty to your company to learn from mistakes and carry forward, not repeat them.

  • 3
    "However, my company has a rule where you can't check in code that doesn't work, so what do you do when you have intermediate/interim code that you don't want to lose". That's a pretty horrifying rule, but I assume what is actually meant is "don't commit non-working, untested code into branches shared with others" - which is a great rule.
    – Voo
    May 4, 2018 at 7:37
  • 6
    The solution then isn't to make every developer roll out their own backup solution, but to educate people on how to create their own feature branches. Every popular source control system of the last 20 years is capable of doing so, even if some like SVN or TFSVC make it more cumbersome than others.
    – Voo
    May 4, 2018 at 7:39
  • @Voo The OP uses SVN (this is centralized version control, not distributed version control like git.) A junior dev likely won't be able to create a private branch on the central repo, let alone squash and rebase non-working commits into working commits. In any case (and especially this case) source control is not a substitute for backups. So +1 to delliottg
    – Qsigma
    May 4, 2018 at 12:58
  • 3
    @QSigma Why wouldn't you give your devs permission to create new branches? That soundslike an awful practice with absolutely no upside -there's no harm in creating branches (you do want to agree on a naming scheme for your branches to avoid conflicts, but the same is true for a DCS such as git). Whether the OP has permission to merge changes directly into the master branch is a different question (preferably there's a review process that requires signing off by a team member), but wouldn't matter here.
    – Voo
    May 4, 2018 at 13:34
  • 3
    And why is source control that is pushed to a central server that is securely backed up by the responsible department not a backup? I've never worked at a company where we had to use USB sticks to make backups of code (matter of fact I've worked at companies where for security reasons doing so would've gotten you fired). Everything you need to get a project working should either be checked into source control or be available from other central sources - private backups are pointless if someone else has to continue working on your project, they will need all this stuff too!
    – Voo
    May 4, 2018 at 13:35

I would fess up - "I deleted 2 days of work, but I think I can recover it in 1 day".

I think you should be able to recover it in one day, we have all deleted work by mistake (especially when under pressure) and it usually does take less time to type it out again than the first time, as less thinking is involved.

There may be some automatic backup that you are unaware of that enables your manager to recover your work (unlikely with git but you never know.)

Your performance review is based on (I am assuming) minimum 6 months work so I really wouldn't worry about it. Also, performance reviews are (unfortunately) only vaguely related to pay raises!


It's just another problem to solve; show that you are solving it

should I tell my manager? How do I explain to the manager [or anyone] what happened?

Depends on the manager. My manager wouldn't want to hear about details like that.

If your manager does want to hear about things like this, you should tell him. Keep it technical-- you didn't "screw up," you had a "code management issue" that you are resolving, with process enhancements to avoid the issue in the future. The issue was accidental deletion. It happens. You don't have to make it a big deal, and he probably won't. Just make sure you have a concrete and credible plan to avoid it in the future.

I can do it, but if I cannot, do I have to report it in the daily scrum?

In your daily scrum, you have to report what you did yesterday, what you are working on, and if you have any impediments. Yesterday you were coding the feature. Today you will continue to work on it. You don't have an impediment-- you can move forward without outside help. You aren't really obligated to say why it's taking you so long, unless someone asks.

When I lead a team, I like to give the developers a bit of privacy in this respect, since sh*t does happen, and as long as you hit your targets and don't need help or coaching with a chronic problem, the rest of the team doesn't need to know the details. Your lead may be different, so follow his lead.


It just happened to me recently, on something that was needed in a deadline. It was a new project so I should have added it to git but didn't. Thankfully it was a maven project with a distribution folder and the java war was there, so I de-compiled and remade the project. I did tell the PM but also told him I have solved it. Two days of productivity can be (sometimes) replicated in lesser time, so don't worry that much as you have already done it.

(Edit) What I failed to mention before, , come in clean. If you have deleted something and there is a possibility that it could be delayed then its better to come clean and notify your manager. I would suggested first try to find out how long will it take to replicate your work so you have a problem (lost code/rework needed) and a possible solution as well.

  • 1
    While a related experience, I am not sure that this answers the actual question. May 4, 2018 at 16:02
  • @MadPhysicist : true, i added an edit
    – sarmahdi
    May 6, 2018 at 11:06

Programming is a lot about planning and understanding code and the underlying specs.

Even if you spend 2 days on writting it, you should be able to complete it again in a lot less time.

Owe up to it, make sure to explain you will need a lot less time and that you're willing to do overtime to compensate, if necessary.


Once the problem is solved: It looks like a good time to review your backup plan on a larger scale.

A wize man once told me:

"In a good Infra, you have to do the elevator test."

With the sound of an elevator trying to brake from a 12 floor fall.

In most country reglementation on elevator is strict. The security of an elevator is basicaly build around:
Detector > Eletrical Safety > Manual Safety

The test of an elevator is really simple, We are going to test our security feature one by one. Trying to make it touche the ground (The spring on the bottom have to be test too) with the following test.

Free fall at full speed + full loaded -> trigger detector.
Free fall at full speed + full loaded -> without detector to trigger electrical safty.
Free fall at full speed + full loaded -> without electrical safty to trigger manual safty.
Free fall at full speed + full loaded -> without safty , it's cranked.
Same with over speed -> into the spring.

How many have ever test the back up, after a full wipe, just to be sure that the back process is ok?

On backing up work their are few step that could be follow:

backing the project with SVN etc. backing the working computer with Dpm etc. and backing things outside.

I have see society able to survive flood, fire, and malice. Beeing able to save ones work even if he had an heart attack. Able to recover from one dev going rampage the tfs/svn.

It's not about mistake, you should just not be able to do that even if you wanted to. At the end of the day comit or not the computer state must be safe.

  • 3
    This is not an answer to the question at all. Telling someone "don't get hit by lightning" isn't useful when they've just been blasted by the sky.
    – user53718
    May 4, 2018 at 10:21
  • For me the question was : i burn my finger, what should i do. My answer is: when its fix. Try to make your house more safe for fire water and lightning May 4, 2018 at 10:25
  • 3
    Your post doesn't answer the question at all, then. "What should I do about my burnt finger?" does not get answered by "once your burn heals, don't put it in the fire".
    – user53718
    May 4, 2018 at 10:55
  • 2
    This answer would be helpful on a more technical-oriented website. This website, however, is about the human component. The question is not "how do I prevent this", the question is "how do I tell my manager what happened without screwing myself over in the next performance review.".
    – Philipp
    May 4, 2018 at 11:07

You must log in to answer this question.