How can Polkadot be even better for developers?

LUCAS VOGELSANG (Co-Founder of Centrifuge, a Polkadot parachain)

Tooling & Abstractions

Polkadot is fundamentally a better and more scalable technology, but it has trade-offs. Complexity is one of them. I usually make the comparison with asynchronous JavaScript requests, a very new technology back in the early 2000s when I got into coding. You started building websites and got some information from here, some information from there... you had to consolidate all this stuff and in the beginning the tooling was horrible. We also have to build the right abstractions - it just takes a bit of time to figure out what they are. We're already starting to fix this.

The Pace of Polkadot

That Polkadot does move fast is a huge benefit; it was the reason why we chose Polkadot. We looked at Cosmos and the upgradability process was too slow with the hard forks. We looked at Ethereum and I thought the Ethereum 2.0 roadmap at the time was unrealistic, would take way too long and wouldn't deliver scale in a reasonable amount of time. Ethereum was very immature early-stage technology. Polkadot was maybe a bit too much on the other extreme. So I think we have to find the middle. It's good that we're slowing down a bit on the pace of deploying features.

Thorough Testing

The other part is that when features are being deployed it's really important there's end-to-end testing done beforehand to make sure it works. At Centrifuge, only about a third of our engineering team is actually doing runtime stuff. Blockchain is a very small but crucial part in the overall architecture, so when features are released we need to make sure the 100% is done, not the 30% of the runtime. We're already getting better at this.

Better Communication

We've also got better at communicating what the use cases are and then concisely communicating that to the developers so they don't need to spend time following pull requests on on the Polkadot repository. Often you can't follow what 70 engineers at Parity are doing and then figure out which thing is actually important to you and which one isn't. The maturity of the codebase is improving. I really like Parity's engineering VP Pierre Aubert's monthly updates on the Polkadot forum. I think that they've been super helpful. Now you know as a tech lead or as an engineer you can go to a single source and not have to go through GitHub pull requests.

SANTIAGO BALAGUER (Parity's Technical Lead, Product Engineering)

Simple Onboarding, Better Documentation

Polkadot offers a very different environment to build in compared to other ecosystems, particularly for new people, We need to make it a lot simpler for them to understand quickly how they get started and how they get moving from there. Polkadot moves quite fast and keeping updated with the new tech updates is not always straightforward. We need to do a better job into having documentation updated all the time.

Agile Coretime: A Big Opportunity

Agile Coretime will help us a lot. It looks complicated from the outside but if we manage to get the right tooling in in place to make it as simple as it can be it will be a great opening for people to join Polkadot. It allows more people to join, try things, iterate and see how best to move forward. They can even expand into multiple cores if they want to which is very interesting. I look forward to initiatives that would allow chains to utilize cores very, very quickly compared to what we have now.

ALBERTO VIERA (Founder of PaperMoon, Core Contributor to Moonbeam)

EVM Benefits, XCM Challenges

One of the things Moonbeam has done well is on the execution side of things. We've benefited a lot from being an EVM ecosystem for Polkadot and and we're benefiting from the tooling and documentation that comes with that, and that's why Moonbeam has been successful within Polkadot. The XCM side has been challenging because it's been difficult to build simple solutions that provide users with one-click experiences. I've heard from other core developers this new perspective on making Polkadot a lot more stable.

Listening to Feedback, a Competitive Landscape

There's more openness to hear feedback on things - for example on the XCM side - so that's something that's changing for the good. About seven years ago there were a few blockchains you could count with your hands and now it's impossible - there's one blockchain popping up every week, so it's a very competitive landscape and you've got to move to stay at the edge of technology which I think Polkadot has always done well.

JOE PETROWSKI (Polkadot Runtime Lead, Web3 Foundation

'Bad User Experience'

We do see a lot of what people call "bad user experiences". It's possible to provide a very good user experience - people just require and rely on a lot of tooling, especially around XCM. We can improve the experience of both builders and end users but Polkadot is really complex on the protocol layer, and we push a lot of that complexity into UX developers and when they don't know how to handle it they push that complexity to their users. We need to give better tools to the UX developers to stop the issues trickling down to users.

Defining the problem first

Communication has got better in the last six months; we're collaborating better. What we could do even better is communicating problems better. I can think of a concrete example: six months ago, someone said they wanted to put a new pallet on Asset Hub and asked how to do that. I asked if they really wanted to put a pallet on Asset Hub. It turned out they wanted to put their parachain token there so I explained they could already do that using the foreign assets pallet. So when we get down to discussing what's the real problem it leads to much better collaboration.