There are many stories like this, but this one is mine. I was born in North Carolina… wait, that’s probably too far back.

Becoming a Code Monkey

Since an early age, I’ve known that I’ve wanted to be a programmer. I use to “design” web pages on Angelfire and dabble in BASIC back in middle school. Looking back now, it wasn’t anything special but it was the catalyst that would carry me into some of my high school classes and eventually on to my degree in computer science from North Carolina State University (go Wolfpack!).

After graduating I didn’t feel like I was a developer. I started full-time at Red Hat as a Technical Support Engineer and worked cases with customers fixing problems they had with Red Hat Enterprise Linux and other Red Hat products. While working I frequently put my knowledge to use writing scripts to give to customers or to help make my workload easier. After writing some tools that were used by technicians, I still didn’t feel like a developer.

Becoming a Developer

After a while I eventually found myself working on our Portal team doing real development. At this point I started to feel like a real developer. While it wasn’t my main job (I was the Training Manager at the time), I was working on a team doing real development work. We had a team goal and we working on a customer facing project. To me, that’s what made the difference between a Code Monkey and a Developer, a vision versus just a goal. Before this all the coding I did just had a goal. There was something that could be called done but there was no vision, no purpose other than coding something.

Read More: Ten Years at Red Hat

Becoming a Salesforce Developer

After a while it became apparent that we needed to condense down our numerous ticketing systems into a unified system. Because of the cyclical nature of training our new hires, I had some downtime in my normal job and was asked to help do a pilot of Salesforce to see if it could do everything we needed a ticketing system to do. We had someone that was a Salesforce admin and knew the platform well but didn’t have any real programming experience. I was brought on to learn the platform and help write some very basic triggers. After a while, I was hooked. I loved the hosted nature of the platform and the testing requirements. So we decided to make the move to Salesforce and I was brought on to the Customer Case Management team as a full-time developer.

Salesforce MVP

I needed a way to give back to the community. Part of my way to give back was to help develop Solenopsis. Solenopsis is a deployment tool that we use internally and because it’s part of our build process, we’re constantly adding to it. Dreamforce also gave me a chance to present our CI process to the community. I also started working in the #salesforce IRC channel on freenode and changed the focus of my blog over to more Salesforce posts. In the fall of 2013 I was honored to be voted into the Salesforce MVPs by the community because of this involvement.

Honing My Instruments

One of the dangers of getting an honor such as MVP and becoming a senior developer is to stagnate. This is one of the worst things you can do. In order to keep myself sharp and keep on top of the changes to platform, I do a couple of things. One of my secrets is to help on the developer boards and answer questions. The trick here is not to just answer questions that your familiar with but to branch out. Spin up a new developer org and try to solve the problem. Lots of times these board questions end up being fodder blog posts.

This year I’ve been pushing myself to post something every week. This has driven me to try out new things as well so that I have something to post about. One of the ways I’ve done this is to look at the release notes and find something new to try out. Also, I’ve done several posts extending an existing Trailhead project. These give a common starting place for people to try things on their own.

How Can I Become a Programmer?

To wrap up my story I’d like to answer a question I get asked a lot. Let’s get something straight, everyone can be a programmer, but I don’t think everyone has to be a programmer. If you are an administrator and you don’t have a reason to be a programmer, don’t hurt yourself to be a programmer. The best thing you can do to help your team is to learn some of the terms and understand when code is necessary.

• Find a Reason – If you still want to learn how to program, find a reason. Just saying you want to program is great, but without a project or a goal or a reason to program, the stuff just isn’t going to stick.
• Learn the Basics – You wouldn’t go out and try to learn calculus without knowing how to add. The same goes for programming. Take a look at something like codecademy and learn the basics of logic and flow control. If you learn this well, changing languages will be much easier.
• Find a Mentor – While it’s very doable to learn to program all by yourself, a mentor will make the process so much easier. When looking for a programming mentor, I recommend finding someone with experience in more than just one language. Also, find someone that can help you learn the way you learn best. There are lots of really smart people out there that cannot teach to save their lives. You’ll be better off finding a mentor that is “not as smart” as some but has the skills to teach.
• Stick With It – It’s going to be tough. They’ll be times you’ll want to throw the computer out the window. But stick with it. The moment that your code does what you want it to will outweigh all the pain getting it done.