What Are Dev Logs?

I am officially back to blogging on a regular basis. My much-needed break is now over, and I can come back to the blog to provide my clients and other interested parties with updates about my company and the web industry as a whole. In my last post, I said that I would be posting on Tuesdays and Thursdays about random topics and occasionally would post on Sundays. Dev logs will primarily be the topic on Sunday, and I wanted to talk about what they are and how they benefit my readers and myself.

So, what is a “dev log”? I don’t know if this is a term that the industry uses, but it’s exactly what it sounds like, the logging of events that occur during development. It’s a tool that I use to put my thoughts into words and help discover problems before they occur. In dev logs, I tend to write about what I’ve done since that last dev log, the problem’s I’ve faced, solutions I’ve used or decided weren’t good enough, and potential issues that I see arising in the future.

I use Dev Logs as a way to clear my mind. In software engineering (and possibly others), there is a tool referred to as Rubber Duck Developing or Rubber Duck Debugging. You can read the linked articles, but this tool consists of a rubber duck that you talk to. If you didn’t know, all developers are a little crazy, and if you have something you can talk to and discuss your problems with, you are more likely to find an answer. If you’ve ever had a discussion with someone who knows nothing about the problem you have or the solution you need and talking to them helps you lead yourself to the solution, you’ve effectively used Rubber Duck Developing, but you’ve replaced the duck with a person. Developers can’t always use a person as people get annoyed when you start talking code to them at 2 in the morning while they’re trying to sleep. These Dev Logs are essentially a form of Rubber Duck Debugging to me. As I write things down, my brain starts working, and I come up with some possible solutions or ideas to add to the project.

On the other hand, Dev Logs assist my readers by giving them a source of information directly from me. You see, when I write Dev Logs, I am truthfully writing them for myself. I don’t do keyword research or analysis to find out what my readers would want to know. I just write. This allows me to be completely free with how I write, allowing my readers to see exactly what I’m thinking. The other thing that could benefit my average reader is seeing how much work goes into the even “simpler” projects. I put “simpler” in quotes because I find that non-developers have a different definition of “simple” than developers do. For clients, dev logs are a great tool to track my progress on the web projects they’ve assigned to me. However, I will always ask for permission to write dev logs about a client’s project. This way, I don’t talk about anything they don’t want me to talk about.

My future Sunday posts will consist of Dev Logs for any of the projects I’ve worked on since the last post. Some of them may contain only one projects log, while others may contain 20 projects logs. There will not be a post if I don’t have anything to log. Simple as that. These logs will also be written a week ahead of time, partially to give me time to get approval from clients and make sure I can keep up with the posting schedule.

Now that you know what dev logs are, you can look forward to next Sunday, where I post an actual Dev Log. I’ve done a few exciting things this week, and I am looking forward to writing about them soon. Thank you all for taking the time out of your day to read this, and I hope to see you back here again on Tuesday!

Leave a Reply

Your email address will not be published.