What resources would you recommend?

Difficult question. For scientific visualization, Edward Tufte is my hero and I also like very much the book “Trees, maps and theorems” by Jean-Luc Doumont. For Emacs, I never took the time to follow a proper course on lisp and I mostly use Stack Overflow when I need to find an answer. I also look at people’s code to take inspiration. On that respect, I like very much the work of Adam Porter and Protesilaos Stavrou.

Instead of traditional books or other education media, I’d rather argue a deeper intuition can be honed by simply cataloging works that inspire you with functional and beautiful designs. After carefully combing over that reference pool, you’ll start to become aware of high-level patterns and good practices that will afterwards seem obvious. Picking up that kind of intuition is something I’ve struggled to do passively with books, videos, etc. in the past, so if you also find that approach isn’t clicking with you, I’d encourage you give this a shot. It also has the added bonus of giving you a jump start in learning what your general tastes and design voice may be, based on which designs you gravitated towards and cataloged into your reference pool.

The go-to course I recommend to people that want to start developing for Apple platforms is the CS193p course from Stanford. The latest edition available is from 2021, so it already covers some of the most recent APIs and frameworks like SwiftUI.

https://cs193p.sites.stanford.edu

There are so many resources out now for building iPhone apps. When I started, there were very few, so there was a lot of trial and error. The biggest bit of advice for another developer is if you haven’t yet published an app, do it! In all likelihood it won’t be a smash hit, but you will learn so much that the next one will be even better.

I don’t recalled the exact number, but I’ve probably published 20 or 30 apps in my time - each to varying levels of success.

My advice to anyone who wants to make a personal site of their own:

• Don’t be boring. Seriously — if i see one more white-grey-and-a-spot-of-colour techie website that might as well be someone’s paperwork, i’m going to throw my monitor out a window. And that would be a terrible waste of money on my part, so please don’t.
• Don’t be fancy. Simple HTML, CSS, and a bit of Javascript will get you 99.9% of the way. I’m a hobbyist — i barely even know what a React or a Vue is, and that’s never stopped me, nor did it stop the thousands of webmasters in days gone by!
• Don’t use your tools to talk about your tools. You’ll notice there’s vanishingly little talk about tech on my site, and that’s deliberate: nobody wants to read about that cool programme you wrote in Rust++ or whatever the language du jour is, and certainly, nobody wants to read your blog when the only post on it is explaining that you’ve got this cool new static site blog that you’re totally going to start updating any day now…

For Emacs:

• https://emacsredux.com/resources/

For Clojure:

• https://www.youtube.com/playlist?list=PLXsqD83He-e5oUh_DFrHbO3MoNj3tG8Vh

Following my 3 blogs would expose them to a lot more resources:

• https://batsov.com (personal blog)
• https://metaredux.com (OSS work blog)
• https://emacsredux.com (Emacs blog)

Check out my app “Happy Scale” on the iOS App Store. I’m sorry to say it is not currently available for Android phones.

Happy Scale is my life’s work, and the best representation of what I’m trying to do in the world.

For me the best starting point has been Apple’s Developer documentations and the Human Interface Guidelines (HIG). The Developer documentation has some really good tutorials on getting started with App Development, the HIG is a fantastic primer for UI Design, it’s got everything you need to create a good first interface for your app.

Apart from that, raywenderlich.com and hackingwithswift.com have been really useful. Their tutorials have been helpful for tackling common but tricky scenarios.

For programming? Gosh, there’s too much. Back in the day it was actually really hard to learn programming as you’d need books, the web/internet, or know someone who knows a bit about it. Today, it’s infinitely easier to get started — though I think it’s equally hard sticking to it, and becoming proficient!

The internet is bursting at the seams with amazing resources to learn how to do this stuff. Tons of individuals are making great instructional content, and that’s on top of resources like Stack Overflow and Reddit. Just go try to make a thing to solve a problem you (or someone else) has and Google when you get stuck!

Apple has a wide range of sample projects and sample code on their site, ranging from simpler to more complex, so that’s always a good place to start. I was always a bit of a self-taught man, so as I dug around the system, I experimented and learned from my mistakes. I cannot say that I’d recommend that to everyone, everyone needs a different approach.

But what I’d stress out: don’t forget the basics. It’s nice to learn how to make some UI with a few lines of code. When you see something on your screen, it always appears a bigger accomplishment than spending hours on some algorithm that doesn’t show on the screen, but allows more efficient computations in the background and therefore more responsive app for the end user.

Go low and start with how a CPU works, what are instructions, learn about syscalls, about algorithm complexity. Even if you develop web apps, it’s all quite connected. It seems like some unnecessary evil that would get pushed onto you at school, and I’d seen it this way back in my school years as well, but it turns out that it changes your perspective on how to do things. Usually towards a more efficient and better design of the app (internally, we’re not talking about UI).

The best resources are, honestly, my channel (www.youtube.com/anamorphiconabudget). A good starting point is the “Anamorphic Shooting 101” series, followed by the “Anamorphic Cookbook” modules. The Facebook group “Anamorphic Shooters” is a lively community where you can get lots of questions answered, buy and sell gear, as well as share your progress and gather feedback.

