TwilioQuest, a new way to learn Twilio | Hacker News Reader

TwilioQuest, a new way to learn Twilio

twilio.com

159 pointsgregorymichael47 comments

I attended Twilio’s Signal conference and they had Twilio Quest running at their hackathon.

As the head of my little startup I was supposed to schmooze and attend all the biz type talks - what did I do instead for the entire morning? I spent it on the Twilio Quest hackathon coding away.

Haven’t had that much fun coding since college. Could not believe Twilio put so much effort into what I assumed would be a small side show at their conference.

This kind of commitment is incredibly impressive and really endears developers and technical users who see this side of Twilio. I even think it has applications outside of Twilio as a teaching tool if it could be frameworked up and open sourced.

Incredibly impressed by Quest and so tempted to see if I can improve my score!

Now you made me want to spend time playing it :-)

It seems so strange to have such a polished initiative on a niche project like Twilio. I can understand this for AWS, JavaScript Libraries, or SalesForce, but nobody's job title is exclusively "Twilio Engineer".

Then again, the team was always notably helpful during hackathons, and their documentation is usually on point. Maybe they recognize this as a company strength, and they are harnessing it as a way to compete with the likes of AWS/Google Cloud.

Twilio has an entire team of engineers focused on Developer Education. Two of the leads gave a talk [1] that explains this in more detail at Signal 2016.

[1] https://www.twilio.com/signal/2016/video/6Gjpnzch0sggKeey0yi...

Honestly, even as a marketing effort this is awesome. It just speaks well of a company that it does something like this, without knowing much about them before this, now I have impressions of cool and even trustworthy for some reason after seeing this.

Much like when you go into a website and know (unlike your average mother/grandfather) where to put your credit card or not because of the "feel", this gives me the feel of an awesome company.

Stuff like this and their hackathon reps are why I care about Twilio in the first place. I have suggested its use professionally before and I would have never remembered the service existed if it wasn't for a great hackathon experience using it where the rep was very helpful.

Twilio has nearly a $3 billion market cap right now, and their signup/churn/usage rates give them a good idea on the growth potential for this market.

Nobody I know is a Twilio engineer, but nearly every backend developer I've worked with has, or wants to use, Twilio. There's something old school phreaking about using a computer to control phone systems.

They seem to believe that the market is very broad, occasionally deep (Uber was ~10% of their usage), and super cool. They haven't gotten so big to discard their focus yet playful roots (their hackathon outreach is a great example; that's where I first learned the API).

SMS is really hard. While my name isn’t Twilio Engineer, it might as well be SMS engineer.

Anyone with the misfortune to work in enterprise software would probably disagree with describing Twilio as a "niche" project. Increasingly they _are_ inbound channels for a huge range of customer facing enterprise applications.

Speaking of hackathons, I've got one this weekend and was planning to use twilio in the hack. In the past did you just reach out to them for help? How so?

They are super responsive and helpful. Where are you located? Sam Agnew is always there to help you.

Hackathon is in StL (midwest USA), it looks like they are only available M-F though.

I believe that it's because of efforts like this that you don't see the need for "Twilio Engineer." When you make integration easy for the everyday developer, they're able to spend more time focusing on the other parts of their project.

I'm basically a twilio engineer now. I do a lot of telephony, but no one wants to run and scale their own stack, so everyone ends up building against REST apis. Twilio has some of the best features around reliably placing calls, sending texts, and the most enjoyable developer experience of any api I've ever used, including outside of telephony. I've built a 100% serverless contact center, among other things. Twilio Sync RT infra is also fantastic. Their WebRTC service was total shit through 2014 but is better now.

Would you use their WebRTC offering, or is there a better alternative?

Sure, I'd use it, but under the following conditions:

- wired ethernet

- lots of guard code that reconnects failed calls

- customer is aware they will not get 5 9's or even 3 9's.

Typically using WebRTC means a significant cost savings, so it may or may not be worthwhile to build out the additional stuff needed to make it work.

I've heard it's not the best solution in Europe. What can you tell about it ?

I think we will have Twilio Engineers. They might be called vocal interface engineers. and I'm pretty sure that there will be people that would exclusively use their SMS / MMS backends so they will be voice / text UX engineers.

I remember this from Twilio-con in 2014 or so. TwilioQuest was easily the best session I've ever had at a conference. It looks like they took that and went even further. What a fun project to work on! I wish every conference session was as well polished. To me this one is the gold standard, or maybe on HN the bitcoin standard, of conference sessions. Approachable, engaging, educational, and entertaining.

I'm amazed at how big Twilio has become. I just thought of them as operating a useful gateway between the Internet and the SS7 network. I've used it for inbound SMS, for which it works fine. The API is simple enough. I used to do SMS via Google Voice and a Python program, which was awful. (It did take three years of nagging to get inbound multipart SMS support on Twilio, but they finally implemented that.)

Now they're moving into customer relationship management. They may end up competing with Salesforce.

When your service is a commodity, consumers choose by price and ease of integration. This is a great way to make the choice easy

Does anyone know any other apps that have done similar things? Gamification really pays off for me - but I have no interest in Twilio hehe. I'm familiar with habitica, not what I'm looking for

https://trailhead.salesforce.com/en

Ruby Warrior?

https://www.bloc.io/ruby-warrior#/

Maxed out auto-play audio on homepage warning

Not quite the same focus on core product but Stripe CTF https://stripe.com/blog/capture-the-flag

This reminds me of Braintree and their hidden games in the source code. They used to have it some time ago: there were some links and instructions in the source code that you could use to access some URLs with classic videogames, Braintree themed.

This "little" details make developers take the company more seriously, somehow: "If they make the effort to develop this just to make developers smile, they must be extra committed to their code and their API quality". Not sure if true, but it's an effective strategy. Kudos to them.

