The Vision Pro’s R1 Chip is Real-time, not “Fast”

Almost all coverage of the R1 in the press is just a reprint of Apple’s PR, so it just says that the

[…] R1 chip processes input from 12 cameras, five sensors, and six microphones to ensure that content feels like it is appearing right in front of the user’s eyes, in real time. R1 streams new images to the displays within 12 milliseconds

Or some simple variation on that. Obviously, 12 milliseconds is “fast”, but that’s not the point of the R1.

If “fast” was all that was required, Apple probably could have gotten a process on the M2 to average 12 millisecond display times, maybe plus or minus a few milliseconds. The point of the R1 is that it guarantees to do that processing in an exact amount of time. That’s what “real-time” in real time chips and operating systems means. It lets you express your requirements to run tasks in a given amount of real time and can guarantee it before runtime.

This is not the first time Apple tried to get “real-time” working for a single element of a device. In the original iPhone, scrolling with your finger was given such high priority that displaying the view was partially delayed. John Gruber described it well in his review from 2007:

Update: Real-time dragging is such a priority that if the iPhone can’t keep up and render what you’re dragging in real-time, it won’t even try, and you get a checkerboard pattern reminiscent of a transparent Photoshop layer until it catches up (typically, an instant later). I.e. iPhone prioritizes drag animation over the rendering of the contents; feel over appearance.

This was the compromise they had to make in 2007, but in 2023, with the same requirement to prioritize “feel”, they decided to keep appearance this time and trade-off price, complexity, and battery-life.

Write While True Episode 23: Take a Break

Podcast: Play in new window | Download

We just passed the second anniversary of the break that I didn’t come back from right away.

I know exactly what was going on. I had a lot of travel to visit family and for work and it was just hard to find the time to plan and record podcasts.

Well, since it’s exactly two years later. It’s summer again, and I want to take another break. But this time I have a plan to take a break, but still publish on schedule and hopefully, not lose my momentum.

Transcript

PR Authors Have a lot of Control on PR Idle Time

Getting a pull request reviewed quickly is often under the author’s control. This is great news because, according to DevEx, you should reduce feedback loops to increase developer productivity. There are other feedback loops that a developer experiences, but pull requests happen all of the time. You can have a big impact on productivity if they happen faster, and a big reason they don’t is because of the commits in the PR.

At Trello, during a hackathon, someone did an analysis on all of the PRs on all of the teams to see if they could get some insights. At the time, we probably had about 10 teams of about 7-10 developers each.

One thing they looked at was median time to approve a PR based on team, and there were two teams that were far outliers (with smaller waits for a PR to be approved). They went further to look at the PRs themselves and noticed that they generally had fewer commits and the commits themselves were smaller. The number of pull requests per developer-week was much higher than other teams.

I was on one of those teams, and the other one was very closely aligned with us (meaning we had a lot of shared processes and rituals). When we very small, 5 total developers, we were basically one team with a shared lead. The style of PR on these teams was very intentional. When I was onboarded, I was given very specific instructions on how to make a PR.

The essence of what we did was to completely rewrite the commits before making a pull-request to “tell a story”. I wrote about the details in Construct PRs to Make Reviewing Easy.

As a reviewer, this made it very easy to do approvals, which we could fit it in at almost any time. With all of us doing this, many PRs were approved within an hour and most in a few hours. A really good time to do some reviewing was right after submitting a PR, which made the throughput reach a steady-state. The PR list was rarely very long.

I worked in this style for the 6+ years I was on this team and know that it contributed to a high level of personal work satisfaction. Even though I had to wait for others to approve my work, I felt that my own productivity was largely under my control.

Related: Metrics that Resist Gaming

The Tools and Materials of Writing

I sketch—mostly with pencil and charcoal on paper. To do that, I have had to become proficient with the physical nature of the drawing tools and the paper. Over time, I have become better at manipulating them because I do a lot of drawing.

When I was learning programming, I Didn’t Have a Disk Drive, so every day I started by typing in my program from the day before and then I added to it. In that time, I became proficient with the tools of programming—the typing, the code editing.

I was trying to think of what the equivalent was for writing. Typing is certainly part of modern writing. I think it’s good that I’m a fast and accurate typist. But, text editing is very easy compared to code editing.

