Live data from Hacker News

GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

blog.ycombinator.com

11–20 of 320 posts

Re: GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

#11

>> 2:41 – GitLab values boring solutions: our product should be exceptional Exceptional products have exceptional UX. Gitlab IMHO has the worst UX of all git based products out there, I much rather take BitBucket over Gitlab. I tried using Gitlab, but no, I would much rather pay the 7$ to GH for my private repos. I sincerely hope they make an exceptional product. And 'should' better be 'must'!

I'm curious what you dislike about the UX. Personally I like the "feel" of the website generally (though it's not as polished as GitHub) and just find it to be slow, which I think they're working on improving.

Re: GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

#13

>> 2:41 – GitLab values boring solutions: our product should be exceptional Exceptional products have exceptional UX. Gitlab IMHO has the worst UX of all git based products out there, I much rather take BitBucket over Gitlab. I tried using Gitlab, but no, I would much rather pay the 7$ to GH for my private repos. I sincerely hope they make an exceptional product. And 'should' better be 'must'!

This is pretty subjective obviously.

I think the GitLab interface is pretty good, especially compared to GitHubs. I can't speak for BitBucket since I've only used it once, but I do remember having a hard time finding my way around it.

Re: GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

#14
post #7

> Write Everything Down Then rm -rf the paper.... https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/

Not really germane to the topic. This type of op fuck-up happens everywhere. It's hard to build solid process, particularly in growth phases. Unless there are 2x a year restore tests, I personally assume a 60% backup fail rate.

The only reason they are still in existence is due to a chance backup they took for a tangential reason. From the sounds of it, their solution is held together with bubble gum, some tape and lots of hand waving. Being in 160 different locations probably doesn't help much either.

Re: GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

#15
post #2

After the mess up, I don't really like seeing these posts about Gitlab. Maybe this is their problem after all.

"This" being remote work?

Also, I'm a little surprised by the anti-GitLab sentiment on this thread. I thought the consensus was that they had bad luck but didn't do anything particularly more wrong than anyone else? (I may have missed some more analysis of the cause of the failure.)

Re: GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

#16
post #2

After the mess up, I don't really like seeing these posts about Gitlab. Maybe this is their problem after all.

Scale is freaking hard. It is absurd to say they figured out the secret after a 7 layer failure on disaster recovery, even more so when one of the main reasons for source control is to have disaster recovery and the ability to rebuild old source.

Re: GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

#17
post #15
post #2

After the mess up, I don't really like seeing these posts about Gitlab. Maybe this is their problem after all.

"This" being remote work? Also, I'm a little surprised by the anti-GitLab sentiment on this thread. I thought the consensus was that they had bad luck but didn't do anything particularly more wrong than anyone else? (I may have missed some more analysis of the cause of the failure.)

It may be due to downtime earlier today (this being only days after the data loss). Things don't seem to be going well for GitLab right now.

Re: GitLab’s Secret to Managing Employees in 160 Locations: Write Everything Down

#19
post #7

> Write Everything Down Then rm -rf the paper.... https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/

Not really germane to the topic. This type of op fuck-up happens everywhere. It's hard to build solid process, particularly in growth phases. Unless there are 2x a year restore tests, I personally assume a 60% backup fail rate.

"It's hard to build solid process, particularly in growth phases." Hard is an understatement, it is insanely difficult.

However, the interview seems to suggest that "write everything down" is the way to solve this problem and was what allowed for all their growth and success. So the solid process they have built is to write everything down, which they obviously didn't do or they wouldn't have had a 7 layer disaster recovery failure.

Post reply on HN