Relicans host Kirk Haines talks to Custom Ink’s, Chris Mar about building an architecture practice, having a responsibility to give back to the engineers that are beginning in their careers and helping them grow in leadership roles, and why as a leader, it is imperative that you model positive behavior.

Chris and Kirk even dive into a little crypto chat, and discuss and break down things like the blockchain and NFTs in simpler terms.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Kirk Haines: So welcome to Polyglot. My name is Kirk Haines. You can find me @wyhaines pretty much anywhere on the internet, on Twitter, and everywhere else. And today, I'd like to welcome my guest, Chris Mar. Chris, tell us a little bit about yourself.

Chris Mar: Thanks, Kirk. Thanks for having me. So I'm Chris Mar. I work at Custom Ink, and I've been working at Custom Ink for the past eight years. I think my total software career is a little over 25 years at this point. Interestingly, I've had this unique experience where I've worked at small to very large companies. So I've had the opportunity to work at different-sized companies from two to three people up to 40,000-plus people because I had a stint at Oracle for a while. I bring a lot of experiences that maybe I never once had the opportunity to, just as the software industry has changed. And I was looking forward to talking to you today about Polyglot, architecture, and NFTs. [laughs]

Kirk: Awesome. That sounds great. So, when did you work at Oracle? I'm just curious.

Chris: So I was actually in acquisition because I worked at Sun Microsystems. So I worked at Sun Microsystems for many years. And we were doing Java there. I really enjoyed working at Sun. When I was growing up, Sun was one of the real big companies, so you always aspired to work for Sun. And some of the smartest engineers before all worked there. So I really looked forward to working there.

And then I actually got into Sun through an acquisition. So I was at a startup, and we were doing monitoring and management of computer systems, and then we got acquired by Sun. And I had a long stint at Sun, then we got acquired by Oracle, and I had a year at Oracle. And then that just got to be a really large company. So I actually went from Oracle at 40,000-plus down to a small startup of two people to three people. So it was a pretty big jump, but it was exciting.

Kirk: Yeah, early in my career, I did a lot of work actually on the system side. I was working for one of the Baby Bell companies. And all of the engineering staff, like 5,000 engineers, all had SPARC 5s or SPARC 10s as their workstations. And I was responsible for maintenance on all of those at the operating system level as well as larger systems all running on various Sun Microsystems workstations operating software. And so yeah, Solaris Sun Microsystems hardware formed the foundation of a lot of the early parts of my career.

Chris: Sure. And the advertising used to be "We put the. in .com." So every startup during that .com era and the turn of the century, you immediately bought stacks and stacks of Sun hardware to build your .com.

Kirk: Yeah, that was all everybody ran on for a while because it was a high-risk proposition to run on Linux. That's kind of cool. So you went from Oracle to tiny, little companies. And then, at some point in time, you transitioned from Java to other languages and found yourself in the Ruby world. Do I have that right?

Chris: Yeah, that's exactly right. So I was working at Sun at the time. I remember the JRuby guys. I saw them speak at one of the Java conferences, and they came to work for Sun. Just listening to them talk about JRuby...and then a lot of it was obviously about Ruby on Rails at the time. And I was like, wow, this was just mind-blowing the way they talked about it.

And I remember it was in San Francisco, the conference center there. They were talking about this. And I went right out, and I remember I walked right over. And Bruce Tate had written a book about getting started with Ruby on Rails. I went and bought that book immediately. And at the hotel, I was reading that book. And all along the flight home, I just read that book. And I was just amazed considering the way we were writing the J2EE applications for the web and all what we were doing, the deploying the JARs and just the complexity that we had just to make webpages, and the beautiful story of Ruby on Rails. I remember buying that book and reading it. I got home, watched that DHH video on how quickly he started a blog with the generators and things. I was hooked.

And so then I just spent the next few years still doing my day job, but Ruby and Rails just learning, building side projects, and connecting with the community. And that was one of the things that really attracted me. It was just this open community of people building cool things and sharing versus kind of like...I guess at that time; it felt like Java was really corporate and maybe not even sharing that much with each other.

