Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Welcome devs, testers, and managers alike! We've got an exciting announcement here at DZone, we'd like to introduce you all to the Writer's Repo. The Writer's Repo is a place for DZone authors and contributors to check out article ideas, brainstorm, collaborate, and/or reach out to our Editorial Team.
Say bye-bye, writer's block!
The way it works is you select your favorite Zones and review article prompt(s). From there, you can contact our editors with questions or go ahead and start writing.
In today’s global marketplace, you need a web presence to survive, but that’s not all. If you want to set yourself apart, you absolutely need to create engaging content. Content marketing has been around for quite some time, but in a day and age where we grab our phones or tablets every time we need an answer to a question or curiosity, it’s even more useful than ever.
When you create useful, relevant content for your audience, they’ll come to think of you as an expert and thought leader in your field, and they’ll keep coming back to you whenever they need information in your area. This is a great start, but it’s not enough to convert your viewers and readers into customers on its own.
Contribution graphs tell the story of your year.
Especially when you're a daily user, they have a funny way of capturing not only professional milestones, but personal ones too. Vacations, sabbaticals, and family leave are all captured by characteristic little gray squares where no work is done. Equally telling are the times when work overflows into the weekends, or when it forms those satisfyingly deep navy streaks for consecutive days with over 30 commits each.
After more than four years at Google, I'm now a Developer Advocate! "Wait, I thought you already were that?" is the most common reaction. Allow me to tell my story.
Google recruiters had reached out to me over the years, and in August 2014 — if my memory serves me right — they queried about my interest in becoming a Developer Advocate for the Web at Google. I expressed my interest and we started Google's detailed and granular assessment and hiring process. In my first call with HR, though, they informed me that this role was full-time in London. Not having an interest, nor possibility, to move to London, I said that I couldn't relocate but I would be happy to travel there every second week and work there then. I was met with "Unfortunately that's not going to work out; you have to be based in the London office full-time."
In the context of developer relations, a Lunch & Learn event is a lunchtime developer education event. It's very similar to an evening meetup, but hosted during the lunch hour. While a meetup can have different formats (hands-on, lecture, panel, etc.), this particular event has a lecture-style format. Developers come to the event, get to eat a delicious lunch, learn something new, ask questions, and network.
So now the question is — why run an event during the lunch hour? I'm going to share why a Lunch & Learn can add value to your developer relations program. I want to mention this is not to run instead of evening events, but in addition to evening events.
Is programming like math, or is it like writing? I think there are elements of both in it, even though programming is a discipline of its own. Nevertheless, it is interesting to think about what aspects are like math, and what aspects are like writing. Maybe it will even lead to a better understanding of what programming is.
Sometimes, the domain of the program requires math — for example; machine learning, graphics programming, or financial modelling. But I am more interested here in parallels with math that apply regardless of the domain.
It's unavoidable. At some point — if not on a regular basis — as a developer, you will need to produce some type of content in written form to share with your team or others. Since clear and concise technical writing takes practice, it makes sense that you should make a proactive effort to practice your writing. Writing a blog is a perfect (and an easy, low- or no-cost) opportunity to get some practice.
There are plenty more reasons, however, why blogging is beneficial and useful for all developers. In no particular order, here's why you should be blogging:
I personally really love self-publishing, or indie publishing, so I am a little biased. In this article, I will go over what I think are the pros and cons of indie publishing versus going with a "real" publisher.
Here are my favorite parts about indie publishing:
A big part of many developer advocacy programs is content. Content can be in the form of tutorials, blog posts, videos, and hands-on workshops and other forms. Coming up with content ideas is not always easy. In this blog post, I'm going to share some ideas how to simplify content creation.
The IBM Developer SF team hosts weekly events. We host at least one in-person event and one online event (webinar/online meetup). For every in-person workshop, we host an online event. It's usually best to host the online event after the in-person event, as people who couldn't make the in-person event can watch the online version (but the other way is also fine). The in-person event is about two hours and the online event is usually 40 minutes. So yes, the content covered will be different, but the basis will be the same. This is the first example where doing a hands-on workshop easily creates content for an online event. The in-person event doesn't necessarily need to be a meetup/workshop-type event. It can also be a conference talk, a panel, or a Q&A. It can really be anything.
Listening to users, stakeholders, and dev team members is crucial for product people. It helps us build rapport, generate new insights, and make inclusive decisions. Unfortunately, we can get so busy updating and convincing others that we forget to attentively listen to the individuals we communicate with. This article shares 12 techniques to help you improve your listening habits and become even better at understanding others.
"Most people do not listen with the intent to understand; they listen with the intent to reply," wrote Steve Covey in his book The 7 Habits of Highly Effective People. It's true: we often listen with a specific goal in mind, with the intention to reply, to share our perspective, or to convince the other person. As a consequence, we don't pay full attention to what the other person is saying or filter what is being said; we only hear what supports our view. We obtain partial or selected pieces of information, which can cause us to draw the wrong conclusions and get the wrong end of the stick. To avoid these issues, start by taking a sincere interest in the individual and what the person has to say. Make a conscious effort to listen to understand, not to reply, correct, or criticize.
"Should I write a book?" Someone asked me this today, and I rattled off an answer.
But as I was doing so, it occurred to me that I get this question frequently. Probably a few times per month, at least. And this makes sense, since I've written a few myself and I'm in the content business. Heck, one of those books has even enjoyed more success, commercially, than I ever anticipated.
When it comes to tech startups, we often talk about innovation — “digital innovation” (or “technical innovation”) in particular. It has, unfortunately, become a cliche, and now “innovation” is devoid of meaning. I’ve been trying to do some meaningful analysis of the “innovation landscape,” and to classify what is being called “innovation.”
The broad classification I got to is “technical innovation” vs. “process innovation.” In the majority of cases, tech startups are actually process innovations. They get existing technology and try to optimize a real-world process with it. Some examples of these processes would include “communicating with friends online,” “getting in touch with business contacts online,” “getting a taxi online,” “getting a date online,” “ordering food online,” “sharing photos online,” and so on. There is no inherent technical innovation in any of these — they either introduce new (and better) processes, or they optimize existing ones.
There are patterns to bad writing. I'll give some examples based on a blog post I was sent. It's also based — indirectly — on some of proposals I saw for PyCon and PyDataDC.
For the conference calls for papers, I can ask a few questions of the author, but that's about it.