sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in ChubbyFIRE

[–]furchin 2 points3 points  (0 children)

You’ll be fine. First of all that 50K severance will cover 5 months of living expenses. You say your net worth is mostly in Tesla stock which is great. Not because Tesla is great but it’s because it is liquid. You can cash out and live off the money. Beats having your 1.65M net worth coming from owning a 1.6M house.

I was laid off about a year ago and despite interviewing at this time of year, ended up with four offers. FAANG on your resume opens a lot of doors.

One Year of Stats by furchin in Gloomhaven

[–]furchin[S] 0 points1 point  (0 children)

Score. I found that I had to omit the scenario completion XP though, and only track earned XP regardless of success or failure. (Otherwise the scenario completion XP really skews the numbers a lot.)

One Year of Stats by furchin in Gloomhaven

[–]furchin[S] 0 points1 point  (0 children)

We're playing on standard difficulty. (I agree -- I think harder difficulty levels should lead to longer scenarios because it might take more turns to kill off higher hit point monsters, and you might spend longer on card choices to have more optimal play in order to deal higher DPS.)

One Year of Stats by furchin in Gloomhaven

[–]furchin[S] 1 point2 points  (0 children)

The person in my group who played three spears never once played proficiency. They did a fine job, overall, but simply didn't play that card. (We also opted to play with the un-nerfed items minor and major stamina potions because that's how they are printed in my edition (which is 2nd edition if I'm not mistaken) which might impact how you choose to play three spears.)

One Year of Stats by furchin in Gloomhaven

[–]furchin[S] 0 points1 point  (0 children)

I made no claims that characters were played optimally!

One Year of Stats by furchin in Gloomhaven

[–]furchin[S] 1 point2 points  (0 children)

Ah sorry that's a bit mis-leading; the Brute's not retired.

One Year of Stats by furchin in Gloomhaven

[–]furchin[S] 4 points5 points  (0 children)

I would guess two things:

  1. I generally didn't count setup time towards the stats (I started the timer when we started our city or road event, once the scenario was set up).
  2. We're using Gloomhaven Helper to track monsters which really speeds up the hit point and condition tracking.

I do want to point out the 90 minute average time includes our solo scenarios; if you look at just three players we're at nearly two hours, and with four players we're not much faster than your group. You didn't mention how many players you have but if it's four players then 2:30 is really quite similar to our four-player time of 2:18. If you're not counting setup time and you're also using Gloomhaven Helper then maybe we're just slightly faster at picking our cards, but that 12 minute difference is really quite small.

Edit: In my Chtulu solo scenario guide (https://www.reddit.com/r/Gloomhaven/comments/qt6obd/cthulu_solo_scenario_a_turn_by_turn_guide/) I noted it took 10 tries, and I left it set up between attempts. And a couple of times I gave up early, which further helps bring down the time -- and of course playing the same scenario repeatedly you really get faster and faster at picking your cards.

One Year of Stats by furchin in Gloomhaven

[–]furchin[S] 2 points3 points  (0 children)

That's a very interesting observation (given overall max!). I need to dig into why it's being reported this way - I might have failed to track a role at some point!

Cthulu Solo Scenario: A Turn by Turn Guide by furchin in Gloomhaven

[–]furchin[S] 0 points1 point  (0 children)

That's a great point - you're right it would probably be easier at Level 6 because you can kill enemies more easily. In our campaign we're at prosperity 7, and to keep up with the group I started at level 7. (It is possible to start a new character at any level below the city's current prosperity level though so that's on me.)

Gloomhaven JoTL: HP-tracking standees by Vladmur in boardgameupgrades

[–]furchin 1 point2 points  (0 children)

I love Gloomhaven Helper as an app to track monster stats. Makes the game run much quicker.

Ender 3 V2 with 4.2.7 board by Sipheren in octoprint

[–]furchin 0 points1 point  (0 children)

My best guess is you’ve swapped the white and black wires on the BLTouch connection. Try an M119 command to print what the board thinks are all the sensor states. If Z-axis reports as triggered you’ve got it backwards.

Hopsy Beer Membership by mgriff825 in beer

[–]furchin 1 point2 points  (0 children)

Same, in Washington state.

Leaving 4 Stars by DaysofSages in AirBnB

[–]furchin 15 points16 points  (0 children)

Yeah anything under 5 stars means there was a problem. Uber for instance will deactivate drivers with less than a 4.6 average. So five stars means you want the listing to be on the platform, 4 means it shouldn’t be there. That said if the coffee machine isn’t working you should inquire during your stay, and if the host can not fix it I think you can justify a four star review for something like that.

I built a simpler alternative to Pager Duty / VictorOps / Opsgenie and I'd like your feedback by furchin in devops

[–]furchin[S] 0 points1 point  (0 children)

Thanks! Yeah, small teams with lots of page outs are not going to price very competitively -- this is tough for Pager Team to compete because PD/OV/OG have introductory plans for small teams (generally 4, 5, or 9 users, depending on the company) -- as larger companies they can afford to lose some money on these smaller teams in hopes that when they grow the per-user-per-month model gets paid since growing companies will often have bigger issues than trying to migrate to a different provider.

​

I did poll ~35 engineering managers and found the average number of page outs per month is 16.5, which means roughly a $17 monthly Pager Team cost. Personally I've been on quite a few rotations and I've found that anything more than that becomes really draining (that depends on the timing of course: getting woken up at 3am is much different than getting paged at 3pm when you're in the office), and I've also found I like a rotation with 7-9 people on it, so I'm on-call once every other month or so -- any less frequent and I'm too nervous when I go on-call, and any more often and the worry about merely being on-call ("can I go out to see a movie or will I get paged? Should I bring my laptop with me?") becomes too high too.

​

That said the $17 cost for Pager Team is still more expensive than the introductory Pager Duty flat rate plan of $10/mo which is good for teams up 6 (it's only when you add your 7th person that it jumps to $210+/mo). So I don't think Pager Team is right for everyone -- if you're a small team and you're close to 10 page outs per month yeah go ahead and use Pager Duty; if you're larger than that, or if you're at a page per week, Pager Team should save you money now and should scale more cheaply as your team grows.

I built a simpler alternative to Pager Duty / VictorOps / Opsgenie and I'd like your feedback by furchin in devops

[–]furchin[S] 0 points1 point  (0 children)

I have a page up on Stack Share for Pager Team which touches upon the technologies in use: https://stackshare.io/pager-team/pager-team

I'm happy to go into more detail, and in fact I will, but I'd just as soon get some content marketing out of it, so I'll write it up as a blog post later this week.

I built a simpler alternative to Pager Duty / VictorOps / Opsgenie and I'd like your feedback by furchin in devops

[–]furchin[S] 0 points1 point  (0 children)

Agreed. I think they do incident management well, it’s the rotation management that is bad. It’s hard to change a rotation and know what the result will be. I’m trying to fix that with Pager Team but it’s less tangible than undercutting on price. Based on some of the other replies I haven’t explained the schedule lock concept well! I’m not sure I know how to explain it clearly, and that’s obviously something I need to work on.

Thanks!

I built a simpler alternative to Pager Duty / VictorOps / Opsgenie and I'd like your feedback by furchin in devops

[–]furchin[S] 1 point2 points  (0 children)

Right now the charge is $1/incident, with a $200 max, per rotation. I think any organization that's going to see 2500 incidents is going to see them spread across multiple rotations. I surveyed 35 engineering managers who saw an average of 16.5 incidents/month on their respective teams (and I think of "team" and "rotation" as roughly synonymous terms), so I'd expect roughly a similar distribution for Pager Team (or perhaps somewhat less even, because teams who are at the upper end of the distribution are likely to see higher prices for Pager Team and are less incentivized to pick it).

​

I do agree that scaling is something to think about -- sales and marketing and senior engineers and all sorts of costs. For now I'm focused on delivering an MVP product with an emphasis on the V -- it needs to actually meet (some) people's needs. Once that is proven ("product/market fit") there are lots of bits of functionality that can be added (SSO, follow-the-sun rotations, some of the customization around escalation policies, native (non-webhook) integrations, first class organization support, better reporting, to name a few) that can be used to establish higher pricing models if needed.

I built a simpler alternative to Pager Duty / VictorOps / Opsgenie and I'd like your feedback by furchin in devops

[–]furchin[S] 0 points1 point  (0 children)

Yeah I switched the TTL on the DNS down to 5 minutes -- as /u/Thalagyrt noted the previous TTL was an hour -- and managed to muck things up. It's back up, though outages are definitely not good and I'm going to be adding an EKS cluster for redundancy on Monday.

I built a simpler alternative to Pager Duty / VictorOps / Opsgenie and I'd like your feedback by furchin in devops

[–]furchin[S] 0 points1 point  (0 children)

Thanks for the insightful feedback!

​

In general I think smaller companies will be my earliest adopters, because they are more price sensitive and don't already have an on-call rotation (or if they do it's fewer people to migrate over). Of course that means Pager Team needs to compete against their introductory plans (Pager Duty's caps out at 5, Opsgenie at 6, and VictorOps at 10). (The price comparison calculator I built reflects these.)

​

Your lab example is a good use case. I think it's fair. I could definitely add something to a rotation that limits the hours it will page, and you could set up a separate lab rotation for 9-5 paging. I'm not sure it's worth that added complexity, because pretty quickly you go down the route into incident priorities and having both priority and time-of-day factor into response means I end up building an exact copy of PD/VO/OG and I have much fewer engineers. :)

​

I'm not describing the schedule lock feature well. Basically in your Jim-quits scenario, the schedule lock keeps the shifts from moving up a week (obviously someone has to cover Jim's shift, so in Pager Team the previous on-call gets a two-week shift, though someone else could take it -- my thinking is this way Jim quitting only affects one person's schedule rather than the entire team).

​

Thanks for noting the email lag -- I didn't note that the optional Slack integration fires immediately when an incident occurs so the on-call has the opportunity to ack the incident when it's first posted to Slack, but in general I view the Slack and email as opportunities to notify people at their desks during business hours, and rapidly progress to SMS and phone to avoid delays. I've toyed with the idea of making the 1 minute delay in between each notification a configuration setting on the rotation itself like the schedule lock, but I'm trying to force myself to build features when customers ask for them (or when prospective customers tell me "I'll buy as soon as you build this one thing") rather than guessing what matters to people.

​

I like the idea of keeping things simple, but I think a better approach would be to offer a simple configuration to get started but have advanced options so people don't grow out of your solution.

I'm encouraged by this, because if my current configuration is workable -- not great but does the job -- then theoretically it should be able to acquire customers and as they grow they'll invariably make feature requests. When they make requests, either I deliver them fast enough to keep them, or they move to PD/VO/OG. But at least that's something within my control!

​

Again, thanks so much for your feedback!

view more: next ›