JAMEY:  Hello, listeners. I have a really exciting news because I would love to welcome you to Episode 100 of Greater Than Code. Yay! One hundred episodes.

JOHN:  Yay!

JAMEY:  I am one of your host, Jamey Hampton and I'm here with my friend, John K Sawers.

JOHN:  Thanks, Jamey and I'm so excited to be here on Episode 100. Our guest is Jaime Slutzky. She is a virtual CTO, providing tech strategy and implementation services. She integrates software systems for creative but out of the box entrepreneurs, so they can spend their time and energy creating content and engaging with their clients. She thrives by removing tech as a barrier to letting her client’s visions shine through. Jaime hosts the Tech of Business Podcast where she showcases the role of software and technology in businesses of every size and shape.

Welcome to the show, Jaime.

JAIME:  Thank you so much for having me. This is going to be a fun conversation because I love code but I love so much more than that too.

JAMEY:  Then you're perfect for the show. I want to start out with the question that we often start out with, that always start with which is what is your superpower and how did you acquire it?

JAIME:  My superpower is taking complex ideas and just figuring out the fastest way from here to there. Honestly and truly, I can look at a complicated system, I can look at the scenario of driving my kid to carpool or a complete computer system. It doesn't matter and I figure out the best possible way and I think that that came about out of necessity because I had to find my place in the world. I don't know. I mean, it's kind of strange but it works pretty well in business and in life and everything.

JAMEY:  Yeah, that sounds like 'useful in all situations' superpower.

JAIME:  It's helpful for sure. The biggest challenge that I had with it is that I couldn't figure it out for this school year, for my daughter, to be able for my older daughter to dance and so I have pivoted her entire schedule so that she and I get one-on-one time that we were going to have if she dance. I kind of turned it into a positive because I couldn't figure out the logistics which was kind of depressing. I actually figured out the logistics but I couldn't put people in place to make it happen.

JAMEY:  It wasn't a fault of your superpower.

JAIME:  It wasn't.

JAMEY:  Your superpower worked. There's people around it that didn't work.

JAIME:  Exactly.

JOHN:  And then, it led you to come up with a good fall back too.

JAIME:  Yes, because now I get to spend time with my 12- year old. Who doesn't want to help shape them in that pivotal year, the final year before teenager?

JAMEY:  Wow, it's awesome.

JOHN:  You've mentioned obviously some personal situations where you found this really useful and I'm sure we can dive in some more of those but I'm also interested in the business situations where you find that really useful.

JAIME:  Yeah. In business, I spent a lot of time putting systems together, making disparate pieces of technology work together. It may be a WordPress website and using Zapier to do with some integrations and using a third party checkout program and doing all these different things. I tend to say, what do we actually need to accomplish and oftentimes, I can cut out a piece of technology or I can write one large zap on Zapier that accomplishes everything that needs to be there, so that we have fewer break points and that really the biggest part of it all is make it system streamlined so that they don't end up being bloated and overly complicated.

I spend a lot of time working in a course and membership delivery platform and inside there, I actually will go into the code and write things to make it so that things are more functional, so that we don't have to necessarily add-in additional pieces of technology as well. It's really just a matter of bringing the pieces together in a chronological and logical order, not just for the client who is the one who's paying me but for their users because I can create the most complicated system out there and imaginable and make it work flawlessly but that's not going to benefit the end user and the consistent user who is my client. I guess I think that's probably the biggest reason why I love honing in on this superpower is because I want to make it simple for people to use and protect not to be a roadblock going forward.

JOHN:  There are so many people who realize that tech is somehow involved in the solution that they need but completely daunted by like where do I even start. There's a million different routes that you could go when you started adapting a technological solution.

JAIME:  Absolutely and the nice thing is that there is not one right answer. It's also really helpful to know that there's not one right answer and that you can follow three or four different rabbit trails and find the best one that is for you. It had of that same thing as like just-in-time learning. It's just-in-time, what do I need to use in order to accomplish this particular task or call?

