Skip to content

Instantly share code, notes, and snippets.

@LarryRuane

LarryRuane/bgrant2022.md

Last active August 27, 2022 15:30
Show Gist options
  • Save LarryRuane/d69834e4b2a796ab96018151145c3c46 to your computer and use it in GitHub Desktop.
Save LarryRuane/d69834e4b2a796ab96018151145c3c46 to your computer and use it in GitHub Desktop.
Download ZIP
brink full time grant application
Raw
bgrant2022.md

Dear Brink Board,

Thanks to 20% support from Brink, I've been very fortunate to work part-time on Bitcoin Core engineering, mostly review, for almost a year. These are some of the accomplishments during this time:

I've become more integrated with the development community, which has been a very positive experience for me. So much so that I'd like to request support to move to full-time Bitcoin Core development. I've been software developer for many years, and I've never encountered a group as talented as this; they're amazing. I'd like to be more involved with this group!

The limited review that I've been able to do has taught me how much there is to being a great reviewer, and how much room there is for my own improvement! Reading reviews by John Newbery and Jon Atack, among others, has made it crystal clear to me that there are real skills to be mastered, much like learning programming itself. Good programmers aren't automatically good reviewers! I'm determined and dedicated to learning how to be a great reviewer. This, along with contributing to the greatest software project by far in the world, Bitcoin Core, would be my mission in life for the foreseeable future.

As just one example of what great reviewers can do, I've seen them make suggestions about how to reorganize a PR's commits to be more logical and consistent. That is, not even suggesting that the code itself should be changed, but the ordering and content of each commit. When you understand how important project history is and how critical it is that future developers be able to understand this history, this makes all the sense in the world. It's a great thing, for instance, when a developer can cherry-pick or omit exactly one commit to perform a test or backport onto a release branch, rather than having to perform surgery within a commit or take subsets of multiple commits. This attention to detail is very much to be admired and emulated.

If I could work full-time on Bitcoin Core, my plan would be the following:

  • Get to know the most active developers to discover which PRs would be the most productive to review. I would use the high-priority for review list as one resource.
  • Be very active in Bitcoin Review Club (I've hosted twice, I'd love to do more). Spend many hours reviewing that week's PR, testing it, helping the author if needed.
  • As part of reviewing a PR, contribute additional test code where appropriate, rather than just saying, "there should be a test for this". PR authors can be somewhat territorial when it comes to the production code of their PR, but they're more open to others providing additional test coverage.
  • When possible, if the PR author is amenable, pair with the author on a screensharing video call and have him or her explain the PR to me. To the extent I'm just a rubber duck, that can still be useful! And people love talking about their own code. Pairing in this way would build a stronger connection with the members of the community, which has ongoing advantages.
  • I'm partial to using debuggers to review code, and I don't think many, if any, others do this. Being able to step through the code and "look around" at the various state, verifying that it's as expected, can reveal bugs that aren't caught by the test (if it's "accidentally working").
  • Perhaps become a mentor (at least a "starting mentor" since I don't know that much myself) to new, promising devs. Here again, I think pairing is great.
  • Monitor and contribute when appropriate to #bitcoin-core-dev IRC channel.
  • Reviewing PRs sometimes leads to ideas for follow-on or related PRs, and I'd love to do some of those too (and have already), but that wouldn't be my main focus; I wouldn't go out of my way to make this happen.
  • Pair (video call) with Gloria weekly or bi-weekly; we've already started.

To fill in a bit more detail, here are the most common concrete steps I take to review code (depending on the complexity of the change; I don't do all of these for every PR):

  • Read the associated GitHub issue, if there is one.
  • Read the PR description (first comment) but not the entire PR discussion
  • Clone (download) the PR branch locally.
  • Build, usually without compiler optimization to allow more effective debugger use.
    • Sometimes I will checkout, build, and test each commit separately.
    • If the PR hasn't been rebased recently, rebase (locally) onto latest master, (better to test there), and sometimes this will turn up hidden merge conflicts.
  • Run any new or modified tests.
  • Use Visual Studio Code (VSCode), which has excellent git integration, to view per-commit diffs.
    • Start by looking at header file changes, then .cpp changes.
    • Try to understand the history of the affected areas of code.
    • Look for opportunities to adhere more closely to modern C++ best practices.
    • Make sure there are sufficient, but not too many, code comments, and they are concise and clear.
    • Pay special attention to lock ordering and thread safety, see if additional lock annotations can be added.
    • Understand what the tests are doing, see if they provide good coverage for the code being added or changed.
    • Consider if a release note is needed.
  • Run any code paths that aren't obviously correct with the debugger:
    • VSCode has excellent debugger integration.
    • Use debuggers while running functional tests (run simultaneous debuggers on the Python and the bitcoind), and/or on the unit tests, or just running bitcoind manually (and using the CLI).
    • Set breakpoints and single-step, looking at relevant state.
  • Take local notes of any problems or suggestions.
  • Now go back and read the discussion on the PR. I find it's best to delay this until after examining the code so I'm not unduly influenced by existing review comments.
  • Here is where it might make sense to contact the author directly (as explained previously).
  • Add any comments that haven't already been added by other reviewers. My goal is to make useful comments and suggestions while also being very humble (I may not understand the code as well as I think I do!), and very gentle in making corrections or suggestions, especially with newer developers.
  • Try to bundle comments so as not to spam others with GitHub notifications.
  • After the PR updates, repeat! I love GitHub notifications to keep track of things I need to respond to.

After starting out in a very general way, it may be more productive for me to specialize in reviewing certain larger (multi-PR) important projects, although I would always want to spend 40% of my time on "general" (smaller) PRs. After discussions with a few people, I propose spending 30% of my time reviewing each of these two projects:

After spending a few months just reviewing and learning, I'm expecting that I'll be able to carve out little sub-areas of these to contribute code to.

As for grant amount, it would be nice to stay roughly even with my current compensation. So multiplying my current grant by 5 (to reflect going from 20% to 100% of my time) is in the right range.

I would still be taking a bit of a pay cut, because ECC (my current employer) has instituted what they call a "retention bonus" which is like a stock option (ECC has no stock, as it's also a nonprofit). It's an employee-specific amount of Zcash, in my case 918.65 ZEC, that vests yearly over a 4-year period. The first year was up January 20, 2022, so the value based on the price on that day, $125, which is still close to the current price (I haven't converted it to Bitcoin yet), is about $28,700. So, if you add that to my base salary, it's about $178,700. Another part of my compensation is in the form of employee benefits, such as medical insurance. I don't know the value of the value of these (pretty standard) benefits.

But I'm also aware that there's typically less compensation for working on a grant basis, and especially to work on the world's greatest project, so I'm not expecting my total compensation to stay just the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment