Steven Herod, Salesforce CTA, Managing Director for Salesforce Platform at Accenture, shares what Salesforce architecture and Salesforce developer roles are.
Main Points
The main points Steven talks about:
- Steven’s current role, past working experience, CTA journey
- What does it mean as an architecture role
- How to tell between good and bad programmers
- Why is programming difficult
- Find a team and company that shares the same value as you do
Links
Video Teaser
My Takeaways on Salesforce Architecture and Salesforce Developer Roles
The guest Steven has a working experience of multiple different roles.
He is the type of person who “does whatever the job in front, and get it done”.
He works both intelligently and diligently, received CTA certification after joining the Salesforce ecosystem for only two years.
This is an unbelievable record that I bet nobody can break!
In the chat with Steven, we discussed both the architecture role and developer role in general.
He also answered some of the long-lasting puzzles in my head, such as “how to tell between good and bad programmers”, “why is it important to find a team and company to share your vision and value”.
During the discussion, I also realize that Steven has an amazing skill — he can naturally bridge the gap between business and technology with his easy-to-understand analogies.
He is the type of talent who knows both business and technology worlds well. Unique!
Btw, I also highly recommend you to check Steven’s YouTube video on what he thinks architecture’s role is. This is a summary of his many year architecture’s experiences.
Related Episodes
Episode 4, where Dan Appleman shares his wisdom on what is a good developer, is what I’d recommend you to listen to.
In addition, he also shared how to keep up with current technology and learn knowledge effectively and efficiently.
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:18] This is Salesforce Way podcast. In this episode, a guest is invited to talk on one specific subject. Our goal is to help our listeners to not only become better Salesforce developers, but more in general, better software engineers. So hope you enjoy our content.
[00:41] Stephen, what what is your role in Xcentral at the moment? Okay, yes, and I should I should mention that I'm here on a personal basis, not speaking for the company. Yeah, the the the thing I would, I mean, my role is. I'm part of the leadership group associated with the Australian and New Zealand Salesforce business. So we've got around about a hundred and eighty plus Salesforce people in the practice, plus all the supporting people outside of the Salesforce practice. So that's probably a couple, a couple hundred more. And my role is really technical architecture and capability development. And and I also look after or or help coordinate some of our platform.
[01:37] Work globally, so I've got a team of people that were sort of working together to to build up Accenture's capabilities just in the Salesforce platform and and get the best of our global network. So one of the mitigations of not having enough time. Is to have many, many different people doing many different things, and simply telling us the answer. So I don't necessarily need to become an expert in everything. I can rely on on the team and our network to bring the right expertise in at the right time with with customers and and our own own stuff. So yeah, my roles.
[02:22] All of those sorts of things, and on a day-to-day basis, what does that mean? I'm giving advice to customers on how to architecturally design their Salesforce orgs for large-scale projects. I'm talking through concepts and design choices. I'm influencing customer decisions. I'm Troubleshooting problems and projects, and and working also on a lot of commercial matters. So associated with. Selling engagements and and client responses to responses to client requests. So, it's as much a business role now as it is a technology role. So I had a wide range of experience, and in some ways, you know, doing Salesforce development work was a little bit of a side step. But I was I was very much someone who, I suppose, does the job that's in front of me. Rather than having a particular aspiration about something, and so I did that job, and you know found myself passing certifications. And passing a lot of certifications, so I got six out of seven of them, and decided to set my my heart on doing the CTA, which was really, you know, Bob Buzzard slash Kier Bowden on the the community. He was very much someone I was like, well, I'm going to do what he's done and try and get the get all seven. And
[03:54] pretty soon, found myself in front of a review board and and passed within about. Two years, two and a bit years of joining the Salesforce community, and and and went from there. But I mean, it's that's amazing. It you know, it's a thing of this is the thing. I think people who achieving the A kind of sometimes gets a little lost. You need experience. Yeah.
[04:24] I have still five months to go to pass the CTA. Yeah, yeah. Put myself into your shoes. You've got to you've got to look at the experience, two years, the different things I'd done or involved in before then. So, you know, I I I. I'd been a yeah. I'd managed a team of sixteen or seventeen people at the small company. I'd been involved in some fairly large scale. Well, I won't say large scale system design because since starting at Accenture, I've kind of got a new appreciation for what large scale system design means. You know, very very large programs involving lots and lots of people. But you know, systems that were quite important. And if they failed, bad things tended to happen to us, and and so I learned a lot through through those kinds of experiences. And also working in a large enterprise in an architecture role, I got a real appreciation for, you know, what is architecture and how does it differ from being a developer or being just a general techy. And so that that was all useful experiences. Hmm.
[05:38] Hmm. I always thought I want to be a programmer after joining Salesforce. But the last time I went to the DX19 in San Francisco, we went to the boot camp. There were those CDA folks. They train us application architect path and system architect path. I got really intrigued about you know the architect parts. It's it's it's always about how to design, how to fulfill the business requirements, find the best solution, not a not necessarily an ideal solution. You just need to choose between the options, find the best one that's fitting you. So it's more or less like an art. So I I I like these kind of things that there's no obvious best solution. You just yeah need to find the trade off according to your experience. And that's absolutely you you've hit the hit the nail on the head because it's the least worst option. It's the option that takes into account a range of. A range of circumstances that that it may not be immediately immediately obvious, and that is right for the situation given the customer's circumstances or the problem circumstances, because the right answer today may not be the right answer in in a year or three years. And in fact, you know, we're very good in technology just in general of
[07:08] trying to boil things down to right and wrong. So, you know.
[07:14] You know, you would have if you've lived through the last few years. You know, SQL-based relational databases is the wrong answer. You need a NoSQL database, and and you know you need MongoDB and you need Redis and you need all these different technologies. And it's like, well. No, you know, is the data you're storing relational? Ask everybody that moved to MongoDB how they went about doing relational data management, and finding out that they can't because it's not a relational database. And it turns out most problems are actually relational data problems. It's not to say all problems are relational database, and I speak as someone who once stuck close to a terabyte of XML files into an Oracle database, and and wondered afterwards, you know, probably was that was not the right thing to do, because we were using an Oracle database as a document store. Strangely enough, so you know, it's all a case of what's the right answer and what's the wrong answer for the circumstances, and and the IT industry is so good. At fashion and chasing the next shiny thing, that's the one true answer to all things. Yeah, I remember you had a a Twitter message couple of days ago, week ago. You were frustrated about this. I don't know. Maybe you have some story. It's like people are chasing the the shiny things without understanding why they
[08:44] chose the the cutting edge. Yeah, I suppose I do a bit of a bit of cranky things from time to time. I think. I think the the one for me is, yeah, yeah. I remember what that was. That one was probably about. So I think we conflate. You know, everyone, the the context in which you are working, very much is different for everyone. Silicon Valley is a very particular world, right? It's a particular world of product development companies, of venture capital backed. Product development companies, some of whom are building extremely large scale but relatively simple applications. Right. Right. For instance, Twitter. Right. Now, it it may be a very large scale application, but I would argue that the average Salesforce sales cloud implementation has more functional complexity than Twitter, right? Like, and and so the problems that they deal with are not the same problems that some poor person sitting in a back office looking in a financial account system is dealing with, right? Like the econ, the economic drivers are fundamentally different. The talent pool is different. The technology is different. The problem space is different. Twitter does not need to update its system
[10:15] every twelve months because the regulatory environment around superannuation and retirement funds has changed in that country, which is what happens in Australia. If you're a super fund, most of their IT spend in a super fund administration system is spent constantly changing the system to keep up with all the regulatory changes. Right. So, so these these are all different circumstances, and you've got to look at the problem and the technology. And say, is it right for me? So, and the circumstances that we're in, rather than saying it's a one-size-fits-all. So, microservices makes sense to me. In a in that kind of share nothing Instagram kind of world, where you're going to have a tag service and a photo service and others, but to say that I'm going to recast an entire ERP platform. Which consists thousands and thousands and thousands of functions into several thousand microservices, and then orchestrate them all together seems to me to be kind of a bit weird, and maybe that's not really what you were wanting. So I think to me it's that's what I'm encouraging people to do. I'm encouraging people to. To understand the technology, and I'm not an expert in a whole range of technologies, including, for instance, microservices. But to understand the technology, and then understand their problem
[11:45] circumstances, and then critically evaluate as to whether it's the right thing for them in that circumstances. And I think, in that case, a lot of fashions. Will will pass over you, and some some will absolutely fix your problem and a fundamental problem that you have that you need to resolve. Right. So if document oriented databases or document management document databases had been more popular when we were building a system for the shipping industry, it would have probably saved us. Days of outages, tens of days of performance issues. Completely changed our disaster recovery business continuity environment. Like the whole thing would have been completely different. But at the time, it didn't exist, or more accurately, it maybe wasn't popular, so we didn't know about it. And so we just hit it with the only hammer we had, and the only hammer we had was a great big Oracle database, right? Right. So. So, so yeah, that's that's sort of that sort of where that sort of tweet came from.
[13:05] Hi, just a quick note here. Don't forget to check the links. Share it in the show notes, where you can find the guests' contact information and the important complimentary materials for each episode. In addition, I'd be so happy if you could share with me what you think about this podcast. You can reach me out by email, Twitter, LinkedIn, or website contact form. Your comments would definitely help me improve and deliver better content. So now let's get back to the show, shall
[13:44] we? Hmm. I guess it's not only for architect roles. For developer roles as well, we have all the different IDE and editors. We have all different frameworks. We have all different way of structuring our code. So we do need to know what's the good things, what are the bad things. Yes, and comparing them, yeah, and to understand them, I think on a on a relatively
[14:15] deep kind of kind of world, and that takes time. You know, that kind of kind of stuff just takes. Time and it's and that's often what we're all lacking, right? You lack it in in in consulting world. You lack it in just normal product development world. And so it's it's it's often the the critical thing that we're all we're all needing more of.
[14:50] I always have the struggling that when people who don't know programming or they don't know much about programming, they don't know how to tell the difference between a good programmer and a bad programmer. And they, in that sense, they just simplify the case to say, okay, if you can do it in one day, I would choose you, comparing to another guy do it in two days. So, and it's hard to argue with this mentality. If you have to spend more time to design, spend more time to write the unit test, you think it will help in long term, but. Sometimes it's not a case even like that. You might even make make mistake. I mean, the the extra day might be even lost, useless work if you didn't do it carefully or you didn't have good enough experience in programming. Yeah, it's a it's a it's a constant. I mean, it's a it's a genuine thing as to because programming. There's a there's a wonderful quote in a book called The Mythical Man Month. And it and and it's a book that's quite an old book. It was written in the 60s, I think, and it was about programming. And it talks about it. It struck me when I was at uni. Because the quote really, really impacted me, and the quote was something, mangle it now, but it was programming's like effectively creating castles in the air using nothing but
[16:20] air. Because it's such an imagination, yeah. It's really based upon on on imagination, and it's so hard to tell progress. I mean, almost everything else that happens and that humans do. An average person could come along and see how much has been done, right? You can see it when a buildings get built. You can see it when a meal gets cooked. You can see it when a bus driver drives his bus down a bus route, and almost all the things that's visible. But but programming is a very invisible topic, right? And indeed, you can't even measure it in the amount of programming done, because the number of hours invested or the amount of lines of code written have no bearing at all on whether you've solved the problem or whether it's good or not. And there's even an argument that would say the longer you spent and the less you wrote is actually the best possible outcome, and that's you know intellectually that's that's like. Really weird. Although, there is a famous quote. I think it's always attributed to different people, but one from Mark Twain was. You know, I'm sorry. This letter's so long. If I'd had more time, it would have been briefer. Because writing things in a succinct, including answering questions on podcasts, takes a lot of time, right? So, so yeah, it's a really weird kind of thing. But, but if I asked someone, if someone said to me, "How would I tell the difference between a good programmer
[17:51] and a bad programmer?" A good programmer is open. They communicate. They're generally giving you accurate indications of their progress. You know, a bad programmer will say, "I'll be finished tomorrow." I'll be finished tomorrow. I'll be finished tomorrow. A bad programmer would will attempt to. Intimidate the the non technical person into you know leaving them alone rather than simply you know helping them and explaining to them why the problem. So a good programmer should be able to explain why something's hard or something's good easy. They should be able to give you accurate, reasonably accurate predictions about their progress and where they're going. They should be able to give you suggestions about how things could be done better, or how you could make this this easier. They should be able to point out logical problems in what's been requested, right? And and those are also, I think, signs of a good programmer. And and bad programmers simply they don't ask why, they don't. They don't attempt to understand the context of the problem. They don't go looking for an easier way. They're not curious about their tooling, and they just sort of you know do stuff. And and so yeah, but but those are all very soft things, right? Yeah, indeed. If you if you are cracking open someone's code, I'm
[19:21] immediately impressed by consistent formatting. I mean, one of the programmers I worked with was a was a guy from Yugoslavia, and his indenting and formatting of his code without a code formatter was the most The prettiest code you'd ever see, right? It was just the the capitalisation, the variable naming, the indenting, the the formatting was was really lovely. And it's such a trivial thing, but it really does go to indicate the I think some of the thought patterns that that happen behind behind behind a programmer doing work, right? Yeah, maybe it's my own experience. It does not necessarily apply to like a large scale. Is that most of programmers I met in person are not pay much attention to what you just mentioned, like formatting, the clean code, the naming conventions, but. I treat those things quite how would I say serious, because I think that's how I let the the readers of the code have an easier life in future. Yes, those things are hard to. Visualize them to
[20:51] the business or to the project manager, especially when they don't have such a skill at all. No, but yeah, and that's a case of building credibility, right? Because what you tend to find is over over the long run, you will you will build credibility based on the way you are interacting with other people, right? And I mean, I've worked with I've worked with there's two people that stick in my mind particularly who I wouldn't say I couldn't say they were bad programmers because I'm not sure about their code, but certainly the way they interacted with other people. Meant that the value, whatever value they brought by their brilliance, was definitely under you know, was was unmitigated, you know, compromised by their attitude, which was very arrogant and very, very condescending to the people around them. Whereas some of the best programmers I know are just, you know, they're really enthusiastic about solving the problems. Yeah, I love that, and also maybe it's also my personal experience is that you need to find a team or the company that share share the same value as you do. So if you think the programming is something you're passionate about, you you might want to find a team that share the same passion as you do, and then you you're easier to grow up. And faster, absolutely. That's absolutely correct. I mean,
[22:21] you can't. There's. That's a thing I've learned from the business side of things, and I think gets overlooked is is that um. You, there are some. How do you put it? Have you been? Have you? Do you have like two dollar shops in
[22:43] in Finland where they're like really cheap shops that are just selling? We do. We do have one or two. Yeah, yeah. So they're you know their whole their whole value proposition is that they're very inexpensive, right? And you will have noticed, no doubt, that they're quite inexpensively decorated. You know, they're they're very basic in their in their layout and their basic in their signage and their basic in their uniforms and their basic in their customer service. You know, that's an entire business based on the principle of giving of costing the least amount of money for anybody. You'll probably, if you're in the IT department of that team, probably your entire purpose in life is to make sure that it's as inexpensive as possible, right? So you're probably not going to have deeper, meaningful conversations around you know long-term IT architectural discussions because the fundamentals of the business do not support those kind of conversations. You know, you'll find the costs go all the way down to their office furniture and head office, and it would certainly go down to their it their technology it selection and who their partners are and who they work with. So, so that that kind of thing is inherent in the nature of the business. And I think for programmers, you know, that's that's something to look at when you're looking at a place to work and the kind of work that you're doing.
[24:09] Yeah, all right. I think Stephen, we had a lot of chat. I really appreciate you spend time with me and let me learn a lot of things from you. We just pay it forward, and thank you for taking the time to interview me. And sorry for the reschedules.
[24:29] Hey, this is the end of the show. If you enjoyed the content, please connect with me and let me know your thoughts. All my contact information is available on the website at SalesforceWay.com. Thanks for listening. See you next time.