JAMEY:  I really like what you said about tech not being a roadblock and I hope maybe we could continue talking with that. I think that as a programmer, I feel like tech is what I do and what I should be doing and what I'm good at and what I should be good at and so, it's very frustrating to me when I'm struggling with it. Even at something as simple as like literally this morning, I was hiring in my job and I was interviewing someone and we're having technical difficulties on Skype and we're supposed to be doing screensharing and code and we can't and we're both technologists but I guess, we just can't and that was frustrating. I guess what you said about tech as a roadblock kind of resonates with me but I was hoping that you could talk more about it too like what kind of roadblocks it might cause and how maybe we could avoid those kind of pitfalls?

JAIME:  Absolutely. That's a great line and I actually don't want tech to be a roadblock and I think of it a lot with business owners or with people who their primary function is not in tech implementation and thinking about people who are growing a team and need to have a way of communicating with the team. They could go 20 different routes for communication and every single one of them could be successful but they get stuck at the starting point figuring out which one of those 20 they could go with.

My general philosophy is either implement or get going with something that you know someone you trust is already using or pick two, evaluate two, use the one that you think is best based on what your initial evaluation of those two, use it for at least a month and then, if it didn't work to the specifications and everything else, then compare it against one other system. If you stick with the same system that you're on, try it for another three weeks before you actually want to make a switch.

You can start down a road of trying to figure out what technology to use but if you just start using it, read the manuals, watch the YouTube videos, be in a Facebook group. There are tons of resources to answer the question so don't make the decision point of what tech to use, be a roadblock to move forward and accomplish what you're looking for.

I mentioned already that I spend a lot of time in course delivery and membership environments and I had this client who came to me and wanted to run a membership site on a course delivery platform, which in general is the way I recommend going but based on the direction that he wanted to go with his business, I said, "You know what? We need to use a different solution," and he said, "Okay, you know what you're talking about." If he had continued on using that other system, it would have put a hindrance in front of every single step just because of the way that he was doing it.

He came to me as a tech expert and said, "I think I want to use this," and I could look at the whole situation and drawing on my superpower, I guess and figuring out that it wasn't the best right solution. Tech is just a part of what we all do. It's a part of where we're at and it's super fun to get to implement something that you know is the right piece of technology.

JOHN:  It's a hard pressed to think of many jobs or businesses these days that don't have some sort of technology component and I think over time, that's becoming more and more important in what you choose and how it's going to inform the success of your venture, so having an expert on call, it got to be really handy so that you can get over those like option walk situations that you're talking about and have a sort of a framework for picking what you're going to be doing.

JAIME:  Yeah and I have my favorites. There's no question I have my favorites. I have my favorite plugins for WordPress. I have my favorite way of doing membership sites and courses and payment processing and things like that but I'm adaptable because I get to keep my finger on the pulse of what's going on so that you don't have to as the business owner, as the marketing person or as someone who is not in the space of technology all day long.

JAMEY:  I think what's striking to me about what you said is this idea that tech can prevent you from doing what you want to do. I've experienced and definitely, it makes sense but when I think about tech as a whole, I think about it like how much easier it is made so many things from like how they used to be, like when you think about what did you do before cell phone, what if you were out and you need to call somebody. It's kind of interesting that on a larger timeline, obviously life is more convenient now that we have cell phones but on a smaller timeline, there's lots of ways that cell phones create difficulties for us in our day-to-day lives and that's an interesting dichotomy to think about in my opinion.

JAIME:  Absolutely. I agree with you and I'm thinking about it that our cell phones now become a distraction as much as a tool. I think a lot of technology, if it's not put into the right light, could be seen as a distraction. I'm thinking to myself, as you said when you were out, you didn't have a cell phone, you need to get a hold of someone, I remember being at the public library and going to the pay phone to call my mom to say I need a ride home and realizing I didn't have that quarter and having to make a collect call to my mom who is 15 minutes away.

JAMEY:  I used to make collect calls when I was a kid on pay phones and when they would say like, "Say your name to tell someone who they're accepting a collect call from," I would just say really fast like, "Mom here's [speaking super fast] ... Bye," so she doesn't have to pay for the call.

JAIME:  I think a lot of us did that.

