About Me/Intro to Blogging
Who am I?
I am a junior software developer. I have been in the field for 2.5 years. I am hesitant about the idea of having a public online presence, but there are still a lot of reasons I want to start this blog. Here are some of them, in no particular order.
Why am I blogging?
I want to document things I’m mulling over and ways that I’m learning and growing over the course of my career. I have had many phases of learning and plateauing so far in my career, and it would be nice to be able to look back on those phases and internalize my progress without solely relying on my memory (a concept that is very topical to my next blog post - stay tuned).
I’ve also always wanted to find a way to marry creativity and tech. In that vein, I want to develop my literary voice. I think creativity can only add to my career prospects, even giving me more flexibility to pivot if need be. I want to always be prepared to make a career change if it comes to that. I’ve heard that some of the best technical writers are former software developers, for example.
Lastly, most tech blogs I read are from junior devs or other industry professionals working at fortune 500 companies, tech startups, or otherwise large, well established private-sector companies. As someone working in the government/not for profit/public sector, I want to provide a different perspective.
What makes a public sector perspective significant?
My workplace feels different enough that when I’m reading a book, article, or documentation of a new framework or feature of a tool we use, it seems aimed at a completely different audience. The default seems to be large development teams that build solutions used by thousands or millions of users. From my experience in a small organization, speed and profit are not prominent factors in most of our work. If something breaks, it is our job to fix it and prevent it from happening in the future, but we’re not losing money for every moment a service is down.
Time, resources, and team size are also different. At a large company, you might have designers and developers and quality assurance personnel all assigned to a project, but in small organizations every developer does all of those things. We plan, develop, test, and manage everything.
What can you expect from CaraCodes?
I like bulleted lists. I like using parentheses. I sometimes use words that are bigger than they need to be. I tend towards writing really wordy sentences (but I’m working on it!). Some of the things I write about will betray my juniority, but others I hope will offer insight to other junior developers in similar positions.
Given that this is a blog for my profession, most posts will be more formal in tone, but some will be more casual (like this one).
I've encountered writing from junior developers at organizations with legacy code bases who write about their frustrations and their attempts to change things to be more in line with industry best practices. These efforts, unsurprisingly, are often met with disdain from coworkers. I hope to avoid that energy in my workplace, and also here in this blog. I intend to talk about what works and doesn't need changing, in addition to areas that could use some updates and why. Tech startups on the cutting edge of innovation are cool and all, but legacy systems are also rich texts. I hope to add to that conversation.