So then, when the opportunity came, and I found a job that I could transition to, there was sort of a startup in my local area, Spree Commerce. So if you know the Ruby on Rails e-commerce project, they were starting a company using that on top of that project, so I went to work there. And it was a really big jump into the Ruby and Rails world and the open-source community. It was a huge transition. And most people I remember at the time were like, "Why are you going from this big company enterprise software job to a start-up with an open-source community where they're giving away the software for free?" But I felt like I had to do it. And it's been great ever since.

Kirk: So what timeframe was that? Because I remember I think it was 2008 RubyConf was in San Francisco. And then there was JRubyConf right at the end of RubyConf. Was it then or was it somewhere --

Chris: It was a little bit past there. It was in Baltimore. There was RailsConf in Baltimore.

Kirk: Okay. Oh, it was the Baltimore RailsConf. Okay.

Chris: And that's where I was like, I'm going to see if I can network because I lived in Washington, D.C., near Washington, D.C. So I was just like, I'm going to see if I can network, and I was able to find the guys from Rails Org and Spree at the time. And I connected with them, and then I was able to make the transition.

Kirk: Okay, that's really cool. That kind of sets the connections in my head. I was at that Baltimore RailsConf.

Chris: Yeah, that was a really good one. And I remember everybody came to Baltimore, and most people at the conference what they knew about Baltimore was from The Wire. [laughter] So they expected...many people I met there were like, "This is not like The Wire. It's really nice."

Kirk: Yeah, that was my experience, not so much expecting The Wire, but just that it was a nice venue. It was a nice place. The weather was great. It was really a lot of fun being there. So that covers your history and how you got into Ruby and how you got into Rails. And in that time, you've moved through quite a few different roles; it sounds like. So what are you doing today?

Chris: I'm building an architecture practice, or I lead an architecture practice at Custom Ink. I went to that startup, and it was all Ruby and Rails. But after a couple of years, I thought it was time to transition. And Custom Ink is a local company. And I got to know...again, with the Ruby on Rails community, I got to know a lot of engineers at Custom Ink just because there were so many great meetups. It was like a really small community of people who just really loved and were passionate about Ruby on Rails.

And so, when I made the transition, I went over to Custom Ink. And I worked there for a few years as a senior software engineer. As we started to really grow fast and expand the size of the teams, we really needed to build an architecture practice. I was asked to help do that. So I've been doing that for the last five years.

Kirk: Cool. And you mentioned to me when we were talking before we started recording that you've really been focusing on topics related to growing a new generation of programmers and developers and leadership topics around that. And I was wondering if there were things you wanted to talk about with regard to that.

Chris: Sure. I think as you grow in your role and experience (It's a long time I've been programming.), you start to realize I got to give back is one thing that's top of mind for me. Like, there have been a lot of great mentors over the years who have helped me grow in my career. And as being in a leadership role, so architecture is obviously a leadership role at the company. But I also have a responsibility to give back to the engineers that are growing in their careers and so paying it forward or paying it back. I have a debt, and a Lannister always pays his debts. I always think about this.

Kirk: [laughs]

Chris: I got to help that next generation. And it's a challenge. We've been around a long time, and the experiences that we grew into our careers are different than the challenges that engineers meet now. But I do think it's important to give back and help the next generation.

So when you're in an architect role, one of your responsibilities is to drive a vision and challenge the team to go in new technical directions or solve big business problems. And the engineers need to be able to take those challenges and carry them forward. And if your engineers are not helping lead the way, it puts too much responsibility on you to try to just move the challenges. I can ask, but if I can't have more people taking up, working with me, getting inspired by the same vision, and helping lead that change, it makes it a much more difficult job.

So I realized one of the ways you can give back is just to help engineers grow in their leadership. This is something I started about...I actually just took a whole group of my cohort of engineers through a leadership program. And one of the things I realized when starting this was that I would maybe talk to engineers, and they're like, "Well, we can't do that," or "We don't have authority to do that." They just don't have the skills to lead in place or even have exposure to this is how you lead.