JOHN:  That actually brings up an interesting point. I would imagine that one of your considerations when sort of giving a business owner a technology solution is not only what the problem it's solving but also the obligations it creates them. They've got to keep the system running, they've got to keep it integrated into their business and so, there are some responsibilities there that you're giving them along with the system to keep it all going. How do you sort of handle that handoff like here's the thing that's working but you've also got to keep it going?

JAIME:  The best example of that is whenever I do a WordPress website for somebody. When I do that, I basically do walkthrough videos. I give them structure to, "This is how often you need to go in and run your updates. This is how your backups are performed," so I set them up as best as possible for success and then of course, I also have a retainer package where I could be the one to go in and do that. I have that actually priced a little bit high because it's not my favorite thing to do. If someone wants to hire me to do it, I'm happy to do it because I know how to get it done but on the flip side, I don't want to have it on my plate all the time.

But I think that the absolute best way to help someone do that is to set up the system for them maintaining it, so that they understand what the obligations are and what the rules are. I've used things like Process Street to create the set up for how to go in and check for updates, run your backup, do your update and those kinds of things so that they can then just add it to their weekly workflow. That's something that's worked out pretty well in the past and then, I also do screen share videos with them so that they have a set of videos to actually watch because a lot of people are visual learners and anytime, you can give a visual component to things is helpful.

JOHN:  Tell me a little bit more about Process Street.

JAIME:  Process Street is a website and it's a tool that you can use to list out every single step of whatever project or process you're going through. In the case of updating your plugins and themes in WordPress, it would be like, "The first step is log into WordPress. The second step is click on this and see what's here and the third step is if you have this, then do this. Fourth step, if you have this, then do this and things like that," and then once that process has been created, you can go in and say, "I want to run this instance," and you can actually say, "I'm running an instance of this process," so you can timestamp it, datestamp it or whatever you want to do and say, "If this was the first Thursday of the month," and that's the day you run the process and you could actually, especially if you're using more than one tool, you've got a project management tool and your processes, you can actually set up a reminder to go and run that process and you can then see that you actually completed all the steps because you checked them off inside Process Street.

It's just a nice easy way to have a procedure -- a step-by-step procedure -- and I think it's a great tool. I use it internally and the team as well here, the Tech of Business Team, especially for onboarding, it's a great one for onboarding when you want to bring somebody in. It's nice to have checklists and it's a nice easy one to use.

JOHN:  Yeah. Checklists are fantastic. There's a book the last few years called 'The Checklist Manifesto' by Atul Gawande. He talks about using them in a medical context like for surgeries and things like that but for everyday stuff, like for software releases that's something we use, it's also really handy.

JAMEY:  Do you think there's something inherently rewarding emotionally about using a checklist?

JAIME:  Oh, absolutely.

JOHN:  Oh, yeah.

JAIME:  Everybody loves to be able to check things off because then you know that you've accomplished something. I've heard so many times people are like, "I don't know how the whole day got away from me." I'm like, "Well, write it down Write down what you did but even better than that, write it down the night before everything you want to do," and then you can say, "I did it. I did it. I did it," and it's a fun, it's a visual and again, I said people are visual learners. We need visual gratification just as much as visual learning.

JAMEY:  For me I think I also do checklists. I'm bullet journaler. I don't know. Maybe there are other bullet journalers but using it to keep track of what I'm doing is definitely helpful but I think at the end of the day, I'm going to be fairly productive whether I have the list or not. But being able to look back like if I don't have the list, I'll be like, "I don't know. I didn't do anything today," but if I have the list, I'd be like, "Oh, I mailed the letter I was supposed to mail and I went to the bank. I did all these things that I did immediately and then never thought about them again because they were just chores," but it makes me able to look at my list and go, "No, I didn't do nothing. I did some important things that now I don't have to worry about anymore," and it makes me feel better about it.

JAIME:  I work from home and so sometimes, I have to go to the grocery store and sometimes, I have to do meal prep because I'm out at gymnastics that night because my younger daughter does gymnastics four days a week. That's another story altogether. Sometimes I feel like, "Oh, I didn't get as much accomplished at work or during my work time, as I had wanted to," so having that checklist of, "I went to the grocery store. I made lunches. I did this," it helps me realize that there is more to having a successful day than completing a project for a client or getting my inbox to inbox zero.

