Plannotator is a tool that makes coming up with these plans feel more collaborative and give context or feedback in a much more precise way.

To me, Plannotator is one of the best examples of "chat is a bad UI pattern" since it does such a great job making what felt like typing context-less prose into a back-and-forth conversation, into what feels like reviewing an RFP Google Doc from a teammate.

Plannotator hooks into Claude Code's Plan Mode, so once a plan is devised by Claude Code, Plannotator pops open a localhost website for you. Markup, leave questions or comments, and accept or reject the plan. Any comment will reject the plan, giving your agent another go at creating its best work. Approving a plan sets it off and running.

Comments can be on individual words, sentences, paragraphs, sections or even on the whole plan itself. This context not only helps me from a human perspective (I hate when folks give me a list of feedback in a comment on a PR, rather than asking questions on a per-line basis), but also helps your clanker generate better plans that produce the results you want.

Getting started with Plannotator is about as easy as it comes too (although I wish it came in a Homebrew variant without piping into bash):

# Forgive me father, for I am about to sin.
curl -fsSL https://plannotator.ai/install.sh | bash

# In Claude Code:
/plugin marketplace add backnotprop/plannotator
/plugin install plannotator@plannotator

Give it a go, and watch your plans become more refined, more precise, and your results look more like what you'd expect from your peers.

I wouldn't want to fly on a plane where the pilot said "this plane has autopilot, so I don't look at the controls."

I wouldn't trust a doctor who said "I have no idea what's in this medicine, but it gets results."

I wouldn't hire a lawyer who said "I don't look at the arguments before I make them."

I wouldn't vote for a politician who said "I don't know why UBI works, but it makes people happy."

I wouldn't move into a building where the architect said "I don't look at the structural details. It has four walls and a roof so it's a functioning house."

If your business or side-project works without you needing to look at the code, great. I'm happy for you.

If you are directly responsible for a codebase or product as an engineer, I'd hope you'd be able to know how and why the code works the way it does. You don't need to write every line of it (I don't these days).

Understanding why code works the way it does doesn't require reading every line and memorizing it. Understanding the architecture and design principles does make you a better, more effective engineer, who can build and ship better products faster than the person who needs to have an LLM reinterpret the codebase for every prompt and bug fix needed.

The best makers I know are those who know how and why things work. They can think outside the box to come up with new innovations and solutions. They craft better products not by being first to market (that makes you an entrepreneur, not a maker), but by caring about the little things while the big things take care of themselves.

If you don't understand the code your LLM writes, take a few minutes to ask it to explain things for you. Change the code to understand what breaks when you make changes. I promise your next prompt will give you better results if your brain understands one percent more of how the code works.

Even Simulator.app has a built-in way of recording videos via buttons in the UI now too:

However, one method of recording videos has really stuck with me: xcrun simctl io booted recordVideo.

I've got a lil function in my dotfiles for this command, since I use it so often:

function xcrecord() {
    xcrun simctl io booted recordVideo ~/Desktop/$(uuidgen).mp4
}

I usually use this alongside git commit and git submitpr so my flow looks something like:

# commit my changes
$ git commit -m 'Something new'

# create a PR
$ git submitpr

# record a video
$ xcrecord
Recording started
^CRecording completed. Writing to disk.

Wrote video to: /Users/eliperkins/Desktop/EAB9665D-447E-4033-96B7-FC4D54B7B2D6.mp4

and then I'll drag-and-drop the video into the PR description that's waiting for me in the new tab in my browser.

The result is an MP4 with no artifacting or watermarks that clearly shows the change I've made in my PR.

It's a little quality of life thing that's fit into my workflow as a way to create high-quality recordings from the simulator!

It wasn't Google's lack of privacy controls that did me in, although it was an influence.

It wasn't Google's ad placement that made me switch, although it was a factor.

It wasn't the massive amount of data collection that Google had about it, but I did consider it.

It was the AI Overviews that inserted themselves into every search I did. Instead of letting me be curious about the internet, Google decided it should force-feed me responses to my search query in text form, without sending me to another website instead.

My normal behavior when using a search engine was to search for some query like miami hurricanes football roster or swiftui adjustedcontentinset scrollview, and then scan the results for a reputable website that could give me a believable answer. I'd open the first few links in new tabs, scanning each tab for the results I was looking for. Over time, I'd learn which websites to trust for certain types of content: Stack Overflow for programming things, Reddit for advice while I shopping for Buy It For Life products, Serious Eats for recipes, Sports Reference for a deep dive on sports statistics. The list goes on.

By putting AI Overviews first and foremost on every search query, the first thing I would see would be some regurgitation of what an LLM decided matched by query stochastically. Instead of navigating across the internet, gaining preferences on how I wanted to learn about new things, Google decided to provide their own answer for me. A method I had for navigating the internet was trumped by a wall of text with its own bias. I felt like I was getting dumber every time I typed something into Google. I felt like I was asking ChatGPT for answers every time I googled something, which was very different from how I learned from my searches in the past.

#Switching to Kagi

I learned about Kagi from some tech-adjacent friends. It was pitched as a replacement for Google Search, with a focus on being fast and private. I figured I'd try it out as my default search engine for a day or week or so to see if it could become a full-time replacement.

One day using it became one week using it.

One week using it became one month using it.

One month using it became one year using it.

It felt like a breath of fresh air whenever I used it. I felt smarter again. Instead of feeling like I was being force-fed some LLM-generated response, I got to surf the web again. I learned about new websites, and rediscovered old ones. It stuck in a way I didn't expect. I suspect the macOS and iOS Safari extensions had a lot to do with this.

I tried reskinning it with Kagi's custom CSS to make it look like Google again. After a few hours using it, something felt off, so I reverted back to the stock CSS. Kagi had replaced Google Search completely. Kagi has a million other features to differentiate them from Google that I've explored, from Lenses and Personalized Results to Code Search and Search Shortcuts. I barely scratch the surface of what Kagi offers, since Kagi's base offering is just that much better than the alternative.

#Surfing the Web Again

I've worked in computers long enough to know that Kagi is likely biased in some ways, just as Google or Bing or Yahoo! or AltaVista are. I know technology encodes the biases of those who build them, just as LLMs encode the biases of what they're trained on. I'd rather learn from an interconnected series of URLs shown to me on a webpage than to never go beyond a single paragraph response for information on a given topic.

Kagi recently introduced a similar feature to AI Overviews called "Auto Quick Answer". I'm thankful Kagi introduced a setting to turn this off. I did so immediately after seeing the first one.