And leadership, I don't think it's a natural ability. Some people may have a natural ability. But if you think about the great leaders you have at your company or the great leaders you admire, they’ve all learned some of these leadership tools. And they just get a lot of reps at practicing that, and that's how they become great leaders. But for technical engineers, you've always been like the smartest person in the room. You always solve problems by engineering. You can solve problems with code. You think critically, and you can solve problems. But leadership is not that. You can't necessarily just code people to do what you want. You can't influence somebody like --

[laughter]

So it's different. It's just another challenge. And when I started, I told the engineers this is just another language. These are skills you can learn, and you can apply just as if you were learning another framework that you want to use. It's just another set of tools that you can have to help you.

And so when you think about important things in leadership like change management, influencing people, having critical conversations, there are good techniques that you can learn that you can apply. And as with the reps, you can build it up to where you are very comfortable leading in place and even leading your team where you don't necessarily have authority.

A senior engineer might not have authority over the mids and juniors on his team or her team, but they need to influence them. They need to help them grow. They need to inspire them to take action where they need them to take. And so those are the kinds of skills that I've really been focused on teaching our teams.

Kirk: And so how do you teach it?

Chris: That's a really good question. So at Custom Ink, we have a whole department that teaches leadership skills. And traditionally, they teach it to new managers, new directors, vice presidents. They learn these leadership skills. They have all-day programs where you get the firehose of all these, whatever the management techniques of the day are. But you see that your engineers like we talked about, need to have some leadership skills if you expect them to take on these huge challenges and move your engineering and your technical practice forward.

So I went to them, and they said, "These are the programs that we use." And so I accepted those programs, for example, change management's a huge one. If you're in your group and if you see something that needs to change, you can't just tell people, "This is wrong. Everyone start doing it this other way." [laughs] That doesn't work. Most of the time, it doesn't work. And then you just get frustrated, like, it's obvious that this way is better.

[laughter]

But with some change management techniques, we learn that it's important to communicate and have an understanding of other people's views and understand maybe why they don't necessarily...and communicate and then to bring them along so that they feel like they have ownership in that change, too, and they're not just listening to your change. Those techniques you can learn. So then, I was able to take the materials they would use, maybe for a traditional manager role, and apply them to teaching engineers.

Kirk: So, do you run actual classes for the engineers, or is it brown bag sessions? Or how do you structure that so that you reach the engineers who need it and so that it's a productive use of time? I'm curious about the logistics of how you do that.

Chris: So the way I did it was I broke it up into different modules. So like, these next two weeks, we're going to talk about change management. And there were some class materials. Some of it is just like a LinkedIn learning video you would watch and maybe a reflection sheet with a couple of questions to think about how you might apply some of those to your job. And all I asked engineers was, like, let me have an hour a week, so about two hours over a two-week period. And then we would meet and have a...we called them a reflection session. So we would just get together.

And I thought it was important that the cohort, the group that we would meet, was all the same. So we had all senior engineers. So they are all dealing with the same situations, the same issues, feeling the same pressures from the company. They can share. They can be vulnerable and just share and say, "I have trouble with this. How do you get your team to change? How do you do these things?"

And I will admit that I think a lot of engineers were cynical at first, which as a technical person, you're always solving with code and technical just saying, "Hey, these skills will help you..." But over time, I felt like the entire group felt like they were learning, and they started to understand after a while.

So then we went through months of it. And we ended up just having a little graduation ceremony, like, hey, we went through this whole program, all these different lessons. And we built a cohort, and it was like a team-building session. So all of our seniors and juniors had this team-building session, and now they can rely on each other.

And now, within our organization, we have a tier of senior leaders that, as architecture, I can come to them and say, "Here are some of the big challenges we have to face. Here's what we have to do." And then they can take that back to the teams, and they can lead in place and lead their teams.

Kirk: Okay, that's really cool. Yeah, that's really cool. I like that structure. So do you teach it to the seniors and then rely on them to trickle that down? Or do you bring the juniors in and work with them as a separate group? How do you structure that?

Chris: That's something that I've thought about a lot. Right now, what I'm doing is I'm challenging the seniors that yes, you are now a senior. You have to give back. So you need to mentor the next generation. And it's a great opportunity for them to have leadership because, in a mentor role, you're leading and helping somebody. And you start to actually feel the pain, and like, when you were a mid-person, you knew everything. [laughs] And you're helping them, so they get that perspective of helping the next generation and helping the mids and the juniors. And then I think that helps bring that next level up so that they can then level up to become a senior.

