isugimpy

I openly admit to working at Reddit. In fact, I got hired after reading a post in the monthly hiring thread here on HN.

Calling MSK expensive is maybe not being clear enough. It's more than 2x the cost of the raw EC2 instances. Then on top of that, to get metrics at the per broker level there's an upcharge, and a further one for per topic metrics. These are things that are actually extremely important at scale, and it's absurd how expensive it gets.

Then you combine that with how immature the UX is, and it really just doesn't feel good to deal with. It's not that much work to run a Kafka cluster with the sort of design that MSK provides, and it can be done better than that without much cost.

> The amount of money you are saving by WFH full-time, assuming you properly leverage the opportunity (i.e. cooking own meals and multitasking chores), far outweighs any paltry notion that could be provided in recompense for you dutifully enshrining a guest bedroom as your employment zone.

This one's really important. Prior to moving to my current job, I had a 15-20 minute drive to work every day. I was filling my car up with gas every 2 weeks like clockwork. I was also going out for lunch semi-regularly. Moving to WFH (before the pandemic, because this was a planned move for me) totally changed the math on a lot of stuff. I haven't filled my car up with gas since early February at this point, though even before social distancing the previous fillup was in early December. My insurance cost on my car went down due to no commute. Food costs went down because I was cooking when I wanted lunch. These changes made a pretty noticeable improvement to our finances and we're now getting ready to move into a house where I'll have a dedicated office for work instead of a corner of the basement, and that's going to have some nice tax impacts too.

My employer has done a really good job embracing remote. There was a time when they actually retracted all ability to work remotely and had everyone move to work at our main office or look for another job. A shift in regime happened, and remote eventually came back, and now we've got a whole pile of benefits specifically for our remote employees, to help counterbalance the fact that they don't get some of the benefits that our in-office employees get.

One thing that we all get is a stipend we're allowed to use generally on things that help improve our lives or help us grow as people (a few examples of expensible things would be a new mattress, cooking classes, voluntarily chosen equipment for our workspace, etc). So we really already had the ability to expense the things we need for WFH, which has definitely been a big help.

As far as Overwatch between PRs... I mean, let's be real. Think about how much time you spend in the office chatting with coworkers about weekend plans, or what was on TV last night, or any other thing. Or, for those of you that have something like it, playing pool or ping pong. This is just an evolution of that. Taking a break now and then to do something to blow off steam is good and healthy.

Curious to hear more details about your thoughts on this. I've done some pretty significant improvements around my team's use of it in the last few months and can't say I've had this experience. The difficulties with it really, to me, seem to be a case of batteries-not-included, speaking as someone who had never run it prior to last August.

I'm not a fan of it, personally. The interface is lacking, configurability after launch is minimal at best, and the observability is EXTREMELY poor because you can't get per-topic metrics without paying extra.

As somebody who deals with AWS professionally on a daily basis, I will 100% admit that it can be confusing for people to figure out pricing and scale. I have to talk with engineers every week about design decisions and their cost impacts, and the implications of the things they want to run, and it's clear that AWS doesn't give enough guidance in the UI or documentation structured in a way that a layperson could find what they're looking for quickly and easily for that information.

That said? This article rubs me the wrong way. The suggestion that this problem is caused by "dark patterns" and Amazon being misleading about "pay as you go" screams FUD to me. The screenshots provided right in the article clearly show that what was being done wasn't eligible for free tier. And not understanding that launching a resource, regardless of whether or not you're interacting with it, is consuming the service which launches the resource is a problem with the user, not the marketing. Yes, the author admits that they didn't scrutinize, but that doesn't excuse the position of the article that AWS is somehow doing this to intentionally bilk people.

