Getting high-quality engineers interested in the blockchain space

I want to expand on the following Twitter conversation and our forum seems like a great place for writing > 140 characters.

How Bitcoin got a non-traditional start:
I feel that the Bitcoin/blockchain industry had a rather strange beginning where the technology didn’t come from the tech industry or research labs but was started by anonymous hackers. This beginning is very different from typical life cycles where you see research grants from the NSF, DARPA, etc., research communities coming together under IEEE, ACM, or USENIX, leading to research labs working on early prototypes before we start seeing startups or products from large companies. Think about DARPA providing the initial funding for the Internet, the original TCP/IP paper getting published at IEEE Transactions on Communications (1974) or DARPA’s 2004 self-driving car challenge and advancements in machine learning / AI regularly getting peer-reviewed and published at well-established conferences.

Bitcoin/blockchains came out of nowhere i.e., from a non-traditional channel. Academia is beginning to adapt to it and (after years!) has started accepting blockchains as a valid/interesting technical area. For example, our Blockstack paper got published at USENIX’16, and Gun Sirer’s Bitcoin-NG paper got published at NSDI’16 (the top systems/networking conferences).

Concerns engineers bring up about working on Bitcoin/blockchains:
When I talk to traditional distributed systems engineers, people who’d go and build the next-gen systems at Google, for example, they’re reluctant to give this technology serious thought; some don’t want to touch Bitcoin with a 10-foot pole. Some of the concerns people have brought up are:

(a) there is a lot of drug money involved in that space
(b) it’s built on technically shaky grounds
© the community this space attracts is just weird and strange, and “normal” engineers don’t want to interact and associate with this community
(d) there is a lot of political drama, public fights, and personal attacks

Most of all, engineers have basic questions and concerns about the technology, and you need to walk them through all the concerns before they start to feel that there might be something interesting here. Concerns I’ve seen include:

(a) Can the governments just shut it down?
(b) Are we wasting too much electric power on a “stupid” use case?
© Can a public/global network ever scale?
(d) How are all the federated/private blockchain use cases different from systems we’ve been using for decades?

Steps we can take to get more engineers interested in the space:
I do feel that once engineers get answers to their questions and poke around the technology, they genuinely get interested. So to get more engineers involved in the space, we should:

  • Get blockchain research included in traditional systems/networking and applied-crypto conferences and engage these communities.
  • Engage the experts in distributed systems and applied-crypto space. Get social proof.
  • Place the “new work” in the right context, i.e., how is this different from all the work done by distributed systems people for decades.
  • Tone down the hype. Focus on the actual technology and hard problems. Lower expectations from app developers and the “this is going to change the world!” crowd.
  • Produce better educational content. Engineers should be able to find answers to most their concerns easily.
  • Get Bitcoin/blockchain courses included in major universities. Start training the engineers who’re just coming on the job market.
  • Set up hiring processes at blockchain startups/companies where engineers can get a “crash course” on the technology, given they have the right foundations.
  • Separate the financial risk of Bitcoin crashing to zero from their job. Give them job security.
6 Likes

Thanks for starting this discussion. Interesting points!

The most public ‘hard problem’ right now is scaling. On its face it is a technical problem, but we’ve come to realize it is a social & political problem, and therefore beyond the scope of most engineers. Is there a philosopher-king-engineer out there who can tackle this issue? Maybe, but you need extremely thick skin to dip your toe into this debate. Let’s say you’re working on an app that uses Bitcoin: If you’re creating for ‘on-chain’ then you’re going to need to make a political stance regarding scaling issues. If you’re working on moving money off-chain, get ready for distrust, claims of sabotage, and worse from the community.

Talented engineers looking at Bitcoin or Bitcoin-dependent apps should ask themselves a pretty simple question: Am I motivated enough to bear the drama of an open source currency with a 19 billion market cap filled with people who all think they know what’s best for its future? Or is this just too big of a mess.

These are the same engineers that understand that closed blockchains can be described as a something akin to ‘eventually consistent shared database’ when among their peers, but refer to them with the Ƀ word among employers.

3 Likes

Yep, the block-size debate is a political issue. I think it’s possible to mostly ignore the Layer 1 debates and focus on Layer 2 solutions. Most of the apps are going to be built using Layer 2. It’d be great if the bandwidth of the underlying blockchain improves, but the underlying blockchain not changing is not a bad scenario at all. In fact, stability in the underlying blockchain is highly desirable.

There was an interesting discussion on Twitter about this topic and most people focused on getting more universities involved with teaching courses and improving educational content around the technology. I’d love to see some practical things coming out of this discussion, and I’m happy to contribute.

1 Like

Here’s a round up:

















2 Likes