JAMEY:  Absolutely.

JOHN:  This is something I've worked with when running some of my own businesses, you need to sort of figure out who your ideal client is and figure out who is out there that you can best serve and so, I'm curious as to who your ideal client is and how you came to that model.

JAIME:  Yeah. That's a great question because it's been an evolution. I quit working in my corporate job in February of 2011. I quit that job with six WordPress freelance projects on the books. They ran the gamut from I-don't-remember-what to I-don't-remember-what. I realized that I didn't want to not remember what I was working on and what goal I was helping other people accomplish, so I have ebbed and flowed a lot in my business, trying to figure out who I want to serve and why I want to serve them.

I spent a good chunk of the early years working with fitness professionals and working with people in the fitness industry. People can't see us because we aren't on video but you guys can see that I have a weight rack behind me and I'm very passionate about fitness and exercise and all of that, so it was a really good fit for me where I was. But I found that people who are in that industry are either at the top of their game or just starting out. There wasn't really a spot that fit well for me, so I kind of pivoted away from the fitness industry and working with people who have a more established business and want to do something new or big or better with their online footprint.

They could be somebody who has an established offline business who would then wants to add an additional component online or somebody who has a business that's online and they want to add another revenue stream or another mechanism. I love working on virtual summits and of course, membership sites and courses and things like that because every time I work on that type of work, I get to touch a lot of people's lives through my clients because my clients are serving others with those things. Whereas when I was working on just websites, it was just for my client. I didn't get to see the other side past the client to their audience with what I'm working on now.

I really get to see through my client what kind of impact they're making in a greater society sense and that's for me the biggest reward. I don't have an industry that I work with, specifically but I work with people who are more established in their businesses and are ready to take that next big leap.

JOHN:  That's really interesting. One thing also that comes up related to this is like what are the attitudes towards technology that you run into with some of your clients? is there a wide range or do they all have similar feelings about it like whether they want to do it or don't want to do it or afraid of it or really eager?

JAIME:  It runs the gamut as well. I think that most of them know that technology is the answer but they don't understand how to get from here to there. They don't want to necessarily break anything and sometimes, people think that everything falls on my plate when I'm in the implementation phase but I don't work on their content. I don't work on their design. I'm not a designer at all. I have no interest in doing design. I love implementing design.

If someone comes to me and they want to build out whatever it might be and they think that everything falls on my plate, I'm like, "Okay, so I need your branding document. I need your graphics and I need this and this." Oh, you don't do that? So I think there's a little bit of confusion as to what falls into the tech and what falls into other aspects of the project. I think that probably the biggest thing that people are surprised about is what falls into every single project. When you're working with different projects coordinators or team leads or things like that, there is going to be a different subset that that team is going to take on that other teams don't, so you never really know until you're in the thick of the conversation, what else is going to be necessary.

I also think that sometimes, there's an oversimplification that is done by the tech people, not me necessarily but probably me sometimes but we live in tech so much. We may not document one piece that then when we hand that project off to someone else, that piece falls through the cracks and then it causes problems and then they don't know where to go and this and that and whatever else. It becomes a little bit more chaotic and convoluted a little bit, so that is a challenge for sure that it is only as good as the documentation and the thoroughness and everything else. I think the biggest issue with technology is people don't necessarily know what they're getting because it's not like they're picking up a loaf of bread.

JOHN:  Yeah, there's that gap between the complete novice and the experts that we are in certain areas, where you have to empathize with where they are and sort of shift your mindset to realize like how they're coming at it to think, "Oh, that's right. When I just say log into the website, there could be 15 steps in there that they don't know about," so you have to write them out and make it clear so that they know what those steps are.

JAIME:  Yeah. Sometimes I install two-factor authentication. Actually on a lot of WordPress sites, I install two-factor authentication and I have a number of my clients say, "I don't want this. This is too hard," and I'm like, "I'm doing it for your own good. You trusted me with this site. Please trust me with this," and that usually gets them over the hump of it but that is always the case, that there is always going to be a balancing act between what's going on now versus what's going on in the future and making sure that everything stays up and clean and good and organized. It can be convoluted and messy but it's fun.