After thinking about it for a bit, I think a basic part of writing is sentence construction. Sentences are the things you build paragraphs from. And you use paragraphs to build bigger works. Sentences are like marks on a sketch—a basic building block.

If manipulating a piece of charcoal on paper in different ways is the way to practice making marks. What is the thing I could do to practice making sentences?

I have a clue from David Lambuth’s Golden Book on Writing [amazon affiliate link]:

Complex sentences alone make possible that careful indication of the importance of one idea over another and that sense of the interrelation of ideas which is essential to accurate thinking.

Not until you have learned to select almost unconsciously the central, dominating thought of your sentence, and to group around this in varying degrees of emphasis the secondary or modifying thoughts, have you learned to think clearly.

The tool you are learning to manipulate is clauses. Simple sentences are simple. A complex sentence, however, is made up of clauses that are used give nuance to a complex thought, which you express by ordering them.

Just Started a New Software Engineering Job? Fix Onboarding

If you are about to start a new job as a software engineer, the way to have a big impact day one is to go through the onboarding with the intention to generate a list of improvements that you work on over time.

Here are some things to look for

Incorrect or outdated information. If you find these, just fix them as you find them.
Missing entry-point documentation. Even teams that have good documentation often do not have a document that is useful if you know nothing. Often they don’t go back and make a good “start here” kind of document.
Manual steps that could be scripted. Don’t go overboard, but if you see some quick wins to automate the dev setup steps, it’s a good first PR. It’s a tech debt payoff that is timed perfectly.
Dev Setup Automation bug fixes. If anything goes wrong while running the scripts to set up your machine, fix the bug or try to add in any detection (or better error messages) that would have helped diagnose the issue.

There is usually a lot of tech-debt in onboarding code and documents because no one really goes through them. Sometimes underlying things just change and tech debt happens to you. You are in a unique position to make it better for the next person and have some impact right away.

Invest 10% of a team (not of each dev) to pay back tech debt

If you budget 10% of your team’s time to paying down technical debt, there are a few ways you could do it.

Make sure 10% of the story points of each sprint are technical debt related
Assign every other Friday (10% of 2 weeks) to everyone paying down technical debt (see this article for a story about Tech Debt Friday)
Assign 10% of the team to spend 100% of their time paying down technical debt (rotating who this is every quarter or so, or at project boundaries)

I’ve done some variation on all of these ways, and in my experience, #3 works the best. When I was at Trello, my team allocated more like 30%, but tech debt was lumped together with anything “engineering driven”, which was more than just debt payoff (e.g. tooling).

The main reason #3 works better is how companies typically review and reward developers. Something that is 10% of your work is never going to show up on your review. Over time this is generally a disincentive to do it. But, if you are supposed to spend 100% of your time on something, then it has to show up on your review.

Making this someone’s full time job for a quarter means that they can plan bigger projects with more impact. It’s hard to get a PR done in one day, so it takes about a month to get anything deployed at all. When you work on it full-time, you can deploy much more frequently. When I was on a tech-debt project, I would use the first week to deploy some extra monitoring that could measure impact or catch problems.

It allows devs to get into the zone, which is really helpful in giant refactoring or restructuring/rewrite slogs. If you only get one day every two weeks, you have to reacquaint yourself with anything big, which eats into that one day quickly.

It will also make it more likely that this debt paydown is localized. This makes it easier to test that it hasn’t caused regressions.

Finally, (for managers) it’s easier to measure that you are actually spending your budget correctly because you don’t have to monitor individual stories over time. You just need to track how developers were allocated over time.

Knowing Assembly Language Helps a Little

I can’t say I recommend learning assembly, and I never really had to write much professionally, but knowing it has been helpful in giving me a mental model of what is happening inside a computer.

I started with assembly soon after I started programming in BASIC. In the eighties, all of the computer magazines listed assembly programs because that was the only way to do some things. Jim Butterfield’s Machine Language for the C64 [amazon affiliate link] was a classic.

In college, I used assembly in a few classes. In Computer Architecture we had to write a sort algorithm in VAX assembly, and in my Compilers course, we had to generate assembly from C (and then we were allowed to use an assembler to make the executable).

