https://ift.tt/3nQlam1 To be completely transparent, I am not a successful author — or even a particularly successful blogger — so if you a...
To be completely transparent, I am not a successful author — or even a particularly successful blogger — so if you are aiming to make a living from writing articles this may not be for you. However, if you are a busy Data Scientist, Machine Learning Engineer or Software Engineer, who has been meaning to start writing blog posts for a while but can never quite get around to it, hopefully this will help you getting started.
In the final year of my undergraduate degree, I distinctly remember my supervisor saying to me something along the lines of:
“Although I’m being hypocritical, I think one of the best things that you could do would be to start a blog. Unfortunately, I’ve never done it myself, but I wish that I had”
I responded with:
“I’d love to, but I don’t think I have anything to write about”.
After all, there are people out there that know far more than I do, and who is interested in listening to me anyway?
This attitude stayed with me and prevented me from doing so until many years later, and I have heard the same, or similar statements, from my colleagues. Recently, on more than one occasion, this has been followed by a conversation on how exactly I got started, and how do I find things to write about.
The purpose of this article is to detail the thought process, and practices that I use, to overcome this mindset, in the hope that it may resonate with others in a similar position. If you have ever read anything I’ve written in the past, this is completely different. It is entirely subjective, and you may not agree with all or any of it. Hopefully it works for you, it probably won’t for everyone.
Finding something to write about
Let’s start with the biggest blocker, finding a suitable topic to write about. Despite working on challenging problems on a daily basis, from university and throughout my career, I struggled with this for a long time. One of the biggest excuses I used, and even still do to an extent, is that it needs to be something ground-breaking and original. In my current role — in which I work on engagements with many different customers, working on one project at time before moving on to the next — even in these cases, we often aren’t allowed to write about such revelations publicly due to customers’ confidentiality concerns and competitive advantage!
For as long as I can remember, I have set specific time aside to research and learn about subjects that I’m interested in — maths, machine learning, programming languages, even reading history books. Often, I would document my explorations and thoughts on these areas and, if I felt like it may be useful to me again, I would keep it as a reference. On several occasions, when friends or colleagues have commented that they were interested in exploring one of these topics, I have shared these notes with them.
An eye-opening moment for me was, after sharing a guide that I use to run customer envisioning sessions, when a colleague remarked to me that I should publish this somewhere. At this point, I realised that — despite trying and failing to sit down and write blog posts from scratch on previous occasions — in these cases, I had done most of the work, except for the final publishing. As I had been meaning to start writing for a while, I set myself a challenge. Every time I spend a substantial amount of time working on, or learning, something new, I’m going to turn it into a blog post. Honestly, most of these don’t make it to publication — perhaps I’m still a harsh critic — but occasionally, it works out well.
To me, a great blog post is something that saves me time. This doesn’t have to be anything original, it could be a summarisation of a paper, or book, that I’ve been meaning to read. It could have been a presentation of something I’ve read about before but presented or explained in a slightly different manner so that it just ‘clicks’; a great example of this is Jay Alammar’s Illustrated transformer. Alternatively, it could be a well explained tutorial that walks through a problem, so that I don’t have to invest hours in solving it myself.
When you get that feeling that you have truly accomplished something after struggling for a period of time — whether that is finding a new feature in a programming language that you have used for years that blows your mind, finally understanding a research paper after pouring over it for hours, or you have finally completed a task using a library that has limited documentation after thoroughly dissecting the source code — that could be a great candidate for a blog post. You would be saving someone else the time that you have had to spend to acquire that knowledge yourself. I would recommend asking yourself: is this something that would be useful to other people, that would take them time to learn otherwise? If you have just followed an existing tutorial, the answer may be no. However, if you have spent hours reading lots of verbose documentation and aggregated this into a short demonstration, absolutely!
I find that the best time to complete a blog post is as close to this feeling of accomplishment as possible; it can be very difficult to find the motivation to come back to something later after the initial excitement has faded.
Who am I writing for?
One of the main things that I’ve heard from very successful bloggers is to thoroughly know, and research, your audience; that you should always keep them in mind and focus all your efforts to satisfying them. Overall, I think this is great advice. However, I would argue that, for someone just getting started, you should ignore this completely.
One of the main mental blockers that I faced was the persistent thought: who wants to listen to me? I don’t consider myself an authority on any particular topic and, as my interests are quite diverse, I don’t feel like I am strongly aligned to any particular subset of the data science community. In short, I had no idea who my intended audience should be, and this prevented me from ever getting started.
What enabled me to overcome this blocker was writing blog posts with one audience in mind — myself. More specifically, myself a couple of weeks ago, before I had invested the time studying whatever I’m writing about, and myself in a couple of weeks from now, when enough time has past for me to forget the finer details.
Now, when I start to work on a task that I feel may be a good candidate to write about, I ask myself the following question: if there was a blog post in front of me now on this subject, what would I want to know? This thought process helps me to define my objectives and focus on the areas that I should explore.
After finishing my exploration, I ask myself another question: If I need to do the same task again at some point in the future, which details will I need to remember? This helps me to ensure that I have included all the reasoning behind why I made certain decisions, and outline any context needed.
If you stop worrying about who you are writing for and focus on publishing content that you find useful yourself, you never know — your audience may find you.
What if no one reads my posts?
Another concern that I had was that how would I feel if I invested time into creating content, but then no one read it; wouldn’t that mean that the time I spent was wasted?
When working with others, especially with junior team members, we can often find ourselves in a situation where we are asked to explain something that we have experience with to someone else; this is a natural part of teamwork and collaboration. If you provide answers which convince the asker that you are knowledgeable about that particular area, they may refer other people to talk to you about the same topic. As this happens more and more, you may find that you become the go-to person for a particular subject. Imagine that, after being asked about a subject a couple of times, you documented your explanation; the next time someone asks you, you can provide them with that document — there is your first reader.
If there was an existing blog post, or tutorial, already available that provided everything you needed to know about solving a particular problem, it is unlikely that you would have to invest a significant amount of time or effort to arrive at a solution. However, I usually find that there are many resources, each providing some of the information required, which must be aggregated for the task at hand.
I believe that if reading about how I solved the problem can prevent a single person from taking the time to perform the same steps that I did to arrive at a solution, or contributing towards them solving a different problem, then it was worth publishing; it is likely that if two people are both experiencing the same problem, there will be others too!
Personally, I very rarely focus on views or readership stats, or even much promotion for my posts outside of an obligatory status update on LinkedIn — for those in my network who may be interested — and recommending them to colleagues who are facing similar challenges.
Overall, my advice would be not to dwell too much on who is going to read your content. By formalising your thoughts, you force yourself to be much more rigorous about the subject matter that you are learning. Additionally, in the unlikely event that you have encountered a completely unique problem that is not useful to anyone else, a well written, published solution will act as a good reference should you ever need it in the future!
General Writing advice
Whilst no two writing experiences are exactly the same, here are some general pointers on some areas that I’ve found to be useful.
- When I am preparing to spend a significant amount of time investigating a problem, I approach it with a view that — if I feel that my learnings are useful — I will write a blog post about this. Even approaching a problem with this mindset encourages me to make more of an effort to keep my exploration organised.
- If I’m working in Python, my tool of choice for exploratory work is a Jupyter notebook; this is an exploratory environment where I can experiment, as well as documenting my thought process. However, my main focus is to logically document the experimentation process, and the steps that are taken; a mix of text and code screenshots in a word document would serve the same purpose.
- Keep track of your sources from the very beginning. This includes any books or blogs you read, as well as any code you borrow and modify. I like to take the URL and paste this into my notebook; this makes it easy to properly attribute things later and ensure that I’ve referenced everything that I used.
- I always start with an objective, and explicitly write this down at the top of the notebook. This can be quite broad, e.g., “How to run a PyTorch distributed training job using Azure Machine Learning”.
- When working with notebooks — even outside of blogging — I always find it helpful to imagine that I’m writing a tutorial for someone else to read; keeping notes on what I’m doing, and why, between code cells. When things are likely to change, these may be very short — not even full sentences — and expanded upon later.
- There is nothing worse than a messy notebook, and I find a good indicator of this is if you find yourself jumping around to execute cells out of order. In these cases, I tend to duplicate cells, so that it all runs in order, and then refactor any repeated sections into functions or classes.
- Once I feel like I’ve completed my objective, I find it helpful to proceed sequentially through the notebook and imagine that I’m showing my work to someone sitting next to me. Every time I feel like I’d have to explain something, I write this down. This is also a good opportunity to do a final clean-up of the code and notebook structure.
- Doubt can start to creep in the longer that you take to publish. Once you feel that you have finished, proofread it a couple of times, port to your platform of choice, and publish! Any small errors that you’ve missed can be corrected later.
Final Thoughts
I am still relatively new to this, but I genuinely believe that writing blog posts has been incredibly helpful to my overall learning process and has given me resources to direct people to when they ask me to share the learnings of areas that I’ve been exploring.
Although it still takes me by surprise, on the rare occasion that someone approaches me — either in person or through message — to let me know that something I’ve written helps them out, it feels incredibly rewarding!
If writing blog posts is something that you have been thinking about for a while, or if you are on the fence about whether it is right for you, I would thoroughly recommend that you suspend all of your doubts and try it at least once; after all, what’s the worst that can happen?
Chris Hughes is on LinkedIn.
References
- Setting up Machine Learning projects for success | by Chris Hughes | Data Science at Microsoft | Medium
- The Illustrated Transformer — Jay Alammar — Visualizing machine learning one concept at a time. (jalammar.github.io)
- Effortless distributed training for PyTorch models with Azure Machine Learning and PyTorch-accelerated | by Chris Hughes | Dec, 2021 | Towards Data Science
How I started writing Data Science blog posts: overcoming fear and procrastination was originally published in Towards Data Science on Medium, where people are continuing the conversation by highlighting and responding to this story.
from Towards Data Science - Medium https://ift.tt/3GXn7Vl
via RiYo Analytics
ليست هناك تعليقات