While there’s still a mythology around anamorphic lenses, very few people have gone as deep as I have in making free and consistent content online about them.

Being well read is the best thing you can do for yourself, short of sleep, eating, and collecting vintage computers. It sounds so obvious, but read books about topics you’re interested in pursuing.

Technical writing and blogging are a lot like programming: a teacher or online tutorial can advise you on syntax and best practices, but you only get good at synthesising it from practice. This is why I think blogging is so valuable, which you ask about in a bit :).

If you make it into college or university, take an active interest in the subjects and your lecturers. Don’t be afraid to ask questions. I got my current role after jokingly asking if he had any positions available. Dr Bernard Wong and Dr Asif Gill even took time out to schedule meetings specifically with me to chat. Getting coffee with them and shooting the breeze under the guise of answering questions for assignments was a lot of fun, and hugely rewarding.

Given that most of what I learnt and am interested in came about organically, it is hard to suggest a way to reproduce my experiences. What I do is largely a matter of serendipity. I did not follow anyone and was not working towards something from the start.

Perhaps though there are some insights I can share. One would be to remain dubitative and inquisitive. Learn things for yourself and try to confirm what information you are exposed to and have an interest in. Instead of seeking out an influencer to follow, mark your own path by asking “why” and following up on it.

Where possible, make a habit out of reading the official documentation and relevant resources. Do not sacrifice depth of knowledge for the short-term convenience of getting an answer you can copy-paste. Such easy solutions give you the impression you are taking a shortcut while getting things done, while they actually keep you in the same state of powerlessness — you do not fully understand what you are doing.

Seek high quality reading materials and try to provide those wherever you are involved. For example, dismiss programs whose developer is not considerate enough to write a decent manual for. Not everyone is a domain expert though all deserve to be empowered with the knowledge of how things work and are configured.

As an aside here, we talk about software freedom in a manner that is moralistic/legalistic. That is fine, albeit inadequate. For me, an integral part of freedom is its availability. How can one be free in their computing, for instance, if the otherwise libre program they are trying to use has poor documentation and an inaccessible interface? Freedom presupposes empowerment and that comes about by tending to the accessibility of the tool.

Anywhere art is found (IRL, in print, or virtual) is the best place to start. I’m not sure that there are huge mobs of people wanting to find out more about what I do, to be honest.

Specific resources are constantly changing and usually no more than a Google search away. So rather than providing a list that will be outdated soon, let me describe how I think you should learn to build software.

I find it extraordinarily difficult to learn things in the abstract; I need context and, more importantly, a reason to learn what I’m learning.

So my first suggestion is don’t try learning how to write apps (or any software at all) until you have a spark of an idea of something you want to build - preferably something that solves a small problem of your own.

Once you have that idea, you’ll have a reason to learn, which will motivate you to keep working through the inevitable challenges of learning any new skill.

My second suggestion is to be comfortable “not knowing” and not having a clear plan. Software development, especially when you’re first learning or starting a new project, is often nothing like real engineering. You’re not a carpenter building a table with precise measurements. And you’re not a construction worker with the blueprints for a skyscraper. Those first steps are more like a sculptor with a new block of clay. You start by slowly molding it into a general shape, and then, over time, it gets closer and closer to its final form. You’ll often find that the final product doesn’t look anything like what you first had in mind.

And that’s OK!

So don’t start by googling “How do I build an iPhone to-do app?”. Instead, identify and learn the very first step you need to take. Once done, figure out the second step, and so on. Keep building your knowledge on top of the last thing you learned. Don’t look for a paved road through the forest. Just find a starting point and wander naturally. See where it takes you.

Learning happens best when you feel safe to play, experiment, and make mistakes. The computer science parts and the “real” engineering practices that our industry always seems to get so uptight about can come later.

There are so many more resources for learning how to build software today than there were in 2009. When I started, I was learning primarily through Stanford’s CS193P course on iTunes U and by trial and error, pair programming over late-night Skype calls with Brian. Today, I think folks are best served by resources like Paul Hudson’s Hacking with Swift, Apple’s Swift Playgrounds educational content, and creators like my coworker Mikaela Carron who are posting tutorials to TikTok and YouTube.

But, there’s no substitute for doing it. No matter how many articles you read or videos you watch, you’ll always learn more from opening an editor and starting to work on a real app, preferably on a team.

It’s hard for me to recommend much in the way of resources to learn programming, it’s been incremental learning for me for a long time. I think the most important thing (as, I suspect, with any craft) is to start and keep working at it. I guess one of my favourite books on programming is Writing Solid Code by Steve Maguire, and a lot of that is for the general principle that when you find a bug, you don’t just fix the bug but figure out how you could have avoided ever writing the bug in the first place. Given the complexity of what Keyboard Maestro does, this has really served me well over the years, and I’m pretty proud that I’ve got the Keyboard Maestro crash rate down to around one crash per ten thousand user-days.