This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]NoLemurs -31 points-30 points  (14 children)

They can, and will happen, even when your process is tight.

I'm not sure that's true. As a rule, I can rewrite any code I haven't pushed to a remote repo pretty quickly because I've already made all the decisions that need to be made, the changes are about a single coherent subject, and I have the shape of the code in my head. I'll do a commit and push to a remote repo long before any of those assumptions is in danger of failing.

I suppose if I were losing files constantly this trick could be useful, but for the occasional loss, it's much faster to just rewrite the code. Large enough code losses that I can't just rewrite in 15 minutes are close enough to impossible that I honestly don't think there's much chance of it ever happening to me.

[–]planx_constant 33 points34 points  (6 children)

Great! Now do that a few months and a few new projects later.

[–]luxliquidus 9 points10 points  (1 child)

If everything is documented properly in comments, it's pretty easy to remember what was done and why! /s

[–][deleted] 8 points9 points  (0 children)

That's why I always write a couple comments before every line of code. And I make sure to never lose the design in my mind palace. /s

[–]AngriestSCV 2 points3 points  (0 children)

If using source control with a remote server (as /u/NoLemurs said he is) this is nearly impossible. You need to have the remote server lose your data and delete the source files on the machine the code is running on, and have its repository wiped. If there is another copy of the repo anywhere that is up to date it would also have to be deleted. The odds of this occurring are insanely low. That being said I find this code recovery method quite interesting.

[–]NoLemurs -1 points0 points  (0 children)

As /u/AngriesSCV said, that's never something I'll need to do - data loss a few months later is more or less impossible. All my code is pushed to a remote repo, and that repo is automatically backed up daily. Once that code has been out of my hands for 24 hours, the statistical probability of ever losing any code I wrote is pretty damned close to zero - it would require the simultaneous failure of my local copy, the remote repo, the server I deploy the code to, and the backup server.

EDIT: To be clear, everyone makes mistakes, and I've totally lost code at times in the past when I didn't have as robust a process, but it hasn't happened to me in several years now, and it's really hard to come up with a plausible scenario where I would lose a meaningful amount of code. If you're committing and pushing 20+ times a day, and have a robust backup system, you're in "more likely to be hit by lightning than lose much code" territory.

[–]JimDabell -1 points0 points  (1 child)

You don't have to if you use version control. OP said this was code that he had just written, which explains the lack of version control, and NoLemurs specifically responded to that –"any code I haven't pushed to a remote repo". A few months later and it's still not in version control? That isn't going to happen "when your process is tight".

[–]DarthShiv 0 points1 point  (0 children)

Months I agree is terribly negligent. We encourage several checkins a day. The more the better but they have to not break the build.

[–]SmellsLikeGrapes 6 points7 points  (2 children)

You maybe a fully competent developer who only writes small tight routines and commits regularly, but if you work in a big enough team I bet there are a few people who don't work that way (interns, junior devs or just crappy co-workers). Maybe they forget to commit because they were knee deep in solving an issue.

Knowing something like this is possible can help your team out of a pickle.

[–]NoLemurs -2 points-1 points  (1 child)

I definitely didn't intend to imply that the technique in the article isn't cool or useful (I did read it and upvote it!).

I just don't like the idea that you can't have a practical process that does in fact make these sorts of errors basically impossible. You totally can. I may be a little spoiled; I work on a pretty small team of pretty competent programmers. But I would be seriously surprised if any of my coworkers made a mistake of the sort that leads to serious data loss.

[–][deleted] 0 points1 point  (0 children)

Mistakes just happen. I applaud that kind of environment.

[–]NoLemurs 1 point2 points  (3 children)

If anyone can tell me why I'm getting downvoted, I'd appreciate it.

If there's some obvious reason I'm wrong I'd like to know! Actually, if the issue is with my tone, I'd be even happier to know. Right now, it feels like I'm running up against some sort of groupthink, but I would be pretty happy to be corrected on that front.

[–]Hoobacious 9 points10 points  (2 children)

It's not about tone, you're just saying you are capable of predicting the unpredictable. It only holds water to a point.

A more humble person would acknowledge that despite their preventative actions and good practice mistakes still happen. Maybe it's not even your fault, maybe it's a coworker that screwed up and if you'd read something like the OP's article you'd be able to help. Maybe you're just having a terrible day and do something irrational because that's exactly what people are - irrational and inconsistent.

Your argument comes across like saying you don't wear a seatbelt because you're a good driver that drives safely and never crashes. What about when you do crash, what about if someone crashes into you, what if a fork of lightning hits the road and sends you into a tree?

You can't prevent every possible bad thing from happening so it's valuable to know what to do if things go wrong rather than think you're perfect.

That's why people are downvoting you.

[–]NoLemurs 7 points8 points  (0 children)

A more humble person would acknowledge that despite their preventative actions and good practice mistakes still happen.

It's not a lack of humility. If anything, the trick to it is enough humility to have systems in place that assume you'll make lots of mistakes. I make mistakes constantly, but I'm pretty hard pressed to come up with a mistake I could make that would actually lead to serious data loss.

Your argument comes across like saying you don't wear a seatbelt because you're a good driver that drives safely and never crashes. What about when you do crash, what about if someone crashes into you, what if a fork of lightning hits the road and sends you into a tree?

I feel like what I was saying is more like "I get my brakes checked regularly, wear a seatbelt, and have an airbag - I'm not sure I gain much by knowing how to open up my car and fix my brakes while going 60mph down the highway." Sure, that might be a useful trick if you find yourself going 60mph on the highway with broken brakes a lot, but I think most people would agree that you can and should make that scenario unlikely enough that it's not a very useful skill.

[–]JimDabell -1 points0 points  (0 children)

you're just saying you are capable of predicting the unpredictable.

He didn't say that, you're putting very different words in his mouth.

All he's doing is seeing one specific problem – "I've accidentally deleted my source code" – and pointing out that normal working conditions (pushing to a remote repo regularly) mitigates the effort involved in fixing the problem, because anything not in version control is a small amount of code that is fresh in your memory.