Here are the secret rules of the internet: five minutes after you open a web browser for the first time, a kid in Russia has your social security number. Did you sign up for something? A computer at the NSA now automatically tracks your physical location for the rest of your life. Sent an email? Your email address just went up on a billboard in Nigeria.

These things aren’t true because we don’t care and don’t try to stop them, they’re true because everything is broken because there’s no good code and everybody’s just trying to keep it running. That’s your job if you work with the internet: hoping the last thing you wrote is good enough to survive for a few hours so you can eat dinner and catch a nap.

As poignant, true, and depressing as it was back when it was 2014.

If you engage engineers, you don’t know what you are going to get. You may be unlucky and get nothing. Or their solution may be so outlandish that it is hard to compare with other competing solutions. On average, though, what you get will be more valuable than the gains produced by some tedious restructuring enshrined in a fat PowerPoint deck.

Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance.

I’ve tried articulating this notion to my clients, but now I’m just gonna send them this article.

If you manage a software project, or are interested in software development, Craig’s thoughts are a must read.

Until very recently, Dropbox had a technical strategy on mobile of sharing code between iOS and Android via C++. The idea behind this strategy was simple—write the code once in C++ instead of twice in Java and Objective C. We adopted this C++ strategy back in 2013, when our mobile engineering team was relatively small and needed to support a fast growing mobile roadmap. We needed to find a way to leverage this small team to quickly ship lots of code on both Android and iOS.

We have now completely backed off from this strategy in favor of using each platforms’ native languages (primarily Swift and Kotlin, which didn’t exist when we started out). This decision was due to the (not so) hidden cost associated with code sharing. Here are some of the things we learned as a company on what it costs to effectively share code. And they all stem from the same basic issue:

By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice.

Say it with me: "write once, run everywhere" is a terrible long-term approach for building mobile apps.

One of the biggest reasons we lose leads is because people are swayed by the promise of having a single codebase that runs on iOS, Android, and the web. Solutions like Xamarin, Flutter, and React Native are touted as these golden solutions that will save you time and money.

These solutions, however, introduce a layer of overhead that end up making it more expensive than it would have been if you did it the right way from the start.

If you are looking to build custom mobile software for your business, learn from Dropbox's example and build your apps using native frameworks from day one.

The bittersweet consequence of YouTube’s incredible growth is that so many stories will be lost underneath all of the layers of new paint. This is why I wanted to tell the story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.

As someone who got started developing websites on IE2, IE6 continues to haunt my nightmares to this day. This story made me feel some semblance of vengeance. Kudos to these unsung heroes of the internet.

If you want to develop apps, take your time and make something awesome. Make it fast. Make it beautiful. Make something you’re proud of. Don’t make 60 crappy apps: Make one really good one.

As someone who's about to start an iOS development business, this is exactly the model I intend on adopting. If you make something you want to use (and especially something you're proud of), other people will want to use it too.