Why, oh why?

I never thought I would create a professional blog before. Coming out of college, I never thought sharing my thoughts and ideas would be useful or meaningful for a public audience. A lot of questions that I had about coding could be answered by my co-workers, other blogs, or sites like Stack Exchange. Oh, glorious Stack Exchange! Coming into the coding world I started out with .NET development. This framework was very well established by the time I started my first job in 2013. So creating a blog about my early experiences in a saturated environment seemed like a waste of time.

I would consider my career in software development separate from my personal life. I love solving complex problems with new and well established technology but that passion seems to stop when I am at home. Personal coding projects at home felt like a chore and a continuation of my job. Unfortunately, this prevents me from learning new technology outside of work.

What changed? Why, oh why I am creating a blog now? Two reasons. The first being that I switched jobs and ended up working for a company that I feel really cares about the career development of its employees. Many of my co-workers put effort in advancing their careers and that was very encouraging for me. Some publicly speak about a topic they learned and present to a large conference audience. Taking command of a subject and teaching others is a great way to advance your career.

I deeply and truly loathe speaking publicly. Speaking to a small group or a group of people I mostly know is perfectly fine, but a large unknown audience is not my cup of tea. I figure blogging my thoughts and ideas would be a much better medium. This allows my introverted self time to think about what to write in these things.

The second reason I am creating a blog is because I have switched from the .NET world to primarily developing for the Salesforce platform. Salesforce development will be a primary driver for a lot of my future blog posts. Before last year I had only heard of Salesforce by name and figured it was only used by sales teams. Hearing that I would be a developer for Salesforce projects, I was hesitant to believe it would be an enriching experience. To add to that hesitancy, I quickly found out that one of their slogans and mascots was “No Software”.

I had no idea Salesforce had its own programming languages, and figured they would be limited languages. Through the months of learning the platform I quickly discovered that they are limited compared to the languages they mimic. Some of these were intentional limits to counter issues that come with multi-tenant servers. Other limits are unintentional (debatable I’m sure), like not being able to use joins for a SOQL statement or within apex code, for example. The amount of apex maps I have created to relate data together is astoundingly excessive.

Navigating development in Salesforce, I found myself going through blogs, forums, and Stack Exchange again. This time around, I found there is a much smaller community of Salesforce developers out there to cover the topics I sought answers for. I’ve also found that Salesforce has made the developing experience a lower priority. I understand declarative development for the Lightning experience is more important, but as a developer you notice this very quickly. To be fair though, Salesforce has been changing their tune lately with Salesforce DX and is something I hope to write about in future blog posts.

This blog may not be the best source for new ideas or solving complex problems. Rather, it will be an outlet for me to engage with the public so I can flesh out my own ideas and relay information that has been important for me and my work. And maybe some of the struggles I talk about can be discussed and provide some value to others.