How to devlog

Before we answer how to devlog, we will first answer what devlog is according to me, why one should do it, and how to do it. Over the last year I spent a lot of time running a series called devlog where I would update what I do related to CS that day. Very simple. I got this inspiration from the legend Rui Ueyama who is the real 1000x engineer. Think of an expert in a domain where there are hardly 10-20 folks who are good enough in that domain and maintaining a core piece of software that powers the world. Rui is one among them. I was going through this blog by Rui, https://www.sigbus.info/how-i-wrote-a-self-hosting-c-compiler-in-40-days, where he built a self-hosting C compiler in 40 days. My first reaction while reading this was “what a cool idea.” Not only was the whole blog super cool, I was able to pick up his thought process and I really enjoyed reading it. That’s when I started this devlog series. First series was mehhh, the one which I am currently doing I really enjoy it. this series is the one I would love to read as an end audience. Devlog can be about anything, it doesn’t have to be purely technical, it can also be about what you do in your everyday life. Let’s just assume you want to do a technical devlog. I will share a few ideas on how to approach this. Category 1 is if you are unemployed, have a lot of free time every day: for this category just be consistent every day. Never miss a day, also don’t slack off, and make sure you move the needle every single day throughout the devlog time frame. You have the time, there is no excuse to slack off. Use this as an accountability factor to stay focused and do work. Who knows, someone can really like your consistency and thought process and can also give you a chance to interview. Category 2 is where the majority of us are. We have a busy job. Just starting to think of doing something like this is in itself a great achievement. Congrats. But we have to be practical about it. Either you can push yourself to add this as part of your existing commitments or take it at your own pace. Try to show up every day. Don’t force the habit. Think of it as an activity you would do forever. How will you structure an activity that’s a marathon, not a sprint? If you start thinking this way you will start placing this activity in the time you are most comfortable at, after prioritizing work and life. If you think about it, if you are in tech you’ve got to constantly keep yourself updated, increase your knowledge surface area, brush up your fundamentals, and fill in the gaps. Being curious is key, and there is a price to pay for being curious and proactive(your time). Either you can dump it all in your head once a year or whenever you want to switch jobs (in most of the cases studying something only happens during a job switch) and feel overwhelmed, or you can always incrementally feed your curiosity. The latter is always better. Plus by doing a devlog you have an accountability check from the audience, which keeps you on track.

Few pointers:

• What should I devlog on? Just like Rui, you can take up a single project and keep working on it for the complete period, or else, just like me, where I don’t have a proper agenda for the next 40 days but I would consistently build/study something on topics whatever I am interested in. This is slightly easier than first choosing a single project, because choosing what you want to devlog will make or break it for you, because you have to make sure it interests you throughout, equally challenges you, and you learn something new every day (that’s the whole point!)
• How long should I spend on it? Depends. Ideally 1-2 hrs a day would be really really good, but it completely depends on you. Also remember that not all days are productive, so some days you might just have energy for a 30 min session and other days you might put in 5-6 hrs straight, so you don’t have to worry about bad days because we’re all humans, so remember it eventually averages out. The only thing you should keep in mind is if you have a bad day, it’s completely normal, but you should try to get back to the routine, which is the most important thing here, coz consistency is not linear
• Be honest with yourself. Nobody is giving you a field medal for your consistency here. The last thing you want is someone smelling your bullshit in no time. This is just for your happiness. So be honest with yourself. I would love to see you have an off day, see you struggle, wake up from your slump, and gain momentum again!
• Language should be as simple as possible. Trust me, a large portion of the audience who reads my devlog doesn’t have the same technical background as mine. Some do, which is very useful in exchanging thoughts, but assume nobody knows what you are speaking about. A side effect of writing this is inspiring others in whatever scale possible. Rui inspired me and in the same way you can inspire others. So keep your language so simple that it doesn’t overwhelm your readers. Explain like you’d explain to a 5-year-old. This is very very important. Keep this in your mind.
• Reduce as much friction as possible. Add adequate links to what you are studying and the people you are referring to, add images if possible (you don’t have to draw, just ask Claude to generate and attach it). Keep it candid, which includes adding your thoughts, just a line of how your day went, your witty humour and banter etc etc. Ideally think of your devlog as your diary and you are adding an entry to it. The last thing that we end users wanna read is an RCA-style technical blog.
• Keep it crisp and sharp. Saves your time as well as your reader’s time.
• Do not use AI to write one. You writing it by yourself helps you to think deeply and pen down your thoughts better. Just use it to spell check if you are insecure about spelling errors.
• My recommendation is to try to pick topics tangential to what you work on. Something which you always wanted to try out but don’t do as part of your job. Like brushing up on core fundamentals which you don’t use as part of your job anymore. You might be a frontend dev, you can try out a new lang, framework, do backend stuff, etc etc, whatever makes you feel uncomfortable to touch and explore but enjoyable at the same time.
• Don’t feel demotivated if people don’t interact with you every day for what you are posting. Think of it this way: if someone opens your blog in a year, he should have fun reading them day-wise. Also be open to discussion and revert back immediately if someone interacts with you on that day’s devlog.
• Store chronologically, latest day last. Folks should be able to scroll and read each day chronologically.
• Last one: be consistent!