I've been working on a SQL dashboard project whereby I modified a template script.

I became stuck on part of the project and asked for help from a senior colleague (on the same level as my manager but I don't report to him).

He made a clumsy mistake of copying and pasting the template over my work. That is, he replaced the file with the template, saved with the same file name, therefore taking the project back to square one*.

Since then, I've put in extra time to bring the project back on track, but I want to know:
How do I approach my senior colleague to ensure that he doesn't make the same mistake again?

* I've investigated the possibility of recovering the old file, but IT have informed me that is not possible.

Edit I appreciate the value of a version control system. We don't have one and I don't have the ability to download anything to my work computer, e.g. git.

For context I asked How to deal with IT help desk that does not acknowledge requests for help? which highlighted that my employer is very process driven, and those processes are imperfect.

If I proposed a version control system today, it would take over a year to be implemented.

  • 78
    It would be better to change the development environment so that it couldn't happen again, or, if it did, that it wouldn't matter. Oct 11, 2016 at 9:25
  • 114
    Don't be shy when you are in your right to correct someone else, even if he is a senior colleague. This is a rookie mistake. Another rookie mistake is to work without source control.
    – Maarten
    Oct 11, 2016 at 9:34
  • 53
    Approach yourself and ask yourself why do you not use source control. It takes like 1 second to initialize local git repository. Oct 11, 2016 at 11:45
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Oct 13, 2016 at 9:08
  • There will always be human error. You can't avoid it. The best way to deal with it is to adopt working practices where it is harder to make errors or where it's built into that human error has less impact. For instance, before GIT I had a script running that backed up my work every half hour alternating over 2 backup locations. So if ever I made a mistake or my office would burn down I could always roll back and never lose more then an hour of work.
    – Pieter B
    Oct 13, 2016 at 11:56

7 Answers 7


Accidents happen. Even though we can put processes in place, there's always going to be room for human error.

To answer the question here, you should speak with the guy who made the changes and say what's happened. If he asks you why you didn't retain a backup of your last script, you're perfectly entitled to ask the same question in return. Looks like you both assumed the other had a backup and didn't ask. The fault ultimately lies with both of you.

Obviously, if this creates more than a small delay to the project, you'll need to raise this with the PM (if applicable). Covering up for problems (yours or others) can create more problems than they solve.

  • 59
    Also pitch the use of Version Control when approaching the PM!
    – T. Sar
    Oct 11, 2016 at 16:48
  • 5
    Even a simple Dropbox folder now offers version control, so there is NO excuse to not have it.
    – Nelson
    Oct 12, 2016 at 1:59
  • 25
    @Nelson a simple Dropbox folder also shares company owned data with a third party company with whom your company does not have a privacy agreement. Don't do that!
    – simbabque
    Oct 12, 2016 at 9:13
  • 4
    @simbabque obviously you shouldn't host company data on Dropbox, but the implication is valid: even a simple file host is implementing version control, there's really no excuse for not using it.
    – Cronax
    Oct 12, 2016 at 9:54
  • 2
    No, the senior guy assumed the OP had a backup. The OP knew for sure it was the only copy, and let someone ruin it anyway. Oct 12, 2016 at 14:06

Simple solution: make backups, especially if anyone else might be working on your stuff. This should have been a very very minor problem. Take responsibility for your work in future.

Most people have either made a similar mistake themselves or know about one. The thing is to learn from it. Even this late in my career I had a laptop stolen which held the only copies of about 2 years worth of research. Luckily it was just a personal project but it might have become lucrative eventually.

There's not a lot of point in recriminations; it's best to address the problem proactively and make sure it can't happen again.

All three people are at fault here: the OP for not having a backup; the colleague for not backing up before making changes; and the one person who really really should know better, since he is the backstop: the IT guy who can't retrieve the file. Where are his server backups?
Staff make errors like that, it happens. But I can bring back files that were deleted 5 years ago, for my clients, because their stuff is regularly backed up and archived.

As far as confronting the colleague, I'd let him know, but I wouldn't make a big deal out of it, or try and give him all the blame. I'd say it in a constructive way which might possibly help me. "You've overwritten the file with a template, did you make a copy of the file? There was a heck of a lot of work in it I don't want to have to redo."

  • Comments are not for extended discussion; this conversation has been moved to chat. Oct 11, 2016 at 17:20
  • 1
    Your penultimate paragraph is the most important, and maybe should be brought to the top. This type of situation open happens when there are multiple levels of failure: the victim, the actor, and whoever is responsible for tooling standards.
    – corsiKa
    Oct 11, 2016 at 21:28
  • 1
    @MonicaCellio The comments you moved were relevant to both the question and this answer as they addressed backup methods that would help the OP avoid a similar situation in the future. Oct 12, 2016 at 12:47
  • 1
    @RichardU were they answers in comments? Comments that would help improve the question or answer? Or just helpful advice, which I relocated (so it would remain available). Oct 13, 2016 at 1:19

This happened to a colleague of mine. First he sent an email, saying "you overwrote my changes by accident, and that caused us a lot of problems. Please be more careful in the future". The second time shortly after he sent an email "You have overwritten my changes for the second time. If you disagreed with my changes then contact me urgently, because I strongly believe that these changes are needed. If this happened by accident, then don't do this again". CC'd to his own and the other guy's manager.

(That was with a source control system in place where this shouldn't happen by accident, but only if other people's changes were intentionally overwritten. And my colleague's change fixed a rare but a bit critical bug, and he thought he had fixed it just for complaints about the bug coming back. Twice. ).

  • 3
    So there wasn't a comment against the change to explain how important it was in fixing the rare bug?
    – uɐɪ
    Oct 11, 2016 at 13:21
  • 5
    In this kind of situation a phone call is much better than an email because you want to be sure that the recipient fully understands what has happened. Face-to-face communication even better. Sometimes passive-aggressive emails do more harm than good, even if the intention is good.
    – UpAllNight
    Oct 11, 2016 at 15:28
  • 6
    What source code control system lets one user overwrite another users's checkins, making the original code inaccessible?
    – Johnny
    Oct 11, 2016 at 16:12
  • 4
    @Johnny: git push --force
    – eckes
    Oct 11, 2016 at 19:53
  • 7
    @Johnny: Not inaccessible - but removed from the current version without telling anyone. Boss: "Please fix this bug. " My colleague: "It's fixed". Someone else: "I'll just overwrite these changes..." Boss: "You said it's fixed, but it isn't. That's unacceptable. ".
    – gnasher729
    Oct 11, 2016 at 20:32

The fact that someone copying and pasting the template over your work creates a real problem suggests that your computer setup is bad. If there's no automatic backup of files it's the problem of the IT department and the IT department should change it's policies.

Simple software like Dropbox does automated file backup.

  • 3
    Dropbox is a syncing tool, not a backup tool.
    – Maarten
    Oct 11, 2016 at 20:18
  • 4
    @Maarten Dropbox keeps old file versions (and allows to revert to them) for up to a month even in the free version. How is that not a backup tool?
    – Voo
    Oct 11, 2016 at 20:39
  • 1
    @Voo Simple. Dropbox keeps, as you say, old file versions for individual files. It does not offer a way to retrieve a complete folder from a specific point in time. Not much use if you need to retrieve 100s of files which were muddled up. I'm not saying Dropbox can't be used to recover an individual file. But Dropbox is not a backup tool.
    – Maarten
    Oct 11, 2016 at 21:05
  • 3
    Dropbox is also a third party software. Using that for company files especially in a corporate environment without permission is a sure way to get fired.
    – simbabque
    Oct 12, 2016 at 9:19
  • 1
    @simbabque : That's why I wrote "The IT department should change it's policies".
    – Christian
    Oct 12, 2016 at 10:01

It sounds like there are serious issues with your organization. I've worked at places where overly simplistic IT policies (like not being allowed to install anything) actively prevented me from doing my job as a programmer.

There are several options here, in order of desirability:

  • Push for organizational change
  • Push for change for your team or yourself
  • Keep manual backups
  • Break the rules
  • Leave

This is an ideal time to work with your manager to write a business process proposal for switching to using version control. Even if it takes a year, start the process, because a year passes faster than you think.

You can likely also get permission from your direct manager for your team, (or yourself) to use version control that does not require installation. Specifically, there are versions of Git that don't require you to install any files. Git for Windows Portable ("thumbdrive edition") is available on the Git for Windows download page.

If forced to do so, you can also keep manual backups. When changing a file, you can look at the last modification datetime before you open it, and copy the file, and append that part to the end. So a.txt is copied to a.txt.201610131211 before changing a.txt. This slightly is better than not having version control at all.

I was young and reckless once, and I was more interested in actually getting work done than following the rules. As a result, when I worked under suboptimal conditions, I looked for loopholes. I got the friendly networking staff to install a dual boot Linux partition on my machine, and then I installed the network tools I needed to debug my protocol calls. These days you can possibly get away with a Linux liveboot thumb drive. I don't recommend breaking the rules unless you have no other choice.

If none of these initiatives work, try getting a job at a company that isn't insane.


I see two problems: how can you prevent similar mistakes in the future, and how can you minimize the damage from this mistake. Telling your senior colleague not to make the same mistake again might seem the obvious solution, but it won't actually help much with either of those problems and it won't stop anyone else from overwriting your work.

You already know that the real solution is to use source control, but you're not directly in a position to make that happen. What you can do is explain to your manager that this happened because you are not using source control, and the same thing may happen again if source control is not implemented. Be clear that it is a fault of the company's tools and processes, not you or your senior colleague. You're at a large company so you've presumably got a project manager. They will be maintaining a list of project risks, and lack of source control should be on that list.

Putting in extra hours may win you some brownie points with your manager, but many managers won't even notice. On the other hand, if you don't put in extra hours and therefore miss a deadline, your manager might use you as a scapegoat, or they might use it as an example to highlight the need for source control. You'd be amazed how quickly thing can happen when the right people want them to, even in highly bureaucratic companies.

In short: Convince your manager that introducing source control should be a high priority.


The solution is really simple: don't let your colleagues manipulate your computer when asking for help. Show them your setup, explain what you have tried, then ask what you could try next. If this approach is not practical, prepare some sort of sandbox environment for them to play. Actually, without source control you should always work on a copy and never on the actual data. What if your editor crashes? What if you accidentally make a change that cannot be undone? Sure, your colleague was clumsy, but was he aware that he was one click away from destroying several days of your work? I don't think so.

Blaming him for what happened and escalating the issue can only achieve one thing - your colleagues will avoid helping you in the future. Spending time on someone else's problems is bad enough, but being blamed for a clumsy action on a setup they see for the first time is plain demotivating.

You must log in to answer this question.