The So You Want My Job series provides a day in the life overview of a particular Salesforce job, written by a professional who holds that job title. Hopefully, these posts will provide insights and answer some of your questions.

Today, we’ll get a glimpse into the role of a Salesforce Senior Developer.

The Job

My name is Luke Cushanick, I live in Brooklyn and work in Manhattan at 2U, Inc. My title is Sr. Salesforce Developer but my responsibilities are that of a Salesforce System Architect. My job combines aspects of the Administrator, Developer and Business Analyst roles in equal measure. I work in a large team with multiple Salesforce Administrators, Developers and Product Managers. My responsibility is to guide all of us to Salesforce design choices in data models, security regimes and automation methods that will ensure the best combination of reliable data collection, analytic flexibility, strong security, integration compatibility, scalability and more.

And doing this well requires understanding the Salesforce platform from the oldest to newest features. I maintain my Administrator and Developer Certifications as a baseline of familiarity with all key features. I don’t and couldn’t know everything, but I know a broad swath of the platform with exceptional depth in a few areas. And that helps me learn new elements quickly when necessary.

A Typical Day

6:00 – Up and at ’em!

Sure I could sleep a little later, after all it’s acceptable to start my workday at 10:00 but I like to gently ease into my day. I will usually check email shortly after waking up just to make sure there were no urgent issues overnight in my systems that need immediate attention.

7:00 to 9:00 – Ablute and Commute

If nothing needed my immediate attention, I do my morning ablutions, a little housework, tend to the pets, check my Google Tasks list, pack my bag and hop on my bike to work.

9:00 am to 10:00 am- More Channels than DishTV

Read new work emails, check 3 personal email accounts, check 3 Salesforce community accounts, check 3 Slack channels, and reply to communiqués from the past 24 hours that did not need immediate answers. Also check through the daily error logs reports from my 25+ UE Orgs noting any new errors and assessing whether they are critical problems, tolerable glitches or just known noise. The critical ones I either attempt to fix immediately or at least generate a bug report if a colleague is more appropriate to investigate and resolve.

And if I’ve still got some time, catch up on AdminHero.com and my other favorite Salesforce.com blogs (and maybe a little Facebook).

10:00 am – 6:00 pm (-15 minutes for daily standup!)

This is when I feel like my productive work starts: I resume work on the current projects and participate in necessary meetings.

My days are pretty consistent, which is to say they are subject to urgent disruptions to maintain automations or integrations, provide planned and unplanned mentorship, or give ad hoc advice and explanations about our Salesforce system and designs. I try to accommodate the disruptions while still maintaining significant blocks of uninterrupted time to concentrate on development projects, application design and fixing any issues with code and applications I’ve written over the years.

The Education

I did not have formal education in Computer Science; everything I learned was on the job. I hold a liberal arts BA and it taught me critical thinking that has allowed me to thrive in my career.

I started as an Admin in 2007 when my tech support department joined our sales team in our company’s Salesforce.com org. As a team supervisor, I knew our processes and I was asked to implement them in Salesforce.

Salesforce was new to me but I had set up lightly automated and customized support systems before. With the help of our company’s Sales admin, the Help & Training site and lots of Googling, I started building out support processes.

And I loved it. I was hooked. I could introduce useful changes fast and if built right, get analytics and security in the bargain. As soon as Apex was introduced, I taught myself to write (somewhat crappy) triggers. I reverse-engineered what I found in the Developer Forums and in return, answered as many others’ questions as I could. And answering others’ questions taught me more as well. I eventually took some paid Salesforce University training classes to fill in those gaps in my knowledge.

In return for boosting me into a career I loved, I pledged to support the Salesforce Community that empowered me to achieve it.

Responsabilities

In my role as a System Architect, I take responsibility for assessing the impact of design and functionality that affects the entire Salesforce org (or, in 2U’s case, our 25+ orgs). This is primarily the data and security models but can also include application design, development design patterns and installed or integrated applications.

Data modeling is probably the most important responsibility. When you get your data model right, analytics, security and UX fall neatly into place. It’s essential to understand principles of Relational Database Management which informs you how to assess your data needs, choose data types wisely and arrange data tables (objects in Salesforce) efficiently. Data models are difficult to change once significant amounts of data exist and a System Architect must make extra effort to understand the current data needs as well as predict how that data will be used and changed in years to come.

Security is, or should be, the scariest responsibility. A touch of paranoia goes a long way when making security choices, as does understanding the Principle of Least Privilege. The Salesforce platform offers exceptional security architecture and you need to take full advantage of it while planning for your org’s growth. This means choosing an optimal balance of Profiles, Permission Sets and Roles so that it’s easy to tell who has access to what, flexible to satisfy one-off requirements and above all protects your company’s and customers’ data. It also requires understanding the numerous other security controls such as login options, time and location restrictions, oAuth, API access and audit trails. This is the facet of the job where you must lean towards “No”.

Application development can range from very small processes that are no more than a few new fields, custom objects and workflows all the way up to complex combinations of installed applications, custom code and external integrations. I find it advantageous to be hands-on in declarative development in the Setup menu as well as imperative development in Apex and Visualforce. This ensures that I stay current with the rapid evolution of the Salesforce platform. Development also demands testing and deployment, which can take up as much or more time than the development itself.

The Best Part

Getting to make key decisions that can have great benefit to the company and its clientele. I like solving problems, interacting with a variety of colleagues and optimizing systems for efficiency. And I like taking full lifetime ownership of the systems I design, getting to redesign them as better methods present themselves and the satisfaction when they deliver reliably for years and years.

The Worst Part

Getting overwhelmed. Many issues and projects can all demand prompt attention in a sizeable organization with many users, functions and developers. I want to manage them all but know that dividing my attention between too many won’t produce great results for any. I have to delegate some of the interventions I would really enjoy handling myself, and some irritants I’d like to remove have to be tolerated while more critical issues are solved.

Work-Life Integration

My company recognizes the importance of work-life balance and it’s rare that I have to work much overtime. 40-45 hour weeks are the norm for me, business travel is rare and, if I’ve done my job well, off-shift problems are infrequent. I do tend to check work communications outside of the workday every few hours and I’m ready to drop everything if a problem occurs that I can solve most efficiently.

I average a few hours a week of Salesforce-related learning or teaching and my participation in the Community makes that a socially enjoyable venture.

Some Advice

Becoming a Salesforce System Architect takes many years of experience with Salesforce as well as other platforms and technologies. Fortunately there is no one absolute path and so you can choose to excel in the aspects that you most enjoy but acquire just enough compatible knowledge about the aspects you don’t to know what resources you can depend on if necessary. Learning, experimenting and exploring are all vital for the field so find channels for those that suit and motivate you. Take ownership of your projects but be ready to adapt and collaborate, and most importantly, take pride in your craft.