Because the way I see it is as you're progressing in your career, the different roles, like as a junior and then as a mid, you're really good at...you're on keys, you're on screen, you're writing beautiful code, and you're solving the problems. But when you're asked to be a senior, you have a little bit...it's not just time in a role. I don't think it's you have three years here, so you're a senior now. I think it's you're starting to lead and starting to influence, so you're given the opportunity to become a senior engineer. But you're not just looking at the code. You look up, and now there's a whole team here, and I have to help that team be successful.

And you have to start looking up above your team and looking around the organization like, how does what we're doing, the changes we're doing, affect the rest of the organization? How does it fit in the bigger architecture, in the bigger vision of where the technology is going? And so they naturally get into more of a bigger role to start to lead.

Kirk: All right, that makes a lot of sense to me. Forward-thinking, looking down the road, I'm curious, do you see this as something that within Custom Ink, it's sort of like you've built the structure, and this is what it is, and it'll just continue like this? Or are there other layers and other places that you want to grow this and take this?

Chris: It's still new to me. I was trying to solve a problem. I needed to challenge the teams to, hey, this is what we need. We need to be using AWS more, so I need us to be thinking like, how do we move more to Lambda, for example? And when you have a lot of pressure on you, it's oh, I don't have time to do that. I don't have time to think about that. You have to ask the business if we can have time. You feel like all this pressure. We all feel this in our roles. But you can lead. And it's, how can I teach these techniques so then I can do bigger challenges?

So it was kind of I needed to solve this problem of being able to have bigger challenges and have the engineers lead to bigger efforts. And so then it was, can I teach them some leadership skills? Because I can kind of see it, but when you're in your role, and you feel stuck, no one's giving me time to do this. No one teaches. No one's telling me it's okay to learn this. And you can't see it, but you can learn it. And I think that was like the big aha moment for me, like, oh, if they can learn it, they can get inspired. They can start leading, and then we could all together tackle bigger challenges.

Kirk: Okay, that makes a lot of sense. I like where you went with that because that's one of the things that for a lot of personalities, and the way that a lot of people come into this work, and the way that a lot of teams function, it can be a very difficult transition. You're focused on okay, here are my tasks and my sprint, and I've got to get these things done. And the larger perspective of how that interacts with your teammates and with the direction that the technology is going, you can lose sight of that or not even have sight of it, to begin with. Not even lose sight of it, but just never have the sight of it.

And learning that it's okay to explore and to take some ownership of okay, I am a knowledgeable person with opinions that I don't have to ask permission to express and to use to help steer things, that's a hard thing to learn. And so I think that's really cool that you've taken this structured approach to teaching some of that so that then that can trickle on down. And hopefully, then your juniors that are now in this environment won't have quite as much difficulty making that transition and moving into that mindset as they advance in experience. That's really neat. I like that.

Chris: Yeah, for sure. One of the asks of leaders is to model the behaviors. And so if you're a team leader and your seniors are cynical or just feel like they can't make change, then you're going to model that behavior, and we don't want that. We want them to feel like they can lead and make change. And we want the next generation thinking like, oh, I could start doing it. I could start modeling that behavior, and I'll become a leader. It kind of becomes a virtuous cycle when the next generation becomes leaders.

And I think across the organization, especially as you start to scale up, there's this spirit of leadership that engineers have that it's beyond just the code, and the keyboards, and PRs. That's not their only job. They can drive big change. I tell the seniors, as senior engineers, they can effect the most change in the organization. If a senior says, "I want us all to start using some new library," they're the ones that can network with the other senior and say, "Hey, we're the ones making the decisions. We're the ones with hands on the keyboards. Let's start using that and prove that we can do it." And so, as a senior engineer, you really have a lot of power and a lot of authority to make change.