I definitely have to thank this awesome site as well. Had been stuck in a position where I didn't feel like I had a way out, due to a combination of a non-compete on myself and restrictive no-poach agreements between my (now former) employer and a majority of large tech-oriented businesses in my city. Tried everything I could to get out from under both, short of leaving town, and just couldn't find a job that fit my career goals that I was actually able to take. Early last year, I started checking the who's hiring posts monthly, on the off-chance that something would stick out and catch my attention. I was scrolling through pretty quickly one day, just looking for keywords, and blasted through like half the page, and then realized I had missed reading a comment that had some of my target words in it. Scrolled back up, saw a post from an engineering manager at a company whose product I actually use, and on a whim I just applied. Now, over half a year later, I'm happily and gainfully employed, working remote, for a company that I really enjoy working for and on a product that I can dogfood. Feels really great. Thanks for keeping this community alive, everybody. It's awesome to be a part of this.

Serious question: What makes it completely awful? Do you have ideas that might make it a better experience, besides "just use the old UI"?

Would be very curious to hear more specific examples of this one, haven't seen it firsthand.

Having just gone through the interview process with a very well known tech company, as someone who is honestly pretty terrible at interviewing, I think some companies actually get it. It's really a matter of the interviewer at play. Two of the phases I went through really aligned with the company's needs. I was interviewing for a SRE position, and in one phase they gave me a broken EC2 instance that had been manually configured and asked me to get it back up and running. That's a legit task that I've had to do in daily work for years, because there's ALWAYS going to be someone that does a quick hack to get something working and forgets to productionize it. It was a completely contrived box that didn't actually serve customers, but still a good exercise. In another phase, they had me completely blind fire design some infrastructure (without a complete picture of what the current state of the application is) to lead toward a scalable solution for a real problem they're facing. While, yes, that's basically them getting me to do unpaid work, since I didn't put hands on a keyboard during it and really just talked it through with them, I feel like that was a great exercise in seeing how I thought and could work with a member of the team.

There's no truly bulletproof solution to interviewing, because the needs of every org are different, and the skills of interviewers are rarely nurtured to the point of usefulness. Sometimes you just have to luck out and get a good interview.

I figured it was something to that effect, but it's still helpful to call out the consumer protections since a significant portion of Apple's customer base is in the USA.

Post author called out the warranty multiple times. If you're in the USA, at least, bear in mind that doing what's described in the post does not void the warranty. The Magnuson-Moss Warranty Act explicitly requires the manufacturer to prove that your action caused the negative impact the warranty claim is made against, otherwise they legally can't void your warranty.

There's nothing adventurous about using your preferred operating system and enjoying being able to have a working game experience. I've spent significant time in all 3 major OS options over the last few decades, and came to the conclusion that Linux is the one I prefer. A few years ago, I resigned myself to either rebooting to Windows or running Windows in a VM when I wanted to do any modern gaming. The significant advancements over the last year in terms of video driver functionality (both on Nvidia and AMD sides), binary compatibility (WINE/Proton), and more developers releasing native games have been a huge boon and very welcomed. I use Linux full time because it's what I enjoy and feel comfortable with as a primary OS, and I absolutely care about the gaming landscape improving. I'm only one person, but many others won't speak up.

For random toy projects, spinning up a whole Kubernetes cluster is absolutely overkill (unless part of the project is learning Kubernetes). The thing is as you get further along, for some applications, it becomes harder and harder to move to a container-based design as you have to unwind all the weird dependency mappings. I've got an app I've been involved with containerizing for a client at work, and they're dead set on sticking with an Ubuntu 14.04 base container, because they legitimately don't know if it'll even function on a more modern base, and don't feel they can spare the development cycles to figure it out. Thing is, it started as a toy application, deployed to a server by manually SSHing in and doing a git pull from the repo (not even rsync!) and restarting all the services, and that's still how it's deployed in production today.

Containers (and thus Kubernetes) aren't the magical solution to every problem in the world. But they help, and the earlier you can get to an automated, consistent build/deploy process with anything that'll actually serve real customers, the better off you are. Personally, I'd rather design with containers in mind from day one, because it's what I'm comfortable with. There's nothing wrong with deploying code as a serverless-style payload, or even running on a standalone VM, but you need to start planning for how something should work in the real world as early as you can reasonably.