Live data from Hacker News

Gitlab's Guide to All-Remote

about.gitlab.com

241–250 of 254 posts

Re: Gitlab's Guide to All-Remote

#241
post #2

I appreciate they have a whole section on disadvantages, but this stands out to me: "All-remote companies should consider meetings as a last resort, instead relying on asynchronous collaboration tools[...]" To me, this implies a further disadvantage: extremely high latency when compared with in-person collaboration. That can be fine for some things. But there's all sorts of work where I really value live discussion.…

> I know that some remote-first companies tend to group related work by timezone, so that teams can be both distributed and low latency. I take it Gitlab isn't one of those? Probably depends on the team, individuals being able to self-organize and their experience. While some companies may see timezone distributed teams as disadvantage, I believe it is an opportunity to have a continuity of work and getting things do…

Having experienced a manager with a "sun-never-sets-on-my-empire" fixation, I'm skeptical. In theory, you can get 3 shifts in where there was one before. But this isn't a factory. For knowledge work, there's a big problem with handoffs.

If somebody is going to pick up coding right where I left off, I need to transfer a lot of state from my head to theirs. At best, this takes a lot of time. But what's more likely is that things get In software our true enemy isn't time, it's error. It takes seconds to create a bug, but often takes hours or days to remove it. It takes minutes to misunderstand the purpose of a feature, but days or weeks to rework the code to match actual need.

I think if we want to get more people at the coalface, the right solution isn't working in shifts. (If it were, we would already be working in shifts without regard to timezone, just like factories do.) Instead, it's to increase collaboration, which requires much more synchronous communication. E.g., techniques like collective code ownership, pair programming, frequent pair rotation, cross-functional teams, small units of work, continuous delivery, and very frequent releases (daily or more often).

Since very few people work like that, I think it's reasonable to assume that faster results are not in fact a priority for most businesses. So the "distributed timezones are an advantage" to me sounds like an after-the-fact justification, not an actual solution to a problem.

Re: Gitlab's Guide to All-Remote

#242

Earlier quoted context omitted.

If you're refusing to pursue a job at Gitlab because it would pay less then the market rate where you live then the issue isn't that their salaries vary geographically but just that they don't pay enough in your area. If you you object even though they pay higher than your local market rate then you have a weird aversion to money that I don't see a reason for anyone else to care about.

I currently live in a major city but have plans to move to a lower cost rural area. If I did that while I was working at Gitlab they would slash my salary and reap my cost saving, do you think I would be generating less value for them in exchange?

There are two answers to this. One is "No, but prices aren't determined by 'value'. Having air to breathe is very valuable, but it's free! You've got to consider supply as well as demand." The other is "Yes. Previously you were the most efficient source of code per dollar they could get (on the margin). Now you aren't."

Re: Gitlab's Guide to All-Remote

#244

How do people whiteboard remotely? This is a big problem for many development teams. Sometimes you just want to open a blank whiteboard and scribble some boxes and brainstorm or troubleshoot some things. The whiteboard is an inseparable part of nearly every meeting. And no, remote "canvas" whiteboards don't work. They end up looking like this: https://cdn.drawception.com/images/panels/2015/3-3/jLndYAfNf... . Is there…

Google also has a tool for this that seems promising: https://gsuite.google.com/intl/en/products/jamboard/ I can access it under drive.google.com > New > More, on my gsuite account

I knew that existed as a physical product but I never knew it was available as digital-only too. My non-gsuite personal account seems to be able to use it just fine for free.

Re: Gitlab's Guide to All-Remote

#245
post #205

Earlier quoted context omitted.

If you just go up one category you'd see you don't need a third party tool: https://www.amazon.com/gp/sendtokindle

I had searched the Firefox Add-on catalog and the official tool has never shown up: https://addons.mozilla.org/en-US/firefox/search/?platform=wi... Interestingly, the link from Amazon, clicked through your link, is dead https://addons.mozilla.org/en-US/firefox/addon/sendtokindle/

https://web.archive.org/web/20171010081410/https://addons.mo...

seems poorly rated when it was available 3 years ago

Re: Gitlab's Guide to All-Remote

#246

How do people whiteboard remotely? This is a big problem for many development teams. Sometimes you just want to open a blank whiteboard and scribble some boxes and brainstorm or troubleshoot some things. The whiteboard is an inseparable part of nearly every meeting. And no, remote "canvas" whiteboards don't work. They end up looking like this: https://cdn.drawception.com/images/panels/2015/3-3/jLndYAfNf... . Is there…

We as a small business use IPad Pros and Google Jam Board. It’s honestly fantastic. Quick to jump into, export, and share. Especially for those moments where you only need the whiteboard for 30 seconds to get a point across

Re: Gitlab's Guide to All-Remote

#247

Earlier quoted context omitted.

Is it unreasonable for a random Indian company not to pay the same wages as one in SF (assuming the work is the same)? What about if both companies are consultancies doing projects for Gitlab? If differences in those cases are fine, why is there a sudden change if the employees of the above companies start working for Gitlab directly rather than through a proxy?

I'm not sure what comparison you're making sorry. But I think that if GitLab is able to pay somebody in the US one wage for work, and they hire somebody equally qualified in Australia that will be producing the same work, they should be paid the same. Well, it's up to GitLab to decide what they're paid, they shouldn't be forced to pay them the same, but I wouldn't work for a company that didn't. I'm also surprised Gi…

[deleted]

Re: Gitlab's Guide to All-Remote

#248

I find it interesting how they achieve this and it also gives people in remote places the ability to work for such a company. What I don't agree with is the pay scale they use based on your location. If you have the same skills, you should be paid the same.

Gitlabs wants to hire people from everywhere. If they don’t pay people enough, they won’t be able to compete for those employees. If they pay everyone SF rates, they will have far less engineers than their competitors and will overpay unnecessarily.

Re: Gitlab's Guide to All-Remote

#249

Gitlab's remote manifesto speaks to me in so many ways. I'd also love to work for Gitlab anyway. But, alas, I don't know Ruby on Rails and I think it's too late for me to gain the proficiency that I'd require for my expected salary from Gitlab. Are there any fully remote companies doing Python?

Ruby is easy a fuck to learn. And it’s fun! It was influenced by Python, give it a shot
Post reply on HN