Kirk: Yeah, that's something that I think that there are a lot of organizations that lose sight of that. And when they lose sight of it, those engineers then feel disempowered. Then that's where you get into situations where you start having morale problems and things like that. And by empowering your developers and letting them make use of the responsibility and the power that they do have to make good decisions or to make bad decisions and learn from them, I think that that's how you build a strong engineering organization.

Chris: Sure, if you just have the smartest people...we all try to hire the smartest engineers in our hiring practice. So we have a room full of the smartest people. But if they're only going to just be coding, as an organization, you're not getting the best from everybody. If everyone feels agency, that they have ownership, and they know that they can be heard and that they can effect change, then they're going to take on the bigger challenges.

Kirk: Mm-hmm. So a tangential question just because I'm curious. So in your role, you're doing all of this architecture and leadership and things like that. Do you ever still have opportunities to actually write code and get down into the lower-level technical direction of anything?

Chris: Not as much as I would like. I think as you take on these bigger responsibilities, especially in architecture, you're not necessarily going to be hands on keyboard.

Kirk: And time is finite.

Chris: Yeah, time is finite. And I do force myself to get engaged with projects. I need to be able to boot up the apps. I'd be embarrassed if I couldn't at least boot up one of our apps and commit some code if I had to. But the way I look at it...because for years, I actually kind of thought this. The first 20 years of my career, I feel like I was a very successful software engineer. And I was like, I am never doing any kind of leadership. I'm just going to code all day. And I feel like I was pretty good at it. But I was challenged. The organization needed some architecture and needed someone to get into architecture, so I stepped into the role. And after time, just the responsibilities that came with that role, I just haven't been able to make the time to code.

But something I wish I had told myself earlier (And this is for people who are thinking about coming into architecture.) is you're still solving problems. Like the fun stuff of a challenging problem and whiteboarding out the solutions, you're still doing that. You're just not necessarily coding it up. And it's the same considerations, boundaries, communication path, single-responsibility model, all the same stuff you apply to your code. You're just applying it on a more macro scale across the systems, across the teams, and communications. So you're still solving technical challenges. So I do feel a lot of reward from solving problems like that. But no, as my day job, I don't necessarily code it up as much.

Kirk: Yeah, I was just kind of curious about that because that seems to be my experience is that even when people really want to keep their fingers in the pie, there's only so much time. And it can be hard for people to make that transition. But during your day job, do you have projects outside your day job that have your passion and have your focus?

Chris: I do. So I had mentioned one of the things I'm very interested in right now is blockchain. And it took me a while to understand just the momentum and what's actually changing. Everyone knows Bitcoin and crypto and people who are getting rich and buying Lamborghinis and stuff. But there's something else there.

And it took me a while to realize that Ethereum and the Ethereum blockchain is built to have smart contracts put on top of it. And those smart contracts are code. So you're actually writing code that lives forever on the blockchain. And then, on top of that, then you can start to build applications. So all of a sudden, you're building these decentralized applications that just run. And they can run forever on this blockchain. And it's pretty amazing when you think about it.

Like, if I were to write a...and a lot of people write exchanges. You give me some crypto, and I'll give you a different one back. If you write that in a centralized fashion, we would spin up a Rails app, and we just would write that stuff to the database, and my balance would be in that database. But that is me owning that. So everybody in the world has to trust that I'm not getting into the database and changing things.

But if I wrote that same app and deployed it to Ethereum in a decentralized fashion, now every transaction that makes a change of the data in my application is visible in the ledger. And anyone can go in and just see the transactions over time. And I don't have to maintain it. It's immutable code once you deploy it to the blockchain. So that was really interesting to me. And to see the world that was being built beyond the crypto thing, just the crypto Bitcoin stuff, but this worldwide computer of Ethereum and being able to deploy code to it and transact with it is really interesting to me.

So what I'm saying is that's kind of my hobby now. I find something interesting, and I just dig in and learn about the technology. Then obviously, that feeds back into my role of like, hey, I know about this emerging technology. And maybe or maybe not, it's useful at my company. That's where there's a lot of thought being put into, and maybe it's going to transition the industry.

