pull down to refresh
658 sats \ 5 replies \ @elvismercury 13 Dec 2023 \ parent \ on: Start your career in bitcoin free open-source software with Chaincode Labs bitcoin
One of the things I think about a lot is: what is the ideal "bundle" to put together to help someone contribute to something. (This is a bigger issue in my life than SN / btc, but it's highly applicable here, obviously.) A common failure is that people think that if they make the code available, voila, what more is there to do?
In reality, there's a universe more things that can help scaffold someone s.t. they can contribute. Code is table stakes. Documentation, even good documentation, is the bare credible minimum on top of that. Then you can imagine a whole surrounding ecosystem where you have sample projects with varying degrees of completion (e.g., imagine "add function x to SN, here's three skeleton functions that you need to fill in"), videos, live-coding sessions, Discord servers, real-life communities, etc.
There's so much room to innovate in that space. To me, this is the lowest-hanging fruit in all of btc, and a place where you could bring so much creativity to bear. I love what we're starting to see, but so much more is possible.
Thanks @elvismercury. The idea of "bundles" is a useful insight.
To riff on that, I think the "bundle" can also be quite personal -- different learning styles, experience levels, and time availability. I agree that there remains a lot of room for improvement, but simulating these activities can only go so far. To do the work, future contributors must take the step of doing the work itself. That sounds like a tautology, but it remains the biggest obstacle that I've observed separating learners from contributors. The former is passive and safe, the latter is active and scary. This program is designed to break down the barrier, but ultimately the participant is going to need to take their own step off the ledge.
The tension between simulating the work in order to help build confidence (i.e. toy projects and tutorials) versus doing the work itself at a remedial level (review clubs and good first issues) leaks its way into the medium itself:
We've made videos, podcasts, onboarding guides and workshops. We have cute/approachable ways to ask technical questions like ChatBTC and a coding game (WIP). Some of these are passive and others more active, but none of these are doing the work itself.
There exist networks of technical meetups and learning communities (i.e. Chaincode seminars, Qala, Library of Satoshi, Bitshala.
Each of these learning communities have their own flavor, but many participants hide in the comfortable position of being passive students in lectures. The residency has been the most effective bitcoin onboarding program I've ever been involved with because we cut the field down to 3% of applicants and required them to quit their jobs, thereby, burning the bridge behind them. There was no going back and so they could only go forward. The residency model is effective, but is not the accessible and scalable onboarding that we need.
Action remains an elusive outcome for many of those learning from the current bundle. My hope is that this program can be the catalyst to bring scores of people to where they want to go.
reply
Action remains an elusive outcome for many of those learning from the current bundle. My hope is that this program can be the catalyst to bring scores of people to where they want to go.
This is a topic close to my heart, and I think you have it exactly right -- situated action, manifesting as a person building something that they actually want to build, is the One True Way of gaining expertise. If you can get to real, self-directed action, everything can ignite from there. And there's only so much you can do to bring someone to the door of that, for sure.
In my experience, what you can do, oftentimes, is remove auxilliary frictions. For instance, at my job, if you want to mess around with code, e.g., to explore an idea, there's a set of some ungodly number of things you must first configure before you can write a single line of code addressing the thing you actually care about. Virtual machines, pre-commit checks, access control, linting, all of this bullshit that, while important for production code in our security environment, is like driving a bicycle into a swamp for someone outside a product team with an intuition they want to test.
Switching domains, the usual state is often like teaching someone to cook by sourcing ingredients from ethnic grocery stores scattered across the city, then preparing recipe components across two days ("simmer for two hours and then chill overnight"). Whatever desire to cook someone might have had will not survive the encounter.
These are the things that can often be greatly helped by scaffolding: here's a skeleton project, here's you compile / deploy it, now go work on the thing you actually care about, and if it needs to get more "official" later, we can worry about it then. Minimizing the delay between curiosity and fucking-around-and-finding-out.
These are general thoughts, not wrt what you guys are doing, which sounds incredibly well-considered. I'm jealous of the participants whose early encounters in the space are so thoughtfully curated :)
reply
In my experience, what you can do, oftentimes, is remove auxilliary frictions.
Absolutely. This is a particular area where bitcoin gets its lunch eaten by ethereum, et al. My favorite tool, polar, is beautifully done, but its not Jamal's full-time job or anything. We've explored streamlining dev environment setups, but it lacks polish.
Warnet and SimLN were two other attempts at adding to tools to be proud of list, but we aren't there yet.
Lots of work to do.
reply
I've wondered about this before -- is there a structural reason why btc is destined to get its lunch eaten in this manner? Like, does the vibrant eth ecosystem stem from the fact that it's fertile soil for shitcoinery, and this is a beneficial side-effect that btc couldn't realistically equal?
Or is it a historical accident, and the right support could turn it around, and btc could exist at the same standard? Ecosystem support and maintenance seems to be the unloved stepchild of open source in general, and btc in particular. I posted about the consequences of this a bit here.
reply
@elvismercury Here is another project relevant to this discussion.
reply