Sure, I've done it. It's far from impossible. But it's handy.

When I'm on a trip like that, I'm not usually doing the thing people do where they're absorbed in their phone playing Candy Crush or something. I'm not sitting there watching Netflix all day when I could be experiencing the place where I am. I don't see anything wrong with making use of technology to find my way around and communicate.

To me, saying I shouldn't use my phone is like saying to someone a few decades ago, "Why use your compass or a map?! It's kind of nice to have the challenge of exploring." I mean, fair enough, I sometimes do just wander around when I'm on vacation and get lost, and there can be some fun adventure in it, but it's entirely unnecessary if you're not in the mood for it.

I have two types of vacations: One is to go to some other city to explore, and the other is to get away from it all.

In the first type, having Internet access is great. If you get lost or want to find a particular place, you have maps. If you want to find something to do, you have resources to look it up. You can share your experiences on social media and let friends tell you where to go next. If you're stuck on a bus or a train for a while, you have distractions.

However, if I'm intentionally trying to get away from it all, not having Internet is the way to go. It's extremely relaxing to know that there's no point in worrying about work, because you couldn't check in or help out even if you wanted to. You are simply unable to receive messages or respond, and no one can think you're irresponsible for not checking in.

Even if the only difference is the theme, if you like that theme, then you may as well use the version with the theme you like so you don't have to bother customizing it yourself.

It's not just being cheap and short sighted. That's part of it, but it's not the whole picture.

Basically, having real, good security would eventually require two things:

1. 1) The ability to encrypt information end-to-end in a way that cannot be intercepted.
2. 2) Identity management such that you can potentially link online personas to real-world people.

For the first item, the government doesn't want it because it keeps them from snooping on us (and prevents big companies from snooping, and those big companies are big donors). For the second item, privacy nuts don't want it because it would make it easier for the government to snoop on us (and for those big companies to snoop on us). As a result, we've reached a compromise between the government (and big companies) and privacy nuts. Rather than have real security procedures that would make snooping both easier and harder, we've all agreed to continue on with the current insecure state of things.

If DMARC, SPF, and DKIM are all set up, then at least the email can be more easily identified as spam if it's not actually being sent by bad@phisher.org. If bad@phisher.org is actually sending the emails, then you can blacklist the domain, report abuse, and at least play whack-a-mole with that instead of having all email completely spoofed without any authentication.

In addition to helping to prevent completely willy-nilly spoofing, DMARC also provides a scheme for getting reporting back on how your spam protection is working. That in itself is worth something.

I don't know what you mean. It's actually less problematic when you deploy it for normal person-to-person email. Newsletters and automated emails are a bigger problem because you have less control over where the email is relayed from and whether they implement DKIM. If you don't have SPF and DKIM nailed, the DMARC doesn't do much.

I think the whole thing is relatively reasonable, but the biggest problem I've run into is the limit on SPF lookups. I've seen lots of companies where they have automated emails coming from a bunch of sources, each of which requires a few lookups, and it goes over the limit pretty fast. That, and the fact that some vendors that send email still aren't supporting DKIM.

There's one big, possibly insurmountable problem in approaching hiring as hard science: In order to test whether a specific approach is objectively more successful at identifying good employees, we'd first need an objective measure of whether someone is a good employee.

Someone is going to bring up metrics here. If you're talking about programmers, then you can grade them based on the number of lines of code they write per week, but that doesn't tell you anything about the quality of the code. You could try to account for that by quantifying the bugginess of the code or measuring the performance of the code. But then, is the code readable? Ok, let's say you quantify that too.

Now how do you want to weigh those metrics against each other? Do you care more about performance or readability? It might depend on the role, the kind of product you're making, or who else might be working on or maintaining the code. It might depend on the boss's personal views.

Ok, so you have all of that to contend with, but then there are all kinds of other considerations. Is the new hire a cultural fit for the company? Is the new hire a good personality match for the boss? Will the candidate work well in the kind of work environment that the company has? Some companies are more relaxed and some are more intense, some slow paced and some fast paced, some appreciate directness and some require political savvy.

Even within a company, it can be hard to identify an employee's value. I remember back years ago, I worked at a helpdesk position and they were trying to implement metrics to measure performance. One guy did great by the metrics they were collecting. He closed tons of tickets and put in his notes and time, but his work was sloppy, his notes were poor, and people didn't like him. Another guy almost got in trouble for not closing enough tickets fast enough, until the manager realized that he was taking the hardest cases, and taking the time to help and train his coworkers. I've seen people who aren't the best performers, but they have a great attitude and help keep morale up.

Honestly, as someone who hires and manages people, I find it impossible to quantify an employee's value or compare their worth in any kind of precise or objective way. If you can't come up with a way to objectively measure an employees value, then you won't be able to come up with a way to objectively measure the methods of predicting their value.

Yeah, I don't know C++, and I can't quite tell what that does or why you would do it that way. I'd be interested in an explanation, but I think I understand why you don't like it. I assume it's not just an if/then statement checking if "foo" equals the result of "maybeCreateFoo()".

I'm kind of not a fan of overly clever programming. I get it when programmers come up with something really elegant and clever, and they're proud of it. I also understand that sometimes it might be important to do something in a non-obvious way that optimizes performance. However, sometimes it just feels like they're being too clever by half, or even that they're gate-keeping, making things obscure to so that only L337 h4x0rs will understand.

Maybe it's just because I'm not extremely skilled or clever, but I like things to be stupidly direct, almost so a non-programmer could read the code and understand what's happening. Make simple functions that do what they sound like they do, use variable names that are descriptive, and structure the code to follow roughly human logic. Maybe it's because I'm not a good programmer, but I have a lot of sympathy for the damned fool that needs to figure out my scripts, and I don't want to make it any harder than it needs to be.

So for me, the fact that I can't look at that bit of code and understand right away what it does is a sign that I probably don't want to use it, not unless it does something very cool and useful. Even if it means an extra line or two, I'd rather it be totally clear, even if you're not intimately familiar with the idiosyncrasies of the language.

Sure, but on some level, people have to still decide how they're going to work. Management can, for example, make a decision to pay for Slack or not, to allow Slack or not. Management can even encourage workers to use Slack in certain ways, and limit their use of Slack in certain ways. However, in the end, each user has to make decisions about how and when to use Slack.

The technology has changed rapidly over the past few decades. We need to develop a culture of healthy habits, and we haven't done that yet.

I think the key thing is having shared open protocols and formats. That's the thing we have to get back to.

Right now, you have every company trying to establish their own new walled garden. Instant messaging is a good example-- Facebook has their messenger, Microsoft has theirs, Google and Apple and Slack each have their own. There are dozens of others, and in fact a bunch of these companies have multiple different IM applications, each with their own protocols, and none of them can talk to each other. Why? It's not because any of them are doing anything so complicated that a common protocol couldn't possibly be created.

The problem is that each of these companies don't want to work together. Each of them have some interest in walling you into their "walled garden"-- which should really just be called a "prison". The walls aren't really to keep the bad guys out as much as they are to *keep you in*. Every company wants to have their own little incompatibility built into everything so that you're perpetually locked into using their products, and your friends need to use their products to interact with you.

We need to make a cultural move towards standardizing things again. We need to get together the best minds from Microsoft, Google, and Apple to come up with a model for email 2.0. We need to develop a single set of messaging protocols that can allow people using Hangouts and Teams and Slack and Signal to talk with each other, and to talk with anyone who wants to wants to write their own implementation. We need to create a single set of standards for identity management, including SSO and 2FA and whatever other cool technologies we want, so we can securely authenticate without the risk of phishing.

If we could do that, and restore real freedom to the Internet, then we wouldn't have to worry so much about privacy and EULAs, because you could just use another provider that has better privacy policies. Ultimately, the problem with Facebook isn't that they don't respect your privacy. We've known since they started that they don't respect your privacy. The problem is that, knowing that they don't respect your privacy, you can't simply take your business elsewhere.

I don't think we need to go to PINE. GUI apps support plaintext emails, and there's no technical boundary preventing those apps from always defaulting to plaintext.

It's mostly a social problem. People insist on using HTML. They want cute little pictures in their heavily formatted signatures. I'm surprised we don't see movies embedded in flash games embedded in PDFs embedded in our emails.

If we could agree that email should be text-only, making that happen is trivial. The problem is that we don't all agree.

> I suspect they could implement world peace in the Edge browser and we'd still not trust it. Well yeah, and that's appropriate. It's sort of like, imagine if you had a school bully who constantly tortured you growing up, and one day he shows up with a gift: It's a cupcake. Your favorite flavor. He wants you to eat it. Don't worry, it's just a cupcake. He'll just sit there and watch you eat it. You like cupcakes, don't you? And yes, you like cupcakes, but of course you should be suspicious. Beware of bullies giving gifts, Greeks giving large wooden horses, and Microsoft giving free software.

Well... not really. "Free speech" is for speech that needs to be said, but that the people in power detest. It's just that it's impossible to guarantee that free speech without also allowing speech that I detest, at least when there's no solid legal distinction to prevent it from turning into a slipper slope.

But the purpose of "free speech" isn't to protect the freedom of detestable people to say detestable things. That's just an unfortunate but necessary side-effect.

Just my opinion, but: What we think of as "browsers" should just be split into two different products.

The first should be a classic browser, which is mostly a passive document viewer. It shouldn't really need extensive scripting support or access to the filesystem, hardware, or OS. The assumption should be that you're mostly viewing static pages, or pages that are rendered server-side, but not running "web applications".

The second product should be a cross-platform application framework. Developers can then use this to make distinct applications that the user chooses to trust and run, and should have all kinds of access controls to allow users to control exactly what each application has access to.

One of the problems we have is that the classic browser (static HTML viewer) has evolved to encompass an application framework. As a result, you might be browsing static pages, click on a link, and suddenly you've loaded a page that tries to access your webcam and mic and filesystem. The browser developers have created that functionality so that people can make web applications, but you didn't mean to run an application. You just clicked on a link.

We've completely blurred the lines between "static document I just want to view" and "trusted application that I want to run with tons of access into my private files". Of course we're running into security and privacy concerns. Of course that lack of distinction is going to get exploited. These are totally different things, but we're treating them like there's no distinction.

Yeah, it seems to me that the problem here is, the MBA programs don't make enough money. They should just get some people involved in the program who know how to put together a business plan and budget things properly.