Inside the IBM Developer Advocate: I’m a developer

Being an IBM Developer Advocate means I’m a developer. I write code, I look at code every day, and I commit code to GitHub. In a sense, a Developer Advocate is just another Developer. When we get an idea for an integration, for example with IBM Watson, we’re just like any other developer and we sit down and figure out how to build it. We might know a little more about the services, or it might be our first time reading the documentation just like any other developer.

To build the idea, a developer might include open source libraries from various communities on GitHub. If we use Watson, the Watson Developer Cloud is usually the place to copy and paste code snippets to integrate Watson quickly. Nothing to be ashamed of by copying code…it gets you to the meat of your project…the custom solution you’re building.

Now that we have an application running locally, a developer determines the best environment. Should it be in a Docker container, Cloud Foundry application, or be an OpenWhisk serverless action? Perhaps that might have been a choice made earlier on, but our excitement gets the better of us at times.

Fast forward to the project working in some form or other. Developer Advocates share their code on GitHub so that others may see how the project was built. Sharing code is important, as other developers can SEE how something is built, not just use what was developed. Have you ever been bored and swiped through snaps or tweets? Check out a repo next time and you might find something new you never discovered. That’s how I learned about the reduce method for JavaScript arrays.

And finally, Developer Advocates write about the thought process and why certain design and development decisions were made. Share as many details on the process so someone else could follow in the same footsteps and learn as you did. You can find this on DeveloperWorks recipes, code journeys, and on personal blogs of Developer Advocates.

Oh, but that’s not the end of it. We use these examples in our engagements with other developers. From being able to talk about the process and the concrete use case we built, to showing a developer an example to inspire the “what if” questions, to encouraging the developer to take our sample code and build upon the “how would I.” What is most important is the seed the developer with curiosity, courage, and creativity to go forth and build.

And one last thing to remember: a Developer Advocate is human. Come chat with us, day or night (we stay up all night at hackathons, ready to talk) and tell us what you’re building.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.