This brief article serves as a personal exercise for me, the author, in building a second brain. As a reader, I hope you find the insights shared here valuable, particularly if you have an interest in knowledge management. If you’re not familiar with the concept of building a second brain, the main idea surrounds developing a learning process that culminates in doing and or applying what you’ve just learned. I’m certain that I’ve veered far from the prescribed method of building a second brain, at least the one I’m referring to, popularized by Tiago Forte, and outlined here. But, I’m also conscious that even attempting to learn in this second brain inspired manner has shifted my approach towards information synthesis, note-taking, and by consequence, engineering.

Part of the work we’re doing at Public Assembly involves researching and experimenting with ways of distributing context and information across a distributed team in an asynchronous environment. My hope is that, independently exploring ways to do that effectively can in turn lead to insights and the formation of process that can be used to benefit those contributing towards Public Assembly.

My previous approach towards information gathering involved an array of folders in my Notes app. I would organize resources categorically via broad topics like Design or Photography, those parent folders contained subfolders like Interaction Design or Darkroom Processes. The problem with this organizational approach is that the individual resources, say notes taken on an article, or screengrabs from a YouTube video, lacked the context of a larger effort towards learning in order to further a specific project or accomplish a task. In other words, the notes that I was taking, although organized categorically by topic, were disjointed because I wasn’t able to attribute them towards something applicable in memory.

One of my favorite pieces of guidance shared from the article above expresses that, every time you come across a particular element in your knowledge base, your second brain, do something small to improve it for the benefit of your future self. This could be something incredibly minute like rewording the entry’s title or opening sentence. Essentially anything that will make your future self have a better time processing the information that you’ve left for it.

The approach I took during the development of Flexible involved creating a project based folder and including every resource created and collected in the context of the project. This process, combined with the practice described directly above, allowed me to design a project based knowledge hub, where individual resources are clearly tied to their application. Here is a piece of information, here is how it was used in this project. My hypothesis is that this subtle change in the way that I collect information will allow me to create a far more effective structure for my personal knowledge base.

In the process of writing this article, I’ve been cycling through all 62 notes I made during this project, trimming the fat, expanding loose ideas, and creating the links from resource to application. Here is a snippet of the first pass at a resource regarding deterministic deploys.

Deterministically Deploying a Smart Contract on Multiple Chains

This process was used to deploy the PlatformThemeRegistry contract on both Mainnet and Goerli at the same address. The script for accomplishing this can be found here, and the entirety of the process is outlined below.

Resources

• Foobar’s article on vanity addresses

• OZ’s article on deploying with CREATE2

• 0age’s create2crunch program

• Public Assembly’s theme registry repo

Background

It’s important to understand the two opcodes that exist for contract deployment, CREATE and CREATE2.

CREATE is the default method which determines a contract’s address by hashing the contract creator’s address with the contract creator’s nonce.

new_address = hash(sender, nonce)

This nonce is how many transactions a particular address has sent, a fresh wallet starts at 0.

CREATE2 determines a contract’s address by hashing 0xFF, the contract creator’s address, a salt, and the to-be-deployed contract’s bytecode.

new_address = hash(0xFF, sender, salt, bytecode)

0xFF is a constant that prevents collisions and a salt is an arbitrary value provided by the sender.

Deploy Instructions

1. Retrieve the to-be-deployed contract’s initialization code hash

2. Use 0age’s create2crunch and run the script by providing the zero address and the byte value from above as arguments

3. Visit Etherscan and verify that the salt and initCodeHash returns the desired address by calling the findCreate2AddressViaHash function

4. Update the salt in your deploy script

5. Run your deploy script, passing in the appropriate RPC URL for each chain you wish to deploy to

Not every note is deserving of its own mini article, but for those with substantial information, it is helpful to take the time to unpack the process or solution. My goal is to continue to establish a more structured, contextual, and effective knowledge base, with the hopes of becoming more efficient and developing as well as better collaboration practices. Flexible is the first project I’ve employed this strategy with, and many of the resources I’ve compiled around it are still fresh in my head. The real test will come when I embark on my next project and attempt to use this knowledge base towards it.

If you’re process oriented and interested in this type of thinking feel free to reach out to me on Twitter to continue the conversation! Also, if you’re interested in contributing to Public Assembly, follow us on Twitter and join our Discourse forum.