JOHN:  When you're thinking about handing off a project back to a business owner, there's, I would imagine, a huge documentation component. You talked about videos as being one of those things like screen shares and the Process Street stuff. What other things come into that package like? Do you also have written documentation? Do you do meetings or more about that handoff?

JAIME:  Yeah. That's a great direction to take things and I do documentation. Oftentimes, if I've written that chunk of code, I will pull that code out and I will put it into a document that I then convert into a PDF so that they can't edit it, so that it's just there as a safeguard in case for whatever reason the code got overwritten or things like that. I keep that. I provide it to them as well. I summarize what I did in plain English. When I'm working on something else say, I wrote this code which does this, so they don't have to understand and be able to read the code and then I will do a video call walk in the them through everything and we'll record that so that it's got both their questions and my answers on it.

The transfer process seems pretty straightforward. Most of the time, the biggest thing is when I'm actually writing code to make sure that that's well-documented. I wrote a full on plugin for one of my clients, which was fun and exciting and everything else and that one was a lot of documentation: why are we writing this plugin, how is it working, what documentation did I use in order to make sure that it was structured correctly. I've got a lot of citing sources and stuff like that in there as well but for the most part, as long as they understand what was done in plain English and have a recording of their questions with my answers, that's generally where we end up.

JOHN:  I think documentation is generally a huge need, like it's something we recognize. On the teams that I work on, documentation is important and perhaps, not as thoroughly produced as it should be. I'm sort of thinking about you're communicating maybe with your other team who are other developers and so, they do have a lot of shared knowledge but they don't have shared knowledge about what it is you just wrote and thinking about them almost as clients, like you want to do a handoff, like here's a nice package of information with a video and the document. I think that's a really interesting way of thinking about it and using that to sort of motivate more thorough documentation.

JAIME:  Yeah and documenting inside the code is necessary, especially when you're going back into someone else's code and enhancing it, really making sure that you clearly document: this is where I started, this is what I'm doing and this is where I ended. I think that those are really good but that's for the next person who's reading the code, far more so than the person who is evaluating the systems. You have to know your audience.

JAMEY:  I like to think about documentation as for my future self. It's kind of a selfish way to look at it but it does help me be more careful about it but I'm the most senior person, time-wise on my team by a lot, so I'm always getting questions about like, "Why was this written this way? What's going on with this? What does this do? What is this old code?" and I'm very often put in the situation where someone will say like, "Well, you wrote this," and I'm like, "Well, that doesn't mean I understand it," and they're like, "Well, you should."

When I think about writing documentation, I think about being put in those situations and when someone asked me in a year, what is this piece of code that I wrote do, do I want to be like, "I don't know," and sound like an idiot or do I want to be like, "Look, here it says. We can read it together."

JAIME:  Well and then that second one, that makes you look good too.

JAMEY:  That's true.

JAIME:  Just think about it selfishly. If someone comes to you, you could say, "Look, I documented this and you can see it right there." It's fun to be able to go back and say, "Oh, I was smart back then." That's the other thing I like about having documentation. When I go back into a project that I haven't worked on in a few months or even a few years because I have a couple of clients come back to me, I actually have one of those calls tomorrow as it happens, but being able to go back and say, "I kind of know what I'm doing. This is cool. I did a good job." It could be self-serving as well.

JAMEY:  I recently was going through some really old code in my codebase at work and I found a link in the documentation. I was like, "What's this?" So what happened is I had been writing something really complicated and I vaguely remember this happened about a year and a half ago and someone else has said, "Why are you doing this at that time?" and so I drew them like a stupid little chart, it was like a graph and I was like, "It does this, then it goes here and if it does this, then it goes there," and it was this crappy thing and I took a picture on my phone and send it to him on Slack and be like, "Do you understand it now?" and he's like, "Yes," and he literally linked to that Slack message directly in our documentation. I clicked that and it took me back to this crappy chart that I had drawn a year and a half ago, which is A, genius and I didn't think of it but B, I was like, "Oh, man, I would have made the chart look nicer if I had known if our future devs were going to read it."