I don't want people to see a Google AI Overview, a Kagi Auto Quick Answer, a chat response from ChatGPT as the cold, hard truth. Seeing a list of human-curated websites, understanding each website's spin or bias, and coming to your own truth should be something human brains continue to do. There's nothing learned from a single sentence or paragraph generated by an LLM, there's only laziness.

AI and ML are incredibly powerful tools. I currently use a lot of LLMs, ML and slew other stochastic tools at my job at Particle. I probably sit somewhere between an AI skeptic and an AI optimist, since I have seen first hand what these concepts and tools can do, both good and bad. There are ethically and informationally excellent applications of these tools, but I don't think Google's AI Overviews is either of those.

Here at Particle, we've toyed with a phrase to describe what our product can do for your news consumption:

What are you feeding your mind? Clean up your news diet with Particle.

Kagi has helped me clean up search engine diet to help feed my mind. Kagi helps me stay curious, and to choose my own diet, rather than being force-fed one. I would rather pay $10/month to stay mentally healthy than to succumb to a decaying brain from only relying on LLM responses for facts and learning.

Sometimes a garden fills up with weeds, and just needs an hour or two of someone pulling them up to make things pretty again. Other times it's applying fertilizer to the garden so that it can grow healthy and strong. In a codebase, gardening could be updating a dependency, or fixing that nagging warning that keeps popping up in your logs. Gardening could be taking a look at a flamegraph or stacktrace to figure out if there's a hot path that's worth optimizing.

Gardening is not to be confused with boyscouting in a codebase. Gardening is intentional, going in with the intent of pulling up weeds. Boyscouting is a by-product of some other change you're making, doing a refactor in favor of some feature you're building. I'm also happy to leave Uncle Bob and his terminology back in 2009.

Gardening means getting your hands at least a little bit dirty. It's shutting off Slack notifications for an hour or two, opening your IDE and working on some code in earnest. It's not something you need to ask for time to do, or something that your manager will ever tell you to do. It's about caring for your codebase, since you're living with it day in and day out.

Fridays are great days for gardening in your codebase. An hour or two to close out the week so that when you get back to your codebase on Monday, the weeds are a little less tall than they were last week. Maybe pull a few weeds from your garden today before the week is over.

tl;dr

I love mise (aka mise-en-place) for managing programming language versions.

I'm a bit of a polyglot engineer these days. Most days I write Swift, but there's days I write JavaScript or Ruby or Go or whatever language du jour. Most programming languages and their toolchains share a similar pattern: there's some command line binary you'll need to run to compile/run/interpret your code.

$ node someJavaScriptFile.js
$ ruby some_ruby_file.rb
$ swift run SomeSwiftPackage

These work just fine if you're working solo from your local developer environment. You do some brew install or download some installer for the toolchain from the official website, and you're off running.

#brew install my-tool@v???

A new version of your toolchain is released, and you brew upgrade my-tool to get the latest version. This works great until you realize your CI/CD or deployment environment is on an older version, or some package of yours isn't ready yet, so you'll need to go back to the previous version.

Easy enough to do brew install my-tool@v1, right?

Except now my-tool is on version 1.0 everywhere across your computer, and your client's project is actually on my-tool@v2 already.

You swap between versions by doing a brew uninstall my-tool@v1 && brew install my-tool@v2 in the morning to do your client work.

You swap back with a brew uninstall my-tool@v2 && brew install my-tool@v1 in the evening to do your personal work.

Pure madness. 😩

#One tool to rule them all

mise (aka mise-en-place) helps you manage multiple versions of your toolchains through a few mechanisms:

• Global versions: the default version for your development environment, regardless of current directory.
• Project versions: the resolved version for a given project, based on the existence of a mise.toml file in the directory tree.
• Idiomatic version files: language-specific files like .ruby-version, .nvmrc, .go-version, etc.

Each of these versions coalesce into a set of toolchain versions that are automatically available on your $PATH just by changing directories. It's magical.

#"I've used asdf/nvm/rbenv before, this is nothing new."

Yes yes yes, of course. I used asdf for years too. But what's great about mise is that it Just Works™ for nearly every language or toolchain that I've encountered, without needing to install Yet Another Version Manager.

Over my career, I've used mise with everything from Go, Node, Ruby, .NET and C#, Java, and Rust. 99.9% of the time, mise works right out of the box. Even when my work project needed to have a different .NET SDK version versus the .NET runtime version, a handful of symlinks between mise's isolated installs made it easy to jump between projects that had awkward setups.

Of the tools I rely on in my development environment, mise has become one of the first I install, and one I can rely on out of the box.

Next time you go to brew install some programming language or toolchain, think twice, and use mise instead.

One of my favorite Kent Beck-isms is "Make the change easy, then make the easy change."

for each desired change, make the change easy (warning: this may be hard), then make the easy change

— Kent Beck 🌻 (@KentBeck) September 25, 2012

I'm sure my team is tired of hearing me say it, but it's a great way to break down changes into smaller chunks that are easier to reason about and review. Martin Fowler calls this "prepartory refactoring", where changes are made in preparation for the larger change, making it trivial to make the final change.

One way to do this is to use a technique called "stacked pull requests."

Stacked pull requests is something I've talked about before as part of my "Great Contributions to a Codebase" post. The idea is to break down on monolithic pull request into smaller chunks, each on a separate branch, and where each PR points at the branch ahead of it. Each of these PRs can be reviewed independently, and then merged from the first PR to the last, rebasing along the way as each PR is merged. This daisy-chaining of PRs (as my colleague, Sarah Vessels, calls it) is a pattern of organizing branches where PRs for each piece of functionality make the change easy and then make the easy change.

However, this still involves some human overhead, along with the additional git rebase needed to keep merge history clean as each PR is merged. While it's not a ton of work, compounding with CI time, it can make it tough to keep stacked PRs up-to-date. There's tools that have come out like Graphite's Stacked PRs and Modular's Stack PR tool that help automate this process, but I've found a simpler way to manage stacked PRs that doesn't require any additional tooling.

Earlier this year, I started using git-pile by Keith Smiley and Dave Lee, which is a Facebook-/Phabricator-influence way of creating stacked PRs. In this approach, instead of creating a branch for each commit and for each PR, as a developer, I commit directly to main on my local working copy, and use git submitpr to have git-pile take that commit and create a PR for it. Under the hood, git-pile uses a separate git worktree of my repo, creating a new branch for each invocation of git submitpr, and then pushing that branch to GitHub to create a PR. My main working copy is always in a state I can anticipate, and without the need for an additional set of metadata from a service like Graphite or to daisy-chain PR after PR to keep developing locally.

