Deleted 2 days of work and no backup

Question

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?

Answer 1

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?

Answer 2

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

Answer 3

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.

Answer 4

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.

Explain:

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

Answer 5

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.

Answer 6

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!

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.