Kirk: So I'm going to step you back just a second because my hunch is that there are probably people listening to this right now who've heard the term blockchain. But a lot of what you said, they hear the words, and the words make sense. But the concept doesn't quite come together because that definition of what is a blockchain, I think, can be hard for people to easily grasp. And I was wondering if you could distill it down into a bite-sized piece, the TLDR of blockchain?

Chris: Well, I'm definitely not the expert. And there are people that have a lot more experience that could explain it to you. But I could connect it to as a software engineer. I think that's where I can maybe connect that. So if you have a data store, this is a data store of, let's say, balances of an account or something. And to make a change to that data store, you have to do a transaction. And so today in the storage is $10. You make a transaction and subtract $1 from it. Tomorrow, you do a transaction to add $2 to it. Then all of a sudden, you have a history of all the changes that happened to that record in the data store.

And you can think about it like now I have a record of how that value got there. That list of transactions that made the changes to it is public. It's a public ledger. And it was agreed upon by hundreds of people around the world running these...they call them miners, the nodes. So you say, "I'd like to make a transactional change to this field." Then hundreds of people agree that yes, we can make that change, and now it's all agreed upon. And so no one's going to change it, that's it. It's in the record forever. So if you start to think about it, it's really a big huge data store. On top of that, what if you can also write code and deploy it, and it can make those changes for you? Now you have applications running in this worldwide computer.

Kirk: So would it be fair to say that just as a concept, blockchain is essentially a public immutable database in the sense that once data goes in, you can change the data, but there is an immutable transaction log of every change, and it's all public.

Chris: That's exactly what it is.

Kirk: Okay. See, I think that that's the part that is difficult for some people to grasp when they hear blockchain, and they hear blockchain being discussed. And there are various descriptions of running code and transactions and stuff like that. That very simple definition, I know, gets lost on a lot of people because there's so much vocabulary flying around that is hard to associate back to your everyday experience outside of that. It's a really interesting field. I think it has a lot of implications that we haven't even really figured out yet.

Chris: I agree. I think it's just emerging, like the possibilities. I had mentioned exchanges. You can define an organization that's an immutable code on the blockchain that just runs. You can do loans on the blockchain instead of having a bank. If you wanted to loan me money, you would deposit money in a bank, and that bank would loan me that money. I would pay them 5%. They would give you 2%, and that bank keeps 3%. And it is dependent on trusting that that bank is maintaining it, and they're just keeping values in some database they have.

And imagine you could just remove the bank. The code is not hard. You deposit this money, it gives me that money. I owe back that money, and it pays you such and such amount of interest. You could code that up, and that could just run in a decentralized way. There's no one person or no one database that is maintaining that. And when I hear that, I get so excited just thinking about what's emerging, and what's growing, and what can happen. When people start to realize...they call it a smart chain, but it's really that you can write code and deploy it and have these applications that are running in a decentralized fashion.

Kirk: And so then how does...and this gets into a topic area that I think there's also a lot of partial knowledge or lack of knowledge about and also maybe a lot of controversy about it. But how do NFTs layer on top of this? And are NFTs something that are just GIFs of cats or?

Chris: Yes, yes, they are.

[laughter]

So I mentioned that you can deploy code that runs in the blockchain. Imagine you wrote a piece of code that was just an array of 10,000 pictures of cats, different pictures of cats. And that array just had an association to like, here's the address of who owns each one. Then you deploy that code up to Ethereum. And then you can ask that contract, assign cat number two to my address, and now I own it. Then when I make a deal, I sell that to you for $10,000, assign cat two to your address. But the beauty is that the decision-making and the assignment is all happening as a smart contract that's living in the blockchain.

Kirk: Okay. Yep. So that makes sense. So then what...and this is the part that I think if you just go hop on Twitter and you go find any thread talking about this, you'll see lots of opinions back and forth. But the gist of it is that, okay, so I buy that GIF of that cat. What does that really mean if somebody else can also just copy that image?

Chris: Yes. Well, the example I always hear is that there's one Mona Lisa. And you can take a picture when you go visit The Louvre, but you don't own the Mona Lisa. But somebody does own the Mona Lisa. So there's a difference between you just having a copy of it and you owning it. But I think, realistically, if you've collected anything, if you've collected comics, or you've collected Star Wars statues (I have too many action figures downstairs) [laughs], they have a value. There's a small subset of those. And they become collectible because people want them. There's a demand for them, and only a handful of people can have them. So for you to get my Star Wars figure, I'm going to charge you money for it. So it has a perceived value.