This involves a bit of a change in my mental model of how I work with git and my codebase. Instead of having a feature-branch-ish approach with daisy-chained stacked PRs, where my functionality lives in a set of n branches, all which depend on each other, instead, I anticipate that my main branch in my local working copy will eventually be the same as what's on origin/main, after responding to feedback from PR review and working with my teammates. However, I'm never blocked from merging my stacked PRs into main because my local main is already up-to-date! No rebasing needed, other than git pull-ing changes from origin/main to my local main.

This has also changed how I stack my pull requests too. I've found ways to break down my PRs into idempotent pieces, rather than daisy-chained ones, where I can set myself up by making the change easy, and then finally making the easy change once the other PRs have been merged.

Let's look at a contrived example. Say I'm working on a feature that requires:

1. Changing legacy code to add a new isFeatureXYZEnabled property
2. Creating a new controller that's used when isFeatureXYZEnabled == true
3. Changing the behavior within the legacy code to use the new controller if the feature is enabled

In a stacked PR model, I'd have three PRs, each dependent on the one before it. So something like:

1. [1/3] Add a new isFeatureXYZEnabled property
   +400/-90 merging ep/add-xyz-feature into main • 1 commit
2. [2/3] Add ModernXYZController for the new feature
   +215/-33 merging ep/add-modern-xyzcontroller into ep/add-xyz-feature • 1 commit
3. [3/3] Use ModernXYZController if enabled
   +10/-30 merging ep/enable-xyz into ep/add-modern-xyzcontroller • 1 commit

However, with a "stackless" stacked PR model with git-pile, I can break this down into two PRs that are idempotent where PR #1 and #2 can be merged in any order (or even simulatenously with a merge queue), and where the third PR can either be stacked on the first two, or wait until I've gotten feedback on the first two and have them merged into main. So something like:

1. Add a new isFeatureXYZEnabled property
   +400/-90 merging ep/add-xyz-feature into main • 1 commit
2. Add ModernXYZController for the new feature
   +215/-33 merging ep/add-modern-xyzcontroller into main • 1 commit
3. [Draft] Use ModernXYZController if enabled
   +625/-123 merging ep/enable-xyz into main • 3 commits

This has sped up my personal development loop a ton, where I can assume that PRs #1 and #2 will get feedback from my team and get merged into origin/main at any point, just like I already have in my local working copy of main! No more branch-of-a-branch-of-a-branch while I get feedback from my team, or needing to rebase daisy-chained PRs. Yes, there are totally times when stacked PRs are needed, and git-pile even supports that flow with the --onto flag, however, this change in my workflow has led me personally to making the change easy first, and then making the easy change. So after merging my PRs in upstream, upstream looks very similar to my local main branch:

There's so much more that git-pile does, and I feel like I've only personally become comfortable with a portion of it yet. However, this notion of stackless stacked PRs is something that can be adopted even without git-pile (even though it does make it so much easier).

Strive to make Kent Beck happy: make the change easy, then make the easy change. And do it with small, reviewable PRs. 🚀

Companies don’t care about release-notes.

And Apple isn’t setting a great example 😂 pic.twitter.com/hQ6ngAPM7a

— Jelle Prins (@jelleprins) January 14, 2024

When GitHub Mobile began to scale from monthly releases to biweekly releases to now weekly releases, we needed to empower our release captains with the ability to write release notes that were not only on-brand, but informative and consistent. I worked with Brian Lovin and the team to put together a set of guidelines to write release notes that focused on the customer, rather than on the company or bragging about the app itself. Every release, that week's release captain would get a list of the changes going into the app, drafted up a set of release notes, and had them approved not by copywriters, but by the team itself, empowering individual contributors, engineering managers, product managers and designers to speak with the same voice.

These are the guidelines we put together for writing great release notes for GitHub Mobile. We hope you can use them to delight your app's superfans with your next release.

Every week we ship new software to our users. The way we talk about our changes matters: release notes build excitement for our new features, inform people about what's fixed or improved, and remind people that our apps are constantly getting better with bug fixes.

It's important for our release notes to communicate clearly and consistently. We want our release notes to have "one voice," be grammatically correct, be ordered by impact on the user, and when applicable, instruct the user what actions they should take next. Also, checkout GitHub's overall Voice & tone guidelines.

#Guidelines

#Naming & Capitalization

Follow GitHub's Brand Content guidelines for naming and capitalizing features and products within release notes.

We reserve capitalization for the products and programs that define the GitHub experience and where it’s needed for clarity. We use consistent capitalization across marketing pages, docs, blog posts, and wherever else the name appears at launch and subsequently.

#Rule of thumb

When first introduced, primary GitHub owned projects, products, and features are capitalized, like GitHub Codespaces. After that, you can drop the GitHub and simply refer to the feature by its name, Codespaces. When referring to the feature in the product, it’s sentence cased (e.g., New codespace for button text or Codespaces as a navigation link).

#Lowercase

Use lowercase names for features and products that aren’t distinct to or ownable by GitHub.

Examples: insights, accounts, payments, integrations, pull requests, security alerts, search

#Capitalized

Use capitalized names for features and products that are distinct to or ownable by GitHub.

Examples: Octocat, Pulse, Enterprise Server

Some features and products can introduce confusion into an experience if not capitalized:

Examples: GitHub Pages, GitHub Projects

Note: Use GitHub Projects on the first instance it is used in writing. After capitalize Projects when you are referring to the capability (feature) but this is not necessary if you are talking about it as a noun (i.e. You can share projects with your team.).

#Tone and tense

#Avoid third-person when talking about GitHub or our team

Avoid using the word we in release notes. Instead, focus attention on the features and the benefits themselves.

- We made it easier to do foo.
+ A new widget makes it easier to do foo.

It is fine to address users using the personal you, as this still describes the benefit to the user: Foo makes it easier to see the status of your bar.

#Avoid the word now when indicating when the change will affect the user

In most cases, this word can be dropped to better indicate the fix and plays nicely with the "Make it concise" principle of avoiding superfluous terms. If the user is reading the release notes about a given release, the timeframe is implicit based on installing the update.

Leverage the imperative mood followed by the outcome for the user.

- Nested task lists now indent properly in issue comments.
+ Nested task lists indent properly in issue comments.

- You can now view threaded comments on pull requests.
+ View threaded comments on pull requests to see what others are saying.

- Your scroll-position in code views is now correctly maintained when rotating your device.
+ Rotate your device without losing your scroll position in code views.

#What's New

New features, or noticeable improvements to existing features, should always be in the What's new section of the release notes.

#Focus on outcomes and behavior changes

Users want to know how changes or fixes affect their day to day lives. Does it make something easier? Is a new action possible? Is a flow faster? Rather than plainly describing a change, try to emphasize the outcome or benefits for a user.

