For most companies, accessibility isn’t a priority, or worse, something that they pay lip service to while doing the bare minimum to meet regulatory compliance. Ojala’s pet peeve is people thinking that accessibility is a feature, a nice-to-have addition to your product. When they tack on accessibility later, without thinking about it from the very beginning, Ojala can tell — it feels haphazard. (Imagine first creating a product with a colorless UI, then to add colors later as an afterthought, only to use the wrong color combination.)

I heard long ago that the reason developers should start testing software with accessibility in mind is that everyone, at some point in their life, will benefit from accessible technology.

At a minimum, as your eyesight gets older with age, an increase in font size will make it more comfortable to read things.

Any story that revolves around a few people banding together to solve an actual problem, and how that solution literally changed people’s lives, is so inspiring to me.

It’s what I yearn for at this point in my life. I don’t mind making money and building apps which drive business value. The stability of my job has done wonders for my mental health, and I am supremely grateful that I have it.

But boy, wouldn’t it be fun to get to work on something that has an outsized positive impact on people’s ability to live productive lives?

A friend recommended this video to me while I was out with Covid a few months back and I just got to watch it.

Now I get to recommend it to you!

If you are a nerd for process, you will love this. Just one small fact to entice you to watch this: did you know Waffle House employs their own meteorological staff?

You may be thinking: “there is nothing I ever wanted to know about semiconductors.”

I assure you: there is.

This video, created by the excellent Farnam Street, dropped my jaw several times around a topic that is crucial to our way of life, yet is virtually invisible to the vast majority of us.

Take an hour and watch it. It may put many things (including the geopolitical tensions around Taiwan) into better perspective for you.

No. 2: Focus on the Fundamentals

Technology constantly changes, but some fundamental approaches to software development transcend these trends. Here are six fundamentals that will continue to be relevant for a long time.

• Teamwork — Great teams build great software. Don’t take teamwork for granted.
• Trust — Teams move at the speed of trust. Be the kind of dependable person you would want to work with.
• Communication — Communicate honestly and proactively. Avoid the curse of knowledge.
• Seek Consensus — Take the time to bring your whole team along. Let discussion and disagreement bring you to the best solution.
• Automated Testing — Well-tested code allows your team to move fast with confidence.
• Clean, understandable, and navigable code and design — Think of the next engineer that will take over your code as your customer. Build code that your successor won’t have any trouble reading, maintaining, and updating.

Super astute observations, many of which seemed to be hard-earned.

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.