I have been blogging each week for the past 20 weeks 😀
I actually joined dev.to on Aug 2019 (I previously wrote on Medium), but it was only in Oct 2021 that I decided to start publishing a new article, each week, on Friday.
This resolution came from the fact that if I already devoted myself to constant learning, I might as well document my journey and share my experiences and insights as i go, with hopes my readers will find it interesting and helpful.
Writing, in general, and technical writing in particular was nothing new to me. My technical blogging goes back to 2005, but this recent period of 20 weeks has brought a different kind of experience for me, both in audience exposure and recognition.
In this notable milestone I thought it would be nice to “break the fourth wall” and share with you some of behind the scenes insights from the work process I’ve adopted, the challenges, the benefits and the achievements which came along the way.
The Process
As with almost anything creative, it starts with inspiration.
As a full-time Frontend Architect and a side-projects lazy-juggler, I find myself bumping into new concepts and ideas all the time. While I let some pass uninterruptedly, others really spark my inspiration and those which do, get registered as a potential topic I would like to explore (literally, they go into a list I keep 📝).
It’s important to note that I don’t tell myself “oh, this is something I would like to write about next week” but rather it is an “oh, this is something I would like to learn about and deepen my knowledge in”. Writing is a byproduct of it.
I keep the writing as a “study journal” if you wish. It also serves me later when I totally forget how I’ve made something (which happens more than I’m willing to admit).
I might use small bits of time during the week to explore more before I start the actual work, just to make sure I didn’t choose anything which is way over my time capacity. The next thing to do is finding a pragmatic use case I can code in order to implement my study. Once I have the basic idea of what I want to learn and how to implement it, I’m ready to go.
Topics can also be my own opinions or practices which I feel passionate about. I still haven’t decided which is easier to write 😉
The writing itself takes place as I go, so you are kinda making the journey with me and I find it extremely effective since I’m not prettifying anything in the process - if I bump into trouble or challenges, you will read it “live” as it happens and then how I solve it (if I can… sometimes it does not go as smooth as I hoped it to be). I try to document anything relevant which also means taking snapshots and adding code snippets.
At the end I have something which is a good scaffold for an article (or a blog post if you wish). I then go over it a couple of times, tidy things up, make sure that it has good continuity and context and that it all makes sense as a single piece, but the hard part at this point is already behind me.
The Challenges
It's not easy writing each week.
It takes a lot of self discipline to sit your ass down on a Friday morning (which is also my weekend's free day) and start coding/writing.
Sometimes it is even harder to come up with an interesting idea which will inspire me to go at it. I then need to take this topic and translate it into something practical which I can implement in code. Sometimes the code bases I play with are not quite suitable for the concept I wish to demonstrate, which in that case might bring the whole thing down.
The time capacity I have also presents a great challenge - The time I usually have for publishing a blog post is around 4 hours, but you know what? I wouldn’t want it to be more even if I could.
Yes, there are many challenges in the process, but the benefits are evident.
The Benefits
The benefits of blogging are well documented on the web, but here are mine -
Setting this kind of commitment means that I always look for something new to learn. I always look for something to inspire me. Aside from pushing me forward and helping me gain more knowledge and experience, it really helps in avoiding the infamous developer's burn-out.
Writing posts means that you need to know what you’re talking about, and if that’s not the case then it forces you to dive deeper and insist on the small details, like “why does this fail?”, “why are we getting this message?”, “is that the only way to implement it?”, “why do we need to configure this in that way?” - all these sorts of questions are super important questions that I’m sure some of the readers ask while reading and therefore I need to supply the answers.
There are cases where readers comment about something which I’ve done wrongly, or perhaps on better ways of achieving something and that’s a great bonus. As the saying goes “if you wanna get the best answer fast, post something wrong and others will be quick to correct you”. I’m not saying I do that on purpose (am I?) but there is also gain in getting things wrong. Everybody learns.
Blogging consistently is also a great tool for enhancing your personal professional branding. Some of my posts got some nice recognition on the web, with many reads and likes, and I’m not taking it lightly. Aside from giving me a good boost of dopamine, it also allows my name and craftsmanship to reach people I otherwise wouldn’t be able to.
Last but not least is allowing yourself to be a little more exposed - I think that exposing yourself to critics in our industry and the very reasonable chance that others will bash you, is a good practice for those who suffer from the imposter syndrome, like yours truly. It kinda helps putting it all in good proportions, and the achievements will follow.
The Achievements
So aside from learning and gaining more experience,there is the recognition and feedback you get. Allow me to elaborate a little more about some of mine which I’m very proud of:
I have 97,308 reads in total to date.
The “Creating a React component with TDD” article received 18,909 reads to date. It also appeared in React Status newsletter and had mentions in React Tutorial and React Digest Twitter acocunts.
The “Why practicing DRY in tests is bad for you” article was included in issue 107 of the Software Testing newsletter.
The “Why Testing After Is a Bad Practice” article received 12,070 reads to date and raised some interesting discussions on dev.to and Reddit. It actually got to be in the top 7 “must reads” of dev.to. Speaking of which, I got some cool badges too:
The one I’m really proud of is the “top 7” which is dev.to’s “Awarded for having at least one post featured in the weekly "must-reads" list at any point. 🙌” (BTW, this also comes with a really nice award from them 🤗)
In the “followers” section I’m on the brink of 2k followers on dev.to and my twitter account also gets some love (join the party @mattibarzeev)
Along the way, and something which started as a study project, I’ve created my own monorepo called Pedalboard which helped me understand monorepos so much better. I’ve also improved my Word-Search game, which still remains my React punching bag.
And there are many more…
Wrapping up Going forward
This is certainly a milestone for me.
I don’t see myself stopping this blessed habit in the near future since, despite the challenges, I’m gaining so much from it.
The topics will not run out on me and I hope to keep getting inspired and share my experience and coding adventures with you. If you have any ideas on what can be improved I’d love to hear about it in the comments below.
Would I recommend it for you? most certainly, for all the reasons mentioned above.
I would also like to take this opportunity to thank you, the reader, for reading and participating in my coding journey. Your feedback is my 🚀 fuel! Rock on!
Photo by Isaac Wendland on Unsplash
Top comments (3)
You rock 👏👏
🍻 mate!
keep going strong 💪