JAIME:  How cool, though? we didn't have cell phones sitting on our desks that could take pictures that we could upload in the internet and post on a Slack channel. That didn't exist when I started coding. We're going to date myself now but it didn't exist and now, we have these many more tools. I think that's a brilliant way of extending the documentation needs inside your code is to have a link to the more thorough, more complicated document, the why of this piece of code. I think that that may need to be a new trend.

JOHN:  Yeah. I think the most important word in there is why, which is something that often gets left out of documentation. It's more of like a how or a what because it's like sort of when you're deep in the weeds, that's what you're thinking about. You're like, "What I do is this and I do this and do that," but taking that step back and talking about why you're doing it, why it ended up in the situation, why this is the best solution versus all the other solutions, that is incredibly important and I can take for one I tend to overlook it.

JAIME:  Yeah, I think we all do. My husband's a developer at a large corporation as well. He talks about some of the code that he's written years ago because he's been on the same team for a very long time and people come back to him and say, "Why was this written that way," and oftentimes, his answer is because that was the only real data source that we had or that was the only mechanism that we had to use so they had to jump through several hoops. But now, they could go back in and I understand the why this was done that way and there is a new better way of doing it, then you can go in and clean up the code too, so understanding why something was done, not just for what the goal of it was but more why that approach was taken versus any other approach is helpful.

JOHN:  Yes, certainly because then you know whether it's safe to rewrite it or not. You do know whether you're losing any weird assumptions that needed to be made at the time that you could safely remove because they're no longer necessary to make those accommodations versus I'd like to rewrite it as I don't stand it but then suddenly, you lose those weird edge case bits that were there.

JAMEY:  I'm afraid about that all the time.

JAIME:  Actually yesterday, I just wrote a case statement that was taking state names. I had pre-capitalized them so that I was just comparing the state name in capital form rather than worrying about case sensitivity and returning the state abbreviation. Then I'm like, "Wait a second. Somebody who is in Massachusetts might have put in their state as Mass and not as MA or as Massachusetts." I'm like, "That's a case that I don't have in here," and I'm like, "Uh-oh," so I've left it alone at that and then I've just written that if this arises, you've written yours as this. It needs to come into this format and so, I've kind of created it so that the user has to correct their data rather than creating every single one of those edge cases and all those obscure situations but it happens. It really does and understanding why you made the decision to post that message instead of putting anything else is also valuable.

JAMEY:  I like that story about Mass versus Massachusetts because it brings up this question I think about a lot, which is like to what extent should I be building things to accept what I predict someone might do versus to what extent should I try to teach my users to do it the right way and expect them to do it the right way. I feel like I struggle with that a lot because obviously, you want something to be as user friendly as possible but I don't think there's any way to predict what kind of weird things people are going to do.

JAIME:  Right, exactly. In my opinion, you want to code it to normalize as much as possible, so taking off any leading or trailing spaces before you do your eval. That's an easy thing to do. It makes it clean. Just like making it uppercase. That made it clean but if you think about it, nobody would actually write a letter and say 'Boston, Mass' then the zip code. That's not the way that we've been trained and so, I wouldn't code for something crazy like that.

I'm in Washington state. No one says 'Wash' and yet, people could abbreviate it to Wash instead of WA or Washington. I think that it's how to best hit the 80-20 rule -- 80% of the time, my code is going to give the right response based on the 80% of people's expected actions.

JOHN:  Yeah, I think that breaks down like that a lot. I know that as a coder, you want to balance like how many branches you have to build in your code to handle the edge cases versus this training [inaudible] that you can only use these two representations. But I also find myself as a user when those things aren't done where it's like you type in, something with the space at the end and it doesn't strip it off. You know like, "Urgh, it was one line of code. You could add in there."

JAIME:  I was just talking to a guy yesterday who was filling out a form or whatever and it was a website and instead of using radio buttons, they use check boxes and as soon as you checked one of them, they greyed out the other ones it was such an odd user experience. He and I were pondering and we're like, "What would be the reasoning for making a checkbox field and only be able to do one of them." Again, for the one side, you want to make it as flexible as possible but on the other side, let's make this make sense and logical as well.