One of our startups is in a tough, low tech. market [in the USA]. On a tight budget we had to deliver robust SMS based features fast to meet customer expectations. It would have sucked the ocean to build Twilio's stack from scratch then use it hoping we got it right the first time. As someone else said: "the most enjoyable developer experience of any api I've ever used" is why we signed up and haven't looked back.

This was clearly a labor of love. You've taken gamification to a whole-nuva-level.

Obviously we don't know the full context, maybe this was a super quick side project that the developer(s) had a blast doing. But I would've preferred they spent time improving documentation, writing first-class client libraries for more languages (cough Golang), or you know the API itself - which last time I checked had the string "2010-04-01" hardcoded into it.

Naysaying aside i'll give it a shot if I'm ever using Twilio again. Haven't seen API providers really push the barrier in learning materials - could work.

I'm curious about the comment on API versioning. If it instead had the string "/v1/" embedded in the URL, would this be preferable to you? Which APIs do you feel are in need of updating?

Disclaimer: former Twilio PM.

So pointing out the API versioning scheme was disingenuous. It's as good as any other scheme and is probably necessary for backwards compatibility... it just seems old. I'll divide my short feedback into three categories:

API Features that I feel should be there but aren't:

- CRUD operations for Copilot

- Bulk operations for SMS/MMS - seriously one request per?

- CRUD operations and better access for logging and billing in general. The UI does not suffice.

User Interface:

- You did a huge redesign ~2 years ago that was frankly underwhelming. It added some SPA like functionality splattered through out the site, and many of the operations, like adding numbers to a Twilio Copilot service, became slow and buggy.

- Good artists copy and great artists steal. SaaS products at GCP, AWS, Stripe, aren't necessarily perfect but can all be drawn from to create a better product. I honestly feel like most of the innovation at Twilio clocked out ~4 years ago and now its just maintenance work and annual reboots. Though this project shows innovation its far away from the core concerns of customers. We know how to use the platform already...

Generic:

- Better documentation

- More transparency for how carriers handle SMS once Twilio passes it off

- More transparent pricing. I.e. if I send a 1600 character text I'm getting billed ~10 times or whatever - not great.

EDIT: Finally because Twilio is a billion dollar business I hold it to a much higher standard then I did ~5 years ago. I don't mean to discourage hardworking employees who mean well, just as a former employee of a not insignificant customer I have some residual entitlement and frustrations.

>- You did a huge redesign ~2 years ago that was frankly underwhelming. It added some SPA like functionality splattered through out the site, and many of the operations, like adding numbers to a Twilio Copilot service, became slow and buggy.

Not only to the developer portal/backend, but to the documentation as well.

It went from something that was really straightforward and easy to use, to something that feels like you have to fight it to find what you want. I'm really curious what happened, or why this design decision was made.

It's honestly bad enough that imho there is space for somebody with a better UI/documentation to move in and compete on that.

Twilio now has a Passthrough API https://www.twilio.com/blog/2017/08/bulk-sms-with-one-api-re... to address bulk SMS.

Personally I'd love to see an improvement to the backend UI. I spent a good 5 minutes searching around for "twiml apps" yesterday, finally resorting to just googling it.

This seems like core functionality of the backend. Why is it not placed somewhere more obvious?

I did a Twilio side-hack this weekend with a full multi-user phone tree and password layer.

Spent more time trying to navigate the developer portal than programming but wrapped up in about three hours.

It’s a testament to both how capable the API is and how terrible the UX is.

The graphics look nice but the layout is inscrutable.

Agreed - documentation lacks in frustrating ways at times. For example the docs [1] for migrating to their new python client are still lacking despite cornering developers into upgrading (don't offer support unless you've upgraded).

[1]:https://www.twilio.com/docs/libraries/python/migration-guide

Hey out of curiousity what did you feel was tough in golang? I recently built an application that used twilio (heavily) in golang, and didn't seem to have much trouble.

The problem isn't with the REST interface Twilio offers necessarily but that ~3 years ago when I first got into Go + Twilio the third party libraries created had pretty serious flaws. For example they'd use the default http.Client which doesn't set proper timeouts and can lead to various issues. At that time I was unaware with such issues and struggled. A first-class library would alleviate these issues for people who are in a similar spot.

Please take another look, my library configures the default timeout to be 31 seconds (one second wider than the API timeout), and lets you pass in a context.Context for each API call. https://github.com/kevinburke/twilio-go

You're making the mistake laypeople often make which is that the resources disposed to do X were fungible enough to do Y as well. What if this were interns or contractors? Engineers in test? An engineer on sabbatical?

Perhaps a Hackathon project?

(Former Twilio API engineer here - you might like my Go library, which is reasonably feature complete and I have been using in production for some time, https://github.com/kevinburke/twilio-go. In production here: https://github.com/kevinburke/logrole)

I haven't written any golang, but why would you want a native client, when using http directly is nicely documented? I've worked with providers that worked in part of the same space, but only provided native clients, not documentation for directly using http; that was a big pain because I was porting to a language they didn't support and I had to reverse engineer the client for the language we used to use.

For me, I'm happy that they haven't changed their api in forever, I'm still using them in the same way as five years ago, I don't need to change my code.

Chiming in late to say that I love TwilioQuest and I plan to max out my EXP because I just learned more about Twilio since this went live than I understood in the year I have been toying with it.

This is pretty funny :) Not the easiest way to learn how to use their product, but fun :)

Please work on your Programmable Fax API. It's a mess right now with 40% of inbound faxes having a status of "failed" with no additional information. Yes, I get that it's a beta (for many months now) but not showing a descriptive error message? C'mon!

Reply on news.ycombinator.com