Hello, World: Why I Started A Blog

Hi, I'm Stephen. If you don't know me very well, I'd encourage you to check out my bio to take a peek into my life and how I operate.

Back? Great! Now that you have an understanding of who I am and what drives me, let's dive into what this site is and why it exists - a sort of 'what to expect when you're expecting' for readers of this blog.

Sharing is caring

Reference materials can be difficult to find - I spend quite a bit of time searching Google and Stack Overflow for helpful articles and documentation. Sometimes I find a tech blog post by someone who has already solved the exact problem that I'm facing, and I feel like I've struck gold. I'm not sure if every post will be able to guide someone to a Eureka moment, but if I could provide that experience for even one person, it would make writing these posts worth it.

Imposter syndrome

Like many engineers, I've found myself second-guessing my skills at times. Maybe I've had a rough time implementing something that should've been trivial. Or it could be that I started a new position and it feels like everyone on the team is more productive and knowledgable than I am. Experiencing this feeling can be a good thing, as it provides an opportunity to learn and grow, but no one wants to consistently feel inadequate.

One thing that has helped me push through these feelings is writing and sharing documentation. Whether or not it's "just" internal documentation at work doesn't matter, being able to confidently document something and share it to the rest of the team or wider organization is proof that - even if you're not knowledgeable about everything - you are knowledgable about some things. Knowledgeable enough that you're able to write a document explaining how a thing works.

I'd encourage anyone who's experiencing these feelings to try this approach. If you can't come up with any documentation that needs writing, maybe think about something that you documented before, or take extra time to help a colleague who is struggling with a particularly difficult task. Just remember that the goal here isn't to prove to others how skilled you are, it's to remind yourself that you have something to bring to the table - just like everyone else.

My approach to this site is similar to the one above. I'm going to put this "documentation" out there, and maybe it will have an impact. But if it doesn't, that's okay, because it can be a reminder to myself that I have something that's worth putting out there.

Hall of memories

Looking back over previous experiences is an important part of growth, both personal and professional. After all, how can we truly learn from our past if we don't take the time to review our experiences and internalize the conclusions we came to? That most of the posts on this site will be technical in nature does not detract from them as catalysts for self-reflection.

In software development, learning isn't optional - it's essential. Many software engineers started with the desire to create something new with technology. The first step? To learn how to code. They picked a language - like Python - and started learning enough to create a 'hello world' program. With this under their belt, they likely chose a slightly more ambitious project and spent time reading documentation to gain the knowledge required to build it. After that? Maybe building a web app sounded exciting, so they chose to learn about web development with React. Or, maybe they wanted to learn iOS development. And so on. You get the gist.

Throughout all of this constant learning, most developers find themseleves thinking deeply about their work. They may ask themselves, "Is there a faster way to accomplish this?" or "I remember solving a similar problem a week ago. Does that same solution apply here?" In the case of the second question, they might find themselves looking back at previously written code, trying to remember what thought process brought them to the solution, hoping that similar logic could be applied to the current problem. Such is the importance of peering back into one's previous work - it gives a starting point for solving future problems, and helps refine the thought process.

In this way, it makes sense to approach this site as a sort of journal. I find that, a lot of the time, I end up searching for old code fragments, prior insights I may have had, or looking for user stories I completed in the past to help when I approach a problem that I know I've solved before - or when I'm just touching up my resume. Documenting my experiences coding - both the triumphs and the failures - will hopefully make this process of looking back simpler, and allow me to quickly sift through my work when approaching similar problems in the future.

---

If you made it this far, thanks for reading! I hope that some part of this resonates with you. If you feel like this sort of content interests you, that's great! I hope you stick around through my journey. If not, I hope that I at least gave you a few things to consider as you embark on your own.