JOHN:  If you're talking to a generic business owner of that's in your target size, what would you like them to understand about technology that would make your life easier or that would make them think bigger? How would you like them to think about technology that would take the most advantage of it and most of what you can give them?

JAIME:  That is such a great question. I like to have my clients think about what they want to create and who they're creating it for and not actually think about the technology all that much. I say you have to create your content and you have to cultivate your audience. How is your audience going to want to receive this content and I will make that happen? I don't necessarily have them think about understanding if it needs to be in a membership site or in a course or on YouTube or whatever it might be, I don't necessarily think about that so much as making sure that they understand that you can provide downloadable PDFs and you can provide audio files that are downloadable. You can provide videos that are streaming and really making it so that they understand what can come out the other side of the technology so that the engine works itself.

You and I or all of us, we know that technology can do a lot that most people don't have a clue about and I like to kind of make it so that they don't think of technology, kind of rolling back to technology is not a roadblock, just what do you want to do. If we determine that technology can do it, then we're going to do it but knowing what you want to do before figuring out how to do it is a much better approach than saying, "You need to understand how this system works and this system." You have to have to pick your technology before you figure out what you want to actually do. I think that's really where I like to take things.

JOHN:  All right. Cool. We're at the time of the show where we're going to do our reflections, which are just the ideas that have come to us as part of this discussion that really stand out or things that we're going to want to think about a little bit more. I think for me as really reinforcing something that's been happening like a lot this week is discussions about documentation. I was at DevOpsDays Boston earlier in the week and there was a lot of discussion about documentation there and then, on the show yesterday, we talked about it a whole bunch and now, we're talking about it here again. I think it's clearly something that is either in the forefront of my mind or should be at the forefront of my mind and thinking about ways to integrate it more closely into my processes and my team's processes.

JAMEY:  I guess for my reflection, I want to throw back way to the beginning of the show when we're talking about tech not being a roadblock and deciding what tech to use because I thought that was really practical advice from Jaime. I feel like becoming paralyzed by having so many choices. It's like a very real thing that happens to me about things like this and about other things in my life. I feel like when I'm presented with a couple options, I can handle that but when I'm presented with a lot of options in general, I just find that very overwhelming.

I particularly like what you said about getting a recommendation from somebody that you trust because I think that's such a natural thing that we all do without even thinking about how smart that is like the idea that's like, "Oh, somebody said this and now it's in my brain and it helps of that feeling of being overwhelmed," but I also think the advice of just freaking try one and do it rather than sitting here paralyzed by indecision is such a good advice and it works in this tech context but I think it also works in lots of contexts. When I start to feel myself becoming paralyzed by indecision, I think I'm going to start trying to say, "Just freaking pick one."

Jaime, do you have a reflection?

JAIME:  Yeah. I think for me, a reflection of this is that everything that we do in our businesses in isolation like that documentation, like I document in isolation. I don't necessarily think about who the end user is and I really, really loved that whole idea of why am I writing this code and why am I documenting it this way and why am I choosing this piece of technology over sitting there in paralysis mode. I think that why statement is really what I'm taking away most from this episode, in our conversation.

JAMEY:  I think this is a really great episode. I'm so happy that you came on the show. I really, really appreciate your time and your insight, so thank you.

JOHN:  Yeah.

JAIME:  It's been my pleasure. It's been fun.

JAMEY:  I want to thank all of our listeners so much for listening to our show and supporting us and letting us get all the way to 100 episodes, which is just a really exciting milestone for me. We don't plan on stopping anytime soon. We have a bunch of really exciting shows lined up, all the way into the New Year and I'm really pumped about it. If you enjoy our show, if you want to see it keep going, if you want to continue having great conversations like this, really consider pledging to us on Patreon. I believe our Patreon is Patreon.com/GreaterThanCode and if you pledge at any level, you'll get an invite into our Slack community, which is really amazing community of people and we have lots of conversations like this all the time. You can ask questions that we can ask to our guests and be part of our community. It's really great and we really appreciate all our patrons.