It still creates non-trivial day-to-day overhead for customers where they now have to think about who to invite and what permissions to grant them in conjunction with costs.
We'd much rather that 90% of the cases, customers can just invite anyone on their team without fearing ballooning costs. Then they can think about permissions purely from a permissions/access perspective and not have to factor cost into that decision.
There has to be some sort of limit because "unlimited" can easily lead to customers using far more resources than they're paying for.
However, by moving away from per-seat pricing, customers who have switched to the new pricing have now added many more users who can benefit from having access to the Flipper Cloud UI but were not worth paying for individual seats before.
So based on customer behavior and reception to the new plans, it has made things much more flexible for them in practice.
I don't have a singular, one-size-fits-all better option, but I explicitly included several options that I've seen work well either as the applicant or from the hiring side. I just wasn't going to presume that there's one perfect replacement that will work for every team or role.
I added that after-the-fact in response to this comment. So that's on me for not including it originally. It's a great idea and one I wholeheartedly endorse because it forces the company to put some skin in the game and helps limit the number of applicants that they would request perform the take home test while also recognizing that applicants' time is in limited supply.
That’s not always accurate that the company doing the hiring contributes nothing. (Also good companies could offer to pay for that take-home test time.)
Having done take home before from the hiring side, it was incredibly time-consuming for us. We had someone anonymize the three finalist submissions, and then we had three people each individually review and comment on each one, and then we got together to discuss and choose the final candidate. Once we agreed on one, only then was it de-anonymized.
All-in, it took way more time than a single developer doing three live coding interviews. But my guess would be that most companies wouldn’t be willing to be that deliberate with take home.
I don’t have any trouble with the three bottom thumb keys in the cluster, but the top three aren’t very useful. I’ve remapped them to media or macro shortcuts that I don’t use while typing.
We have three TCL Roku TV’s, and while they’re all blocked now, they were responsible for about 98% of the requests on our network according to Pi Hole. Now they’re blocked at the router level as well because it’s hard to trust them at all. Pi Hole doesn’t block them by default, but the endless requests to Roku domains are easy to blacklist.
We've been doing 4-day/32-hour weeks at Wildbit for over a year now, and it's been great. We're a remote-first team of just under 30 people spread across quite a few time zones. It's a mental hurdle at first, but the company has continued to grow and be as productive as we were before.
We're all just much more mindful of how we each spend our time these days. We also strive to reduce meetings and lean more on asynchronous communication in order to reduce interrupting each other. That lets everybody focus more and get more high-quality work done in fewer hours.
As a Grammarly user, the thing that's been most surprising is that there's no option for an API to integrate with other tools. I guess with the growth they've experienced, there's not a lot of pressure to expand it, but it seems like a world of opportunity. I'm sure there are some good reasons, like the editing experience or API abuse, but their tool simply isn't the best overall writing experience.
To be able to use Grammarly within Sublime text or other editors would be incredible. As it stands, because you're forced to copy and past content over into their editor, the workflow is the biggest drawback. It's really handy in textareas on the web, but I've struggled to integrate it into my writing workflow because of the copy/paste process. Writing mainly in Markdown doesn't make it any more elegant either.
There is an open source engine offering similar features that might be a better candidate for other products to integrate with - https://www.languagetool.org/
I've been meaning to have a play with it as a potential replacement for Grammarly before the special offer subscription of that is due to renew in a couple of months (though if I keep the special offer rate it is probably just as well for me to stick with Grammarly).
It is Java based which may put off a lot of projects from including it directly in their desktop or mobile products, but they could host their own instance and have their applications submit data to that. Assuming the extra admin (keeping the service running & up-to-date, and monitoring/enforcing API-key use if they don't want the service to become de-facto public once other developers notice it exists) and hosting costs would not be too high, of course.
When I was in a coding bootcamp, one of the other people in my cohort was able to get some access to an API for Grammarly, and we worked on a toy project to use the API to 'score' medium blogs:
Site functionality is pretty much broken now, but it's been almost two years since it went online, so I'm surprised they haven't offered a public API by now.
The more I read about others' experiences with remote work, the more it seems that it depends heavily on whether the company embraces remote work, accepts it, or merely tolerates it. The resulting experiences really need context. Unless a company is truly committed to remote work, it's going to be an uphill battle.
Much of this advice is true in every context, but much of it reads like it's coming from a place of fear and having to prove your worth and presence. I imagine that if you're one of very few remote employees of a primarily centrally located team that makes sense, but it feels really unhealthy.
Half of our team at Wildbit is remote and across many time zones that make meetings difficult at times, but it doesn't feel anything like this. Even the half of the team that's based out of HQ spends a lot of time working from home.
We also activley promote disconnecting and not being constantly available to get focus work done. And everyone's encouraged to not be constantly available because that makes it nearly impossible to get the most important types of focus work done. So in many cases, team members are explicitly unavailable. We even promote email as one of the best ways to communicate because it's less disruptive and let's people stay focused until they're ready to come up for air and respond.
Another thing that makes a difference is that we strive to incorporate the remote team into the daily life around the office. We have team retreats once a year. Everyone regularly spends some time in Philadelphia at HQ. And we have someone who spends a lot of time dreaming up ways to incorporate the remote team so we're not so disconnected. It's a constant effort on everyone's part to ensure we're supporting and fully embracing remote work as a single team.
> We even promote email as one of the best ways to communicate because it's less disruptive and let's people stay focused until they're ready to come up for air and respond.
Those are some of the advantages of email. It also has virtues of being searchable, transactional, naturally organizeable, recorded, and shared.
But how do you respond to the issues of its much higher latency and lower bandwidth? A 5-minute in-person conversation can communicate a whole lot more than 5 minutes writing an email. And while documentation and detail are great, a long, thorough, technical email can cost a lot of money. How do you control for these problems?
Does the loss from writing long emails offset the loss of productivity from disruptive and focus-breaking in-person communication?
Not OP, but the first 3 months of my current job were remote. It was mostly on our backend and frontend teams to realize that meaning/nuance might be lost in an email or slack message and to hop over on google hangouts (what we personally used, but replace that with phone, skype, &c.). Maybe if there's immaculate documentation and tests, then fully asynchronous communications can be achieved, but, from my experience, there's hiccups where synchronous communications need to be taken to overcome something that's blocking.
We don't hesitate to use chat or video if it makes sense. In fact, we use it frequently. We all trust each other to think about what medium makes sense for a given discussion. That way, people don't just reach for what's in front of them. It makes everything much more deliberate, and it helps reduce interruptions.
We'd much rather that 90% of the cases, customers can just invite anyone on their team without fearing ballooning costs. Then they can think about permissions purely from a permissions/access perspective and not have to factor cost into that decision.
reply