Last year I published How content creates content blog post. It’s one of my favorite blog posts. It shows how one piece of content can produce more content. Since everyone shifted to running online events/meetups I wanted to update this blog post and also offer new content ideas for the virtual world. I know it’s not always easy to come with content ideas. This blog post should help you develop more content. I also recommend you read How to scale Developer Relations with online meetups.
We have been running (almost) daily online meetups on the IBM Developer Crowdcast channel. You have been working on an article or tutorial how to solve a problem with a technology from you company. You want to share it with your community, maybe other developers will find this solution useful. You can start with publishing a step-by-step tutorial. That’s one piece of content.
Next you can host an online meetup where you will show the steps building a solution. Now you have:
It’s a good idea to record the online meetup. We use Crowdcast where each event is automatically recorded. You can upload the recording to YouTube and now you have:
Technical note: Twilio expects a specific response from a Webhook. This response includes a message to send back. This no-code examples works differently. While Parabola does send a response from a Webhook, the response is just a default success message (this causes an error on Twilio side which you can see in the debug console). The no-code example sends a new message as a reply to the received message.
(drum roll) It’s the native Apple Notes app. I know, perhaps it sounds boring but let me explain.
Like many people out there I have tried many different to do apps. This is just a short list. I tried Any.do, TickTock, Google Keep, Trello, WorkFlowy, Notion, Taskade, Todoist and probably a dozen others.
I always wanted a simple to do app where I can keep a list of tasks I need complete. Once a task is done I wanted to mark it done (or cross it out). I didn’t need any complicated project management features or collaboration features. On a number of occasions I wanted to just switch to using pen and paper. I imagined I’d write my list of tasks and cross them out when completed. One drawback with a pen and paper is that you need to carry it with you.
As I continued to try more apps and read what other folks are using (there are thousands articles on various to do apps and approaches out there). I decided to give a very simple app a try. I thought this approach would bring me the closest to a pen and paper but I’d still be using an app.
That app is the native Apple Notes app on iOS, ipadOS and macOS.
This video shows how to build a contact form and get notified via email when a form is submitted using no-code tools. The form is built with Typeform. The flow to send the email is built with Parabola.
Check it out and let me know what you think. This is part of my journey to take an application built with code and build it with no-code tools. If you know any solutions built with code that I should try to build with no-code – let me know! You can also check out other no-code videos I have published.
Dave Nugent and I sat down together and Dave asked me the following questions about Developer Relations:
How do you prove the value of DevRel inside a large company?
How valuable is consistent messaging for DevRel?
How does leading DevRel differ between a startup and enterprise?
How does your team interface inside IBM?
How has your mission changed since you started at IBM?
Who in DevRel would you like to call out?
Q: How do you prove the value of DevRel inside a large company?
Probably one of the best ways and my favorite is to explain that developers today have a lot of influence. In other words, developers make decisions what software to use and buy. Many years ago software was purchased by executives and pushed down to developers (top-down approach). In most companies today it’s the complete opposite. Developers try software and if they like it they go to their managers/executives (who has the budget) and ask them to buy the software. Instead of top-down it’s now bottom-up approach. In some companies developers not only influence what software to buy but they also have the buying power.