disport

Disclaimer: My started is made for automatically onboarding user domains to applications, anything DNS-related such as SPF/DKIM/DMARC. It's a "Stripe-for-DNS" called cloudvalid.com.

I like the quality of this SPF/DKIM/DMARC guide. I worked at and wrote the SPF/DKIM/DMARC guides for SendGrid, Amazon SES, and a few other email products. I don't mind saying that author has done a better job at this guide than me.

That being said, I see SPF/DKIM/DMARC guides like this pop up with some regularity, but users continue to have the same level of comprehension as before. I think the nature of the problem is not one that lends itself to being solved by guides. This is the sort of problem that a user is really only faced with once, which means that they're not getting the repetitions in to warrant any long-term comprehension.

I'm naturally biased here, but if you're onboarding users with SPF/DKIM/DMARC to your application, it's good if you can just get them setup with automation.

As a remote, older professional now, my career nevertheless supports the premise of this article: in-office was beneficial when I started out.

My first job had a strong lunch culture, providing an environment for serendipitous conversations, daily. Over time, I bumped into folks I never would have met in the normal scope of my role, across finance, legal, SRE, support, sales, data science, etc.

In turn, as a young professional, I was able to develop a mental model for how businesses "work", why they're organized how they are, and how (good) culture can bind everyone together towards a profitable outcome. I made some friends and acquaintances that I'm still in touch with to this day.

As a remote, older professional now, I don't necessarily "need" these serendipitous conversations anymore, although I miss the general socialization. But I do feel like they're an essential "ladder" that every subsequent generation of professionals should be able to access, and that it's a moral obligation for me to "pay it forward".

For remote work to be "fair" to young professionals, its systems should facilitate the same career benefits, with the same effort.

From my perspective as a user, maybe someone who would visit your domain, I’m indifferent to the specific TLD used. You might be able to compose a clever word that grabs my attention, which I’ve seen a lot from .ly domains.

However, from an email marketing perspective, TLDs are not interchangeable. Some TLDs (think .xyz) see a lot of abuse, tanking the reputation and deliverability for good actors using them too.

So my advice is to stick with TLDs that most good actors are using (.com, .io), giving you better baseline deliverability, because email marketing remains incredibly valuable for growth.

Another way to rephrase the question is: why don't networked devices require signoff from a professionally licensed engineer on its specific software implementation before it goes to market?

You see "forethought" in devices offered to the public when regulation DEMANDS it: think cars, bridges, medical devices, because (or so it's been rationalized), the public needs accountability (a named, professionally licensed, buck-stops-with-them head to roll) when that product can cause harm.

But software harms TOO!. Think privacy, banking, relationships. Those can be harmed. It's always felt to me like a historical accident that networked devices, really most software in general, slipped past this accountability requirement. Without a specific , named accountable person, security seems to fall into the not-my-problem phenomenon, and continues generates articles like from the OP.

In the imagined future where signoff from professional engineers was required, you'd see pushback against a vendor by the engineer until the implementation was secure, because the engineer's licensure was on the line until it was secure. And the vendor couldn't just "shop" for a favorable signoff, because every engineer would be held to the same ethical standard and penalty.

If I could change the article's title, to reduce ambiguity, it would be, "The BUSINESS Strength of Being Misunderstood".

It's ambiguity that I wish Sam would have anticipated, and adjusted for, but the content is nevertheless good advice, once you contextualize where Sam is coming from (a VC spotting market opportunities):

In a certain context, misunderstanding IS a strategic advantage, if you're spotting a market opportunity, and have the resources to exploit the mismatch. You keep a window of opportunity open as long as the misunderstanding persists among those with resources who would otherwise compete.

In another context, interpersonal communication, misunderstanding is NOT a strength, if your goal was to convince people to be on your side. It means you need work on your communication skills. The title is a poor personal maxim to live by, and I hope not the takeaway people had.

As a CEO for a bootstrapped tech startup, coincidentally using Gitlab for our repo, Gitlab's (free) compensation calculator was a godsend as I analyzed the costs of hiring and scaling up. I would never have had access to salary information as nice as this, had Gitlab not put it out there. I certainly don't "deserve" such nice resources on the web, and I appreciate it while it lasted, but is there a way I can find a replacement for information like this?

I think this speaks to the profound duplicity found inside humans. As if they just don't like the consequences of their actions waved in their face. In a lot of jurisdictions, data HAS to be stored locally, for privacy law reasons. So the data center has to go somewhere in the country, and the data center has to draw power from some local source. Given this reality, you just want the power to be clean. An analogy would be that "locals are appalled when they discover that eating meat requires killing animals". Given this reality, you just want the killing to be ethical. Maybe, like meat, put the data centers in some sparsely populated outskirts, out of sight and out of mind, and don't talk about it, sounds like that's what people really want here.