This was last time I wrote any significant amount of assembly, but in all of the time I worked in C, C++, Java, C#, and Objective-C, I found myself needing to read the generated assembly or bytecode on a lot of occasions. There were some bugs that I probably could have only figured out this way. Knowing how different calling conventions work in C on Windows was part of my interview at Atalasoft (and it was actually important to know that on the job).

So, if you have any interest in it, I would try it out. The main issue is that modern instruction sets are not optimized for humans to write. But, I learned 6502 assembler on a C64, and if you learn that then you can get into the wonderful world of C64 Demos.

Approaching Infinity

Moore’s Law predicts that the number of transistors on a chip doubles every eighteen months. But, it has always been understood to be a statement about system capability as well. Speed, memory—we’re even getting advancements in power consumption now with Apple Silicon.

The doubling results in an exponential curve, but at the start, doubling a tiny number doesn’t get you much. My first computer had 4k of memory, but it was already an old model when I got it. By the next year, I had a Commodore 64 with 64k, then a Commodore 128(k) a few years later. My C64 was 1MHz in 1984. In 1992, my first work computer was a 16MHz 386 with 1MB of memory. Nice growth, but from a very low base, so still very underpowered in absolute numbers.

But, just like in personal finance, compounding eventually has enormous impact. It’s not just speed and power. We’re feeling it across all industries. Ubiquitous Software Copilots, Vision Pro, new vaccines, technology-enabled sports analytics, pervasive remote-work—all enabled by the last few doublings.

A doubling means that you have the equivalent impact of the entire industry back to the UNIVAC compressed into eighteen months. And the next 18 months doubles that.

I know this is nothing new. Ray Kurzweil’s Singularity described this in 2005. I’m more pointing out that here we are, and it seems like an inflection is happening where we’re doubling big numbers.

In my 30+ year career as a developer, I experienced a steady stream of big industry shifts. In the 90’s, it was web, then, in the 2000’s, it was web 2.0 and the advent of smart phones. The 2010’s were driven by XaaS (platform, infrastructure, etc) technologies. I could learn these as they happened. There wasn’t instantaneous adoption—you could keep up.

Now these waves are coming very fast, and I wonder if this is what it feels like when you start to approach infinity.

Write While True Episode 22: Harvesting Journals

Podcast: Play in new window | Download

When I was done with a journal, I’d put it on the shelf with others. I do a good job of making sure to transfer anything important to a real tracking system at the end of the day, so there wasn’t much in the journal that I thought would be useful.

At some point, though, I picked up an old journal, it was probably a few years old at that point, and just flipped through it. As expected, it was mostly boring. Just a mundane list of what was going on that day. Meetings, task lists, chores.

But every once in a while …

Transcript

The Second 13 Weeks

At the beginning of the year, I wrote The First 13 Weeks which summarized how I usually set up the first 13 weeks of the year. I am using a Recurring Journal that I designed using Page-o-Mat to run my daily tasks and help me reflect on the year as it progresses. We are almost at the end of the second 13 weeks of the year, so I wanted to give an update.

I build my schedule around weeks, which is why I use 13 week periods instead of months or quarters. They do line up pretty well since 4×13 is 52 and 52×7 is 364. In 2023, I treated Jan 1 as special day, and started the recurring part of the journal on Jan 2, which was a Monday.

The first two pages of the journal show Mondays Jan 2, April, 3, July 3, and October 2, which are exactly 13 weeks apart. In the first 13 weeks, I filled out the top-left quadrant of each page, and this “quarter” I am working on the bottom left of each page. But I can see the day exactly 13 weeks ago. I take time to reflect on that day and notice progress. Since the days that are shown together are always the same day of the week, they are usually comparable.

Doing this motivates me to journal because I know that I will be revisiting each day. There is an empty space waiting to be filled, and I don’t want to come back in a few months and see it still empty.

I have been journaling for many years, but most years there are gaps, usually in the late summer. I seem to have the most energy in the beginning and end of the year and drop journalling for a bit around August. This may yet happen in the 3rd 13 weeks. I’ll check in then to see how it’s going.