- Support quote reply for discussions comments
+ Quote reply a comment in a discussion to keep the conversation going.

#Write like a human

Write like a human. Explain what's new in a professional, but not stuffy way. We're talking to real people, and they expect honest and clear communication.

- Added profile tab to make it easier to navigate.
+ A new Profile tab makes it easier to get to your profile from anywhere in the app.

#Use full sentences

Use complete thoughts to clearly communicate an idea or feature.

- Viewing repositories list on iPad shows split view
+ Viewing a list of repositories on iPad shows the list and repository details in a split view.

#Milestone ships are "introduced"

For our milestone ships – like Discussions – we "introduce" the new functionality with a more excited announcement-like voice. In these cases, use a few sentences to describe the core functionality, and guide users to the place where they can try the new feature.

- Discussions are now supported. Create, edit, and delete discussions in repositories where Discussions are enabled.
+ Introducing Discussions, a new way to connect with your community, team, and collaborators on GitHub! Share new ideas, ask questions, and find inspiration within your repository.

#Use an active voice

Use active verbs like "viewing" and "tapping" and "browsing" instead of their passive variants like "When foo is viewed" or "When foo is tapped".

- When a new issue is being created, there is now a loading spinner.
+ Creating a new issue shows a loading spinner.

#Bug Fixes

People may scan bug fixes to see if an issue they reported or experienced is now resolved. Because people are scanning this list, we must make our documentation concise and front load the fix in our copywriting.

#Focus on outcomes and behavior changes

Users want to know how bug fixes actually affect them. Are they now unblocked? Is their specific use case now supported? Focusing on behaviors creates incentive for users to poke around and try things in the apps.

- Tapping on a notification no longer selects the wrong notification
+ Tapping on a notification selects the correct notification.

#Make it concise

- We discovered that when people were navigating through the file tree, if they long-pressed on the back button, there would be cases that the app could crash. This is now fixed.
+ Fixed a crash that occurred when navigating files and long-pressing the back button.

#Front load the fix

Quickly communicate the feature or surface where the bug fix occurred so that people can quickly decide if it's important to them.

- When there is expandable content, and when dark mode is enabled, user profile READMEs render correctly.
+ User profile READMEs with expandable content render correctly in light and dark mode.

#Use active voice when possible

This isn't always possible for certain kinds of bug fixes, but when possible we should maintain an active voice when describing fixes.

- Fix nested task list indentation
+ Nested task lists indent properly in issue comments.

#What if we have a week with no user-facing changes?

Has the team been heads down on new features behind feature flags? Is the changelog full of only feature-flagged changes? That's okay!

Release notes are one of the few points of interactions that we have to communicate directly with our customers. By using release notes like "Bug fixes and performance improvements," we've given away an opportunity to tell our customers what great features we've been hard at work on over previous weeks as well. Additionally, "Bug fixes and performance improvements" is an opaque phrase which doesn't indicate to our customers where those fixes can be found or what performance has been improved. Let's do better than this!

As release captain, if that week's release notes have no user-facing changes in release notes:

1. Use the previous release's release notes.
2. If last week's release notes include an "Introducing" change, check in with that team to see how to best rephrase that line!

This gives us a second chance to communicate the changes that our customers will get in that build, as well as giving the previous week's release notes another week to get in front of our customers.

If a feature has been "Introduced", feel free to work with the epic team to adjust the copy such that "Introducing..." can be adjusted to the benefit of that feature. For example:

- "Introducing Actions! View workflow run details and manage your pull request checks on the go."
+ "View workflow run details and manage your pull request checks on the go with GitHub Actions."

To re-iterate, it's okay to have weeks where we have no user-facing changes. When that happens, use the previous week's release notes for this week's release notes.

I wrote up this document for our repo's CONTRIBUTING.md to try to capture our growing team's guiding light in what made a great pull request or the building blocks of a great feature. A good chunk of it still holds true today. Here's github/mobile-ios's guidelines for great contributions.

#Development Principles

#Testing

#Leverage unit tests to prevent bugs, regressions

Caught a bug and found a way to fix it? Great, you're halfway there!

One way to prevent a bug from recurring is to write a unit test around the bug. Writing a failing test that isolates the bug and refactoring using "red, green, refactor" will not only fix the bug but give the codebase a way to ensure other changes don't break it again in the future.

#Prefer unit tests before snapshot tests

Prefer unit testing behaviors on view models to assert behaviors. View models allow for testing at a more granular level without involving UIKit.

#Prefer snapshot testing an individual view before snapshot testing a view controller

If a snapshot test is a useful way to test a behavior (e.g., asserting correct rendering of view in light mode and dark mode), prefer testing an individual view in isolation, rather than testing the whole view controller.

#Snapshot tests as a tool in the toolbox, not a hammer for all tests

Remember, snapshot tests are only one tool that you can use to write tests. Before jumping to writing a snapshot test, ask yourself what behavior is trying to be tested. What assertions can be run on the view model before we test the view layer? What assertions can we run on an instance of a view controller, rather than rendering the view controller in its entirety.

All snapshot tests will involve UIKit as part of the system under test, meaning changes to UIKit will affect the test itself. We've seen snapshot tests be invalidated between iOS versions, Xcode versions, operating systems and more, so ensure that these variables are acceptable to the test you're writing.

#"Core before more"

#Prefer well-tested features over rushed corner-cutting solutions

Got that new mockup in Figma that you're ready to crank on? Great! Take a moment to think about how to best land it into the codebase and what tests you might write as a part of your PR.

If you feel like landing a particular feature might take twice as long to do properly, that's totally okay! Let your team know, talk to your engineering manager about it, and ensure that writing tests is part of estimates on your project.

#Use TODOs and linked issues to track follow-ups

#Leverage feature flags to roll features out while still landing code into main

One great way to move at a higher velocity while still writing well-tested code is to leverage feature flags to hide your feature in production until it's ready for prime time.

Feature flags can also help you deploy features to certain environments or "rings", like only to TestFlight or only staff users. Use this to get feedback from a specific group of folks, rather than rushing out to production.

#Refactor existing code in-place

Rather than rewriting code anew, prefer refactoring existing code in-place with a series of changes.

If it's tough to refactor a certain pattern in-place, try using a feature flag to allow for toggling between the new and old code.

#Prefer consistency in patterns, code style

Follow established patterns within the codebase by default.

Have a new pattern that feels like it'd work out well? Great! Put the pull request up and start a discussion with your teammates.

Need a new pattern to accomplish a task within the codebase? First, ask yourself if there's a way to do this without a new pattern first. If not, cool! Put the PR up and discuss it with your teammates.