And you can look online on proxy figures or trading cards. And there are websites to tell you; here’s the current value for trading these things, and so we can trade them. So that's practically a currency. And so I think that's where NFT...instead of those, it's pictures of cats. But what's even better, if I have a basement full of action figures, now I have to maintain these things, dust them. And if I want to sell one, I had to sell it on eBay and pack it and ship it to you, whereas these pictures on the blockchain it's just a computer transaction. It's a transaction. So I can sell you the picture of that cat on my phone, basically. I don't need to pack and ship things. And then if you hold on to it and more people want the cats, you can sell it to somebody else.

Kirk: Okay. All right, that makes sense. I think it's hard sometimes to find on the internet a nice, clear, concise description of these concepts. All you have to do is go look on Twitter. And while there are definitely very clear expressions of how it works, there are also a lot of confused expressions. And so, I appreciate that simple distillation of the concepts. That's really appreciated. And I think a lot of people will understand that. But is there anything else that you really would like to talk about or like to share with people? Anything that you're working on, anything that you want to communicate out, the floor is yours.

Chris: It's a practice. As I've gotten better in this architecture role, one of the clear attributes you have to have or clear traits you have to have is trust. And I think this is something that people have a hard time transitioning. Engineers have their code. Any change you want to make to it, I'm going to PR that code. And it's got to be exactly indented the way I like it. [laughs]

But as you're going to tackle bigger problems, you have to step away and say, "I trust that the next person is going to do a good job with that code." And I can't spend my days watching your semicolon usage. I have to just trust you're going to make the best decision. And as you move up, you have to be able to trust people on it and even more and more trust. And then I think a lot of people fall into the trap of like, I'll trust them, but I'm going to review it. I'll trust but verify. And that's not going to work. I don't think that works.

My experience is you hire the best people. And you ask them to do the job, and they're smart, and they're going to do a good job. And you trust that they're going to do a good job. And then that really frees you up to focus on other problems. And as you start to trust more and more people, it just really helps free you up to solve these bigger problems. Because if I'm solving a problem moving 100 systems around, I can't be concerned about are they going to make the right decisions on every little thing? I have to just trust that they're going to make the best decisions.

And so, to anybody who's thinking about an architecture role, that's something you have to start early in your career because engineers don't necessarily trust. We write lots of tools [chuckles] to do things because we don't trust the next person. But you have to start. And I think that's a really important trait. You have to start practicing in order to grow and to be able to take on bigger challenges.

Kirk: That's really fantastic feedback because it is absolutely true. Every engineer has usually pretty strongly held opinions on it should be done this way. It should be done that way. Do we use tabs? Do we use spaces? At some point, those sorts of things, just like you say, become less important to what you need to do. Because it doesn't matter at the end of the day whether the next person down makes the same low-level decisions that you did. They're going to make decisions that work, and that frees you up to do the other things that you need to do to empower them to continue to make those decisions that work. Yeah, that's great advice. I like that.

Chris: Yeah. So trust first and just trust in your practice that you're hiring the best people, and they're smart, and they're going to do a good job.

Kirk: Yep. Well, I think that that's a great place to wrap this up and end this. Do you want to let everybody know where they can find you online? Or if they want to reach out, or if they want to learn more about you, where they can look, where they can find you?

Chris: Sure. I mostly interact with Twitter. So it's @cmar on Twitter. And please DM me or tweet at me. And if you want to talk crypto, that's my current outside work hobby. I'd love to talk about it.

Kirk: All right. Fantastic. Well, thanks again for joining me on here. And for everybody that's listening, thanks for joining us on Polyglot. As I mentioned at the beginning, you can find me @wyhaines on Twitter and elsewhere. And you can find the show @PolygotShow also on Twitter. So this is Kirk Haines for The Relicans, and thanks so much. Find us online at therelicans.com. And we'll catch you next week.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.