#Small atomic pull requests

Prefer pull requests that accomplish a single, focused change. Consider how easily your pull request could be reverted if needed.

#Use stacked pull requests to break down a large diff or set of features/functionality

To keep code review as focused as possible, break up your large pull request into a series of pull requests.

Instead of one PR like:

• Add XYZ feature
  +1,029/-1,390 merging ep/add-xyz-feature into main

Prefer breaking up the PR into a series of pull requests like:

1. [1/3] Add GraphQL module for XYZ
   +400/-90 merging ep/add-xyz-graphql into main
2. [2/3] Create XYZ view controller
   +215/-33 merging ep/create-xyz-viewcontroller into ep/add-xyz-graphql
3. [3/3] Use custom XYZ control throughout the app
   +325/-333 merging ep/custom-xyz-control into ep/create-xyz-viewcontroller

This will create three discrete pull requests for your teammates to focus on, allowing for a better review of the code you wrote and for better code to be landed in piecemeal.

Further reading:

• git-pile
• "Stacked pull requests: make code reviews faster, easier, and more effective"

#Code Review

#Feel free to review pull requests from other projects

Leverage code review as a place to ask how another feature is being built. Dig deeper into a feature to learn about it's architecture or the product itself.

Keep in mind that informed decisions may have been made by other folks on the team, so ask questions and get curious!

#Ask for tests during code review

Do you see some code that might have complex behavior that isn't obvious or is potentially brittle? Asking the author for some tests is okay! Tests are not just for the author but also for Future Us™ as we change the code around it.

Code review is a great time to ask how certain parts of a pull request could be tested. Tests can also provide clarification on certain behaviors, allowing for complex states to be modeled and asserted against.

#Submitting Pull Requests

#Leverage pull request templates

Add further description about what the change that is being made does. Clarify questions that you think reviewers might have. Add steps on how to test the change out locally. Indicate if a change might be risky or requires other changes as well.

Pull requests currently have a template to help you answer some of these questions while also providing a consistent format for reviewers to learn more about the change you're proposing.

#Git commit style

• Use the present tense ("Add feature" not "Added feature").
• Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
• Try to limit the first line to 80 characters or less.
• Focus on "why" within the body/message of the commit. Let your code focus on "what" changed.
  • e.g., "This refactor allows the app to send a query that works on all GitHub Enterprise instances" not "This changes the query by adding the foo field and removing the bar field"
• Reference issues and pull requests liberally after the first line.
  • Use phrases like Closes #1039 to automate closing issues when your pull request is merged.
• Avoid writing commits like Fix bug, preferring more description
  • Remember that the git commit log will be helpful to Future Us™ and Future You™ too! Running git blame on code is a great way to get context as to why code is written a certain way.

#ADRs

ADRs (or architecture decision records) are a great way to capture a snapshot of what decisions led to a certain architecture within the codebase.

Have a question about how different parts of the codebase work together? Curious as to how a certain module is architected? Check out the ADRs for it!

Writing a new module with a bunch of surface area? Have a proposal for a new architecture or pattern to follow? Write an ADR for it!

Our ADRs are stored within this repo at docs/adrs, but you can also find more ADRs within github/mobile for ADRs that affect both iOS and Android.

Further reading:

• GitHub Blog: "Why Write ADRs"

#Project Planning

#Estimate time needed to write testable code as part of project planning

Even if the smallest possible change to accomplish your feature could be made within a day, ensure that you're also accounting for the time it takes to test the feature. "Testable code" could mean writing unit tests, refactoring to allow for writing tests, or spinning up a development environment to test the feature itself.

It's okay (and encouraged!) to advocate as much time as needed to write and test a new feature. Work with your team to ensure that estimates match what all folks on the team expect.

#Break down epics into smaller milestones to ship more often

Talk with your team about sequencing a series of changes that ship to production rather than bundling a ton of code behind a single feature flag.

By shipping incrementally, we can gain more feedback and iterate towards correctness. This will let you focus on smaller diffs and changes as well!

#Submitting Bug Reports

Bugs are tracked as GitHub issues. When you've come across a bug within GitHub for iOS, create an issue in github/mobile-ios and provide the following information by filling in the "Bug Report" template.

Explain the problem and include additional details to help us reproduce the problem:

• Use a clear and descriptive title for the issue to identify the problem.
• Describe the exact steps which reproduce the problem in as many details as possible. For example, start by explaining how you opened the app and navigated to that screen, where you tapped, how you were able to get into a fixed or different state.
• Provide specific examples to demonstrate the steps. Include links to relevant content on GitHub.com to help us reproduce or navigate back to that screen within the app.
• Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
• Explain which behavior you expected to see instead and why.
• Include screenshots and animated GIFs which show you following the described steps and clearly demonstrate the problem.
• If you're reporting that GitHub for iOS crashed, include your device info (what model iPhone/iPad? cellular or wifi?), operating system information, and version and build of the app that you're using (you can find this in the footer of Settings within the app).
• If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened and share more information using the guidelines below.

As most developers do, I let my blog languish, and only really updated my personal site on occasion, like when I got a new job.

Last summer (2023), I got married, and as is a developer's rite of passage, I built my own wedding website. I really wanted to learn Next.js, and play around with technologies that were absolutely overkill for a website that would be used for a single event. In the process, I learned what a joy Next.js is to use, along with how productive I can be with Tailwind CSS. While I've written JavaScript professionally before, it's been many years since I've written JavaScript in earnest, so it was refreshing to once again experience how great the tooling can be when your developer tools aren't a black box built by one company (looking at you, Apple).

Since then, I've been looking at my Dependabot warnings growing in my personal website and blog, and also feeling like their design was rotting nearly as fast as the code instead the repo was. So as a fun educational side project, and knowing what it'd take to create a new Next.js app from my experience with my wedding website, I took the plunge to rewrite both my personal site and blog in Next.js.

After a few days, I had tossed all the old Gatsby code out the window, and had a prettier, more modern, more performant personal site and blog that I feel proud of again. Instead of having a dated look and legacy code as my footprint on the internet, I had a site that I can easily update with a quick git push.

Here's what I learned:

• Tailwind slaps, and makes me feel like a designer. 🎨 I can bring the design ideas that I know from mobile development, and apply a loose design system to my sites with just some HTML class names.
• There's no need for GraphQL in a static site which doesn't fetch data from the internet.
• Bringing my old blog content over from Gatsby to Next.js meant loading in and parsing Markdown files at build-time.
  • I want to explore using MDX for Markdown in blog posts in the future.
• Yarn PnP and zero-installs are trivial to set up these days.
  • Do I need it for my personal site/blog? Definitely not.
• Next.js makes it easy to do code-splitting, SSR, and in general, create a modern performant site, without needing to think about the technical concepts. I feel productive with it in a way that I don't feel with other tools.
• Having a site with continuous deployments on Actions, that I can just commit and push to makes it easier to make quick updates to content without needing to remember what credentials I need or what incantation of AWS APIs or button clicks are needed.
• I can still write functioning JavaScript.

For the curious, here's the tech stack overall:

• Framework: Next.js (with app directory)
• Styling: Tailwind CSS
• Hosting: AWS S3 + Cloudfront + Route 53
• CI/CD: GitHub Actions
  • @static/discharge for easy deployments (which I should contribute back to!)
• Markdown parsing: Remark
• RSS: feed
• Other: TypeScript, Yarn, Prettier, CodeQL + Dependabot

Want to learn more? Reach out to Eli via email or on Mastodon.

tl;dr: Use relay --validate to catch Relay validation errors in CI!

I'm a big fan of GraphQL (seriously, ask me about GraphQL). One tool I've been absolutely loving lately has been Relay. We use Relay at Clubhouse to build some really awesome features in Clubhouse for iOS. As of the writing of this blog post, we've got nearly 100 different components using Relay in some way, shape or form!

#Hold up, what's Relay again?

Relay is to GraphQL and data fetching what React is to DOM and UI. It's a declarative way to dictate what data your components need, rather than how and when to fetch it.

A typical use-case of Relay looks something like this. Say you've got an social media app that shows a list of friends for the current user.

Each of these components gets data from a different part of our tree. We can colocate our queries of how to fetch the data for each component using Relay. A common way to do this is using Relay's createFragmentContainer (there's other methods to do this too, to handle pagination, refetching, etc. , but for the sake brevity in this post, let's focus on fragment containers).

Some of the components may look like this:

// in src/Avatar.js
const Avatar = ({ user }) => <Image src={user.thumbnailImgSrc} />;

const AvatarContainer = createFragmentContainer(
  Avatar,
  graphql`
    fragment AvatarContainer_user on User {
      thumbnailImgSrc
    }
  `,
);

// in src/FriendListItem.js
const FriendListItem = ({ user }) => (
  <View>
    <Avatar user={user.thumbnailImgSrc} />
    <Text>{user.name}</Text>
  </View>
);

const FriendListItemContainer = createFragmentContainer(
  FriendListItem,
  graphql`
    fragment FriendListItemContainer_user on User {
      name
      ...AvatarContainer_user
    }
  `,
);

// in src/FriendsList.js
const FriendsList = ({ currentUser }) => (
  <FlatList
    data={currentUser.friends}
    renderItem={({ item }) => <FriendListItem user={item} />}
  />
);

const FriendListItemContainer = createFragmentContainer(
  FriendListItem,
  graphql`
    fragment FriendListItemContainer_currentUser on CurrentUser {
      friends {
        ...FriendListItemContainer_user
      }
    }
  `,
);

Now each of our components composes together both is UI components and it's data-requirements, declaratively!

#Dope. Relay seems cool. But what's this __generated__ directory I've got here?

The Relay Compiler will read through our source code to find Relay components and their colocated GraphQL queries to generate artifacts that will be used by the Relay runtime.

These artifacts look something like this (abbreviated here):

// from src/__generated__/AvatarContainer_user.graphql.js
const node /*: ReaderFragment*/ = {
  kind: "Fragment",
  name: "AvatarContainer_user",
  type: "User",
  metadata: null,
  argumentDefinitions: [],
  selections: [
    {
      kind: "ScalarField",
      alias: null,
      name: "thumbnailImgSrc",
      args: null,
      storageKey: null,
    },
  ],
};
(node/*: any*/).hash = '693ff4889bc9965ae9f6512d628b7292'; // prettier-ignore
module.exports = node;

We can see that for the Avatar component, the compiler generates a static set of data for the GraphQL fragment it needs to fetch the data.

Relay recommends checking in these artifacts from the Relay Compiler into your source control, as they're crucial and necessary to run your app.

As you work through your app, you'll likely run yarn relay --watch to run the compiler in watch mode to automatically generate these artifacts and as you build new components, pages, features and so on. You'll see that as your change your GraphQL queries, the Relay Compiler will indicate what is changed, and you can see the changes in your git diff as well.

❯ yarn relay
yarn run v1.15.2
$ relay-compiler --src ./src --schema ./schema.graphql --watch

Writing js
Updated:
 - AvatarContainer_user.graphql.js
Unchanged: 2 files

❯ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   src/Avatar.js
	modified:   src/__generated__/AvatarContainer_user.graphql.js

However, these artifacts are only autogenerated if you run the Relay Compiler while you're working! If a team member (or even yourself) forgets to run yarn relay while you're working, and a GraphQL query changes, your generated artifacts will be out of sync with your product code! 😰

🤔 So how do we fix this? How do we prevent our product code's queries from coming out of sync with our autogenerated Relay artifacts?

Luckily, Relay makes this easy.

The Relay Compiler includes a flag called --validate. This flag will run the Relay Compiler and if there are any autogenerated artifacts that will be overwritten based on the GraphQL queries, the compiler will indicate that an artifact is our of date and exit with an error.

❯ yarn relay --validate
yarn run v1.15.2
$ relay-compiler --src ./src --schema ./schema.graphql --validate

Writing js
Out of date:
 - AvatarContainer_user.graphql.js
error Command failed with exit code 101.

This makes it really easy to validate your Relay codebase in CI, just as you might run your tests in CI! Add relay --validate to your CI flow today and catch changes in GraphQL queries before they land on master.

The tl;dr on this proposal is that all classes that are marked as public will not be able to be subclassed unless also marked open. Additionally, it’s functions, variables, and subscripts would also not be overridden unless explicitly marked as open. This means that classes will end up having behavior that some have dubbed "final by default" for any publicly available class. This behavior would eliminate the need for the compiler to generate dynamic dispatching for methods and properties since their implementation cannot be changed after compiletime. While the elimination of dynamic dispatch is a performance boost, this means extra care and attention will be required to turn dynamic dispatch back on for those who want consumers to override the functionality of of their publicly exposed classes.

The changes here are quite interesting. People have taken to blogs and Twitter to express their opinions about how this will affect their development and workflow.

One argument against the proposal that I’ve often heard has been that been that this reduces, if not entirely eliminates, the dynamism of a language like Objective-C. There’s no getting around that elephant in the room; this is a major change.

However, I do think there are some resulting behaviors that have the power to push some core values forward in a way that will make Swift an even better language to work in.

#Lean on Protocols to Define the Behavior You Expect

APIs that expose functions that take in protocols rather than classes or subclasses will flourish. We don’t need to wrap up our intended behavior or properties into a class just to get the code we need run, but rather we can make the decision to use a struct or class, choosing value vs reference semantics.

This means that no matter what type we pass in, we’ll be able to get some property or call some function, regardless of what class, subclass, or subsubsubclass with its subsubclasses pass in.

This will lead to SDKs that don’t make you subclass XYZModel for their behavior and will allow you to create beautiful, testable, understandable, comprehensible code. The extraction of MTLModel in Mantle from a class to a protocol in this PR is almost a case study in the benefits of this type of API design. By moving the behaviors of MTLModel off to protocol implementations, consumers of Mantle were no longer forced into making their types inherit from MTLModel, but let them choose their type that implemented the behavior. Craziest part of all? This conversation was happening in Objective-C-land, not Swiftopia.

Arguments against this proposal that circle around “subclassing lets me write code that I can test” are immediately moot if the API that they are trying to test takes in a protocol rather than a class.

For more about this, watch me wax poetic about Mocks in Swift via Protocols.

#Encourage Composition over Inheritance

Clamping down on how classes’ behaviors can be modified or extended means that developers will need to find other ways to get the results they need.

Creating types that compose other types will be one opportunity Subclassers™ can use to create types that give the behavior they’re looking for. Packaging their final class into another type that executes the final class’s behavior and then returns its own behavior based on the results of that.

This will lead us towards a clearer business logic in types, that are more flexible and have less responsibilities. Gone will be the god/Grob Gob Glob Grod objects that have subclasses on subclasses just to get the behaviors they want. A series of classes that compose together can more clearly define intention and responsibility.

#Alternatives Considered

I would have loved to seen this implemented as an opt-in compiler-time flag, rather than a syntactical level keyword. As a language feature, some may want it, and benefit from it, while others may shy away or not understand it’s consequences. By having the compiler determine at compile time, with a flag such as Disable subclassing on public classes, we could still write the code we want, while being flexible enough to generate code and interfaces that we need.

While I may not be a ?? on the semantic implementation, I’m ?x? on the value that final by default would bring.

But with Swift, there might be a better way to setup our programs that don't require Objective-C funtime runtime hacks and swizzles.

#Mocking UIApplication

Let's take a look at an example which mocks out our favorite hard-to-test class, UIApplication.

In our example, let's work on a type that handles push notifications.

struct PushNotificationController {
}

The goal of this type will be to have some function which we can call to ask the user for the permission to send push notifications, via UIApplication's registerUserNotificationSettings(_:), maybe handle some pushes and delegate calls for device tokens and such, etc.

We want to trigger push registration to be off of some state, say maybe once our user logs in, so that we don't bombard our new users with alerts without actually using our app first. A naïve approach might be to just create some function which calls UIApplication.sharedApplication().registerUserNotificationSettings(_:).

struct PushNotificationController {
    var user: User {
        didSet {
            let application = UIApplication.sharedApplication()
            application.registerUserNotificationSettings(_:)
        }
    }
}

Easy, right? Okay, now let's go test this functionality so we know that we can write some unit test around PushNotificationController to know that we actually do register for push notifications when we give it a user.

import XCTest

class PushNotificationControllerTests: XCTestCase {
    func testControllerRegistersForPushesAfterSettingAUser() {
        let controller = PushNotificationController()
        controller.user = User()
        // uhhh... now what?
    }
}

#What's in a Test?

Let's take a step back here and figure out what has made our code untestable. There's a couple things that we're fighting against. We don't own UIApplication or it's sharedApplication() method, so it's a bit difficult to substitute our own functionality into these. Additionally, we don't have a way to know if calling UIApplication.sharedApplication().registerUserNotificationSettings(_:) really does anything in our unit test. We can't assert that the screen has the alert view on it now.

What are we really trying to test here? We shouldn't be testing UIKit, there's a few Apple engineers out there whose job it is to do that. We really just want to test that our type asks the relevant party to register for push notifications, and in this case it just so happens that the relevant party is a UIApplication.

#Protocol-Oriented Programming

So how can we get a bit of flexibility here? How can we verify our type?

I propose that protocols are the best way to mock types in Swift.

Let's create a protocol here to stand in for UIApplication.

protocol PushNotificationRegistrar {
    func registerUserNotificationSettings(_:)
}

Super simple. A PushNotificationRegistrar is any type that has a function registerUserNotificationSettings(_:) to call.

Next, let's dependency inject a PushNotificationRegistrar into our PushNotificationController.

struct PushNotificationController {
    let registrar: PushNotificationRegistrar
    init(registrar: PushNotificationRegistrar) {
        self.registrar = registrar
    }
}

Perfect. Now instead of calling registerUserNotificationSettings(_:) on UIApplication.sharedApplication(), let's instead call it on our registrar.

struct PushNotificationController {
    let registrar: PushNotificationRegistrar
    init(registrar: PushNotificationRegistrar) {
        self.registrar = registrar
    }

    var user: User {
        didSet {
            registrar.registerUserNotificationSettings(_:)
        }
    }
}

Beautiful! Now there's no more UIApplication.sharedApplication() to be seen! Less global state gives us a bit more wiggle room in our unit tests.

#Hooking up UIApplication with PushNotificationRegistrar

But if we don't have UIApplication.sharedApplication() ever, how do we get our application to register, you ask? This is where an amazing part of Swift's elegance comes into play.

We can conform any UIApplication type to PushNotificationRegistrar in one line of code:

extension UIApplication: PushNotificationRegistrar {}

Boom. Done. Since UIApplication already has a method named registerUserNotificationSettings(_:), it's already implementing our protocol. In our application, we can simply just create a PushNotificationController in our application delegate, say in application(_:didFinishLaunchingWithOptions:), like so:

extension AppDelegate: UIApplicationDelegate {
    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]?) -> Bool {
        let controller = PushNotificationController(application: application)
        controller.user = User()
    }
}

and just like that, we're on our way to registering!

#Testing with Mocks via Protocols

Now let's write a test around it. In this case, we don't want to give it a UIApplication because it's hard for us to get one and it's simply not testable, like we mentioned before. So instead, let's put together a quick type that does some faux registration for us.

import XCTest

class PushNotificationControllerTests: XCTestCase {
    func testControllerRegistersForPushesAfterSettingAUser() {
        class FauxRegistrar: PushNotificationRegistrar {
            var registered = false
            func registerUserNotificationSettings(notificationSettings: UIUserNotificationSettings) {
                registered = true
            }
        }

        let registrar = FauxRegistrar()
        var controller = PushNotificationController(registrar: registrar)
        controller.user = User()
        XCTAssertTrue(registrar.registered)
    }
}

Et volia! We just created a test that our application should register for push notifications after setting a user!

#What Would Crusty Do?

Creating mocks via protocols in Swift is great for reasons beyond just unit testing UIApplication methods. Protocols contribute greatly in creating boundaries around pieces of your architecture and can make sure your make sure your software doesn't become too crusty.

This isn't anything new to Swift, but rather certainly a pattern that is very trivial to implement in many places now. Protocol extensions with default implementations might even push this method forward more as Swift 2 develops more.

You can find a playground demoing some functionality of this here: https://gist.github.com/eliperkins/8f4115151497dc1953ea

#Predictions

• iOS 8
  • Lots of performance polish, a la Snow Leopard
  • UIMotionEffect improvements (full under-the-hood rewrite?)
  • Touch ID APIs
  • Some unifying API to talk with BLE-, WiFi-, etc based devices
  • Tint color becomes über important and defining, even more so than iOS 7
  • Fast, fast, fast and fast
• OS X.10 aka Huntington (shot in the dark here)
  • New UI similar to this
  • UIKit for OS X
  • Siri integration
• iOS ↔ OS X AirDrop
• Xcode 6
  • Overhaul of Instruments
• Some sort of new platform for iOS and OS X development with JavaScript roots
• Apple Beta Program
  • Beta testing of iOS and OS X apps a la Testflight
  • No limit to beta testers (won't count against developer's 100 devices)
  • Better crash reporting
• App Store app and music gifiting
• MacBook spec bumps across the line, end-of-line for non-Retina MacBooks
• A very average game demo from some company who has been trying iOS 8
• Craig Federighi stealing the show as per usual

#Wants

• Objective-C 3.0 ^^^Just ^^^to ^^^make ^^^all ^^^the ^^^haters ^^^stop ^^^their ^^^bitching.
• XPC on iOS (what I really just want is Android-like intents...)
• Better permissions on iOS
• Siri API of some sort
• OS X does away with sandboxing
• OS X Safari notifications to become just OS X notifications

Almost every tweet, every blog post, every Quora answer I would read really only showed me one thing: the entitlement that many of these opinions carried, as if their opinion was not just an opinion, but rather fact.

Everyone is entitled to their opinion, sure. But to bash others for their opinion is just wrong.

This type of blatant disrespect /against others/ literally keeps me up at night: http://t.co/S6deW2xlZP

— @alloy@mastodon.social (@alloy) February 13, 2014

The way I've noticed a lot of iOS dev's acting lately has been a lot like an old man telling everyone to get off his lawn. Different things work for different people. There's no need to force your own opinions upon others. Listen to others and accept what they have to say. Form your own opinion based on it. But stop with the petty subtweets, stop with the bashing of the work of others, stop with the outcry of how shitty our tools are.

If you don't like something, don't use it. Simple as that. Facebook doesn't like Xcode, so they don't use it. Jeff Lamarche doesn't like CocoaPods, so he doesn't use it. Ash Furrow doesn't like the current state of Objective-C, ...so I guess he's stuck with it (I kid, there's alternatives out there that he's trying like Eero, RubyMotion, Xamarin etc., too). My point is, everyone is different.

Throwing some positivism into the twitter-sphere. I liked @CocoaPods a lot, but it didn’t do what I wanted. So I fixed it & helped. OSS wins

— @orta@webtoo.ls --leave-this-site (@orta) February 12, 2014

I've been watching a lot of the Olympics this week and an entertaining bit for me has been Johnny Weir. Johnny Weir's outfits everyday have been off the wall, flamboyant and attention-grabbing. Watching him as he attempts to make a statement in Russia, voicing his opinion, his beliefs, in a way that doesn't harm others, has been awesome to follow.

We could take a note from Johnny Weir, and voice our opinions in a way that doesn't attack others. Start making cool things with the tools you like. Start making cool tools that help others make cool things in the way that you work. Speak with your apps and code instead of 140 characters.

He said people who were right a lot of the time were people who often changed their minds.

-- Jason Fried on Jeff Bezos

Tonight, Bill Nye and Ken Ham put on a bit of a show in Kentucky and on YouTube. Those who know me may know that I'm in no way religious, but I don't shun those who are. I do, however, believe religion is a necessary piece to a functioning society, but that's a piece for a whole 'nother blog post.

The part that struck me most about the debate, however, was listening to Ken Ham discuss the difference between "observational science" and "historical science". Recalling my grade school days (fuck, I'm old now that I've said that), I can only ever really remember being taught that some smart guy named Darwin did some studies on finches and this other guy named Mendel did some study on peas and in the end, it's survival of the fittest... or something like that.

But this isn't about me debating who was right and who was wrong. This isn't about proving Nye's or Ham's opinions on evolution.

What really struck me was that Ham chose to accept a belief that may not have been the popular opinion, that may not have been what was taught to him in school, and chose rather to question a specific piece of science (radiometric dating) and question science's reliance on this method. From here, he draws his own personal opinions on our creations based on his beliefs in Genesis (what he sees as historical science) and what he can readily prove in a lab or on paper (observational science).

While I may not stand for everything Ham stands for, I am all for learning by questioning what already exists. I am all for digging deeper into what we think we may know, with the sole purpose of learning more. And importantly, I am all for listening to what others say and drawing my own personal opinion from that.

Last year, I read a blurb from Jeff Bezos on a Signal vs. Noise post that really resonated with me.

He said people who were right a lot of the time were people who often changed their minds.

-- Jason Fried

People who seek to learn more, who seek to shape their own personal opinion, are those who succeed.

It's really tough to find malleable opinions in the tech and start-up industry.

People are full of opinions and hold them to a high grade when it comes to discussing programming languages or frameworks or hell, even programming paradigms. In the last few months, I've spent my spare time learning ReactiveCocoa, not because I think it's the best and only way to craft Objective-C bits and pieces, but because I wanted to learn.

I wanted to learn why Justin Spahr-Summers, a GitHubber I looked up to, spent a considerable amount of his time doing this. I wanted to learn what existed out there besides the same old OOP that my college professors raved about to my young, supple brain. I wanted to see if it would change my mind and the way I think. And it did.

Which brings me back to the whole reason that started this post. How do we enable ourselves to learn more? How can we help enable others to learn in these same ways? How can we help create productive conversations between ourselves, rather than the relentless shitstorm that follows every opinion posted on Hacker News? How can we promote drawing new opinions from a combination of observable and historical science?

Because I will damn well follow those who will change their opinion based on their own knowledge over the immovable stump any day.