Tech Tidbits Ep. 9: Jana Olmstead

episode 09

Mastering Fundamentals: A Dive into Coding and Architecture

 

In Episode 9 of Tech Tidbits, Chris Tiegen and Jana Olmstead dive deep into the world of application architecture, unraveling the intricate puzzles and challenges they encounter while crafting digital solutions. Their discussions illuminate the multifaceted role of an application architect, showcasing the blend of creativity and problem-solving prowess required to navigate the ever-evolving landscape of digital development.

Chris: Hello, Jana. How are you today?

Jana: I’m good. How are you, Chris?

Chris: I’m doing pretty good. So this is Jana Olmsted. She’s an application architect and senior developer here at Creed Interactive. Thank you for taking the time today, Jana, to talk to us about your world here at Creed Interactive. Are you ready for some questions?

Jana: I am ready. All right.

Chris: So first up, as Creed’s application architect, what are your primary responsibilities?

Jana: I am involved very heavily in the discovery phase of new projects. I ask a lot of open-ended questions, and I listen for answers that are readily at the top of people’s heads and answers they don’t even know they’re giving me. So I am trying to make sure that we are setting every project up for long-term success by asking really vague questions and seeing what people come up with.

Chris: It talks about the discovery process, but you do a lot of stuff here. Right?

Jana: It’s true. As an application architect, that is my role. I also do a lot of coming up with ways for us to document what we do at Creed. So trying to make sure that we have a plan for how are we gonna organize our confluence space? Should that be in Confluence? Should we try to make this something that Creed does on a regular basis? But it is hard for me to attribute that to my role as an application architect that I would lean more on my role as a senior dev here at Creed.

Chris: Fair enough. I forgot about the differentiation there. That’s fair.

Jana: It is, it is a little tricky because I do have a dual role. Yeah, that’s true.

Chris: What are some of Creed’s strengths as an agency?

Jana: I think one of our biggest ones is that we’re collaborative. So we are a collaborative partner through and through. We actively contribute to and support our client’s corner of the tech domain while learning everything we can about their whole business. We don’t want to build anything that isn’t the right solution. And that involves actually getting to know who our clients are, what their goals are as a business, what their dreams and aspirations are, and then what their values are so that we can make sure that the valueless tech in intrinsically valueless tech that we build ends up adding to the value that every client brings to the entire marketplace in the us.

Chris: That’s a great answer. All right. You’ve been at Creed for 11 years in the time you’ve been exposed to a lot of different technologies. In your opinion, what makes a technology worthy of being considered for a project?

Jana: I think that a coding language should be proven and mature in wide usage. Because I think that relying on the entire tech community to be volunteering their eyes to issues that arise, kind of increases the chances that the language will continue to be supported and increases the chances that if there are any vulnerabilities, someone somewhere will catch it that is on the good side and, and fix it before it ends up being exploited. I don’t trust any singular person to know everything there is to know about a language, but when you have a hundred, a thousand, 10,000 developers or even more that are heavily invested in making sure that these open source languages, that frameworks that exist out there, that those are vetted, then it’s not just you. It’s a whole group of people that can be trusted with maintaining the technology.

Chris: Yeah. I gotta be honest, as a developer, I tend to get excited about new stuff and wanna just play with it right away. So that’s actually good to get a foundation there where we say, hold on, let’s make sure we’re doing it.

Jana: I have a tendency to be highly suspicious. That’s good. So we counteract each other.

Chris: That makes sense. Exactly. Yep. I’m the immature one here. All right. What are some of the top things to consider before embarking on building a new custom digital solution?

Jana: The first thing is what existing tools are out there that we could use to get a headstart. Trying to not reinvent the wheel unless you know that that wheel is that’s already supported is for sure not gonna work out. Sometimes there’s a little bit of a vetting process because people can come to technologies thinking it was a bad idea, and it turns out it was misconfigured and it’s built out in a way that wasn’t necessary and made it really, really, really complicated to maintain as an end user. So dealing with not just is there an existing tool that works, but are you already using that existing tool? But it was misconfigured and, and we need to just help support that. So that’s the first step. Do we have to go custom? Despite the fact that I love building from scratch, it helps to use the concrete blocks that were built by the concrete masons to build your foundation so that you can focus on, you know, some doorway, arches in your house and know that it’s not gonna fall down. So that’s kind of my philosophy there. And I always say it’s good to make sure you sit long enough with your problems to know what needs to be built. So thinking about your problem from as many angles as possible, from as many people’s point of view as possible, um, that increases your chances of actually custom building something that works. And honestly, this goes for all digital properties, even those that are just, just using someone else’s product and configuring it. What’s the plan for long-term support? Um, make sure you’re going into your custom or out of the box solution with a plan to keep up on technology because it advances at a lightning pace. And we can’t sit on websites for five years. It, we live in an era where that is just too slow. So just make sure you’ve got a plan to keep the technology up to date.

Chris: Good call. All right. Next question. What sorts of things can clients do to help get requirements lined up for the development success?

Jana: I think it’s really important to make sure that the right people get asked for input at the right time to make sure that their input makes the greatest, most successful impact. And some of that strategy, that question-asking strategy is part of what I do during the discovery process. I might have 20 questions that I need answered, and I know what those questions are at the beginning of the project, but I need to ask questions one, five, and seven before I can ask the next person questions two, three, and four with the right point of view so that we get the right answer. With the right point of view so that we get the right answer. So it’s really important that clients try their best to also wrap their heads around why they’re being asked a question, even if it seems unrelated. It is related. So just trust us. And sometimes it can be a little bit stressful and challenging to be vulnerable and not know all the answers, um, but it’s really important because we are here to build a solution for you and make sure that you are actually solving the problem that you have.

Chris: Exactly. I mean, it goes back to what you were saying earlier about the importance of understanding the problem fully, right? If we don’t understand what the problem is, it’s hard to solve it.

Jana: Yeah, exactly. So that’s where those, those open ended questions come in really handy is that sometimes we don’t know what we don’t know. And sometimes we don’t know what we’re asking, but it’s really important to get you to think about, um, your business from an angle that you haven’t thought about it from before. So that’s what those open-ended questions help to do. It’s my favorite part of the job.

Chris: That’s awesome. I’m excited to ask you about this next question. So a couple of years ago, Creed’s design and development teams began implementing atomic design principles. Could you explain a bit about what atomic design is and how it’s helped Creed’s process?

Jana: So atomic design is a design philosophy for your user interface, and it encourages you to think about your interface as a composition of distinct parts that we call atoms. And these atoms can be things like buttons, form elements, they could be text inputs, they could be headings, all those things. And then you’ve got your molecules, which are kind of your small, simple components that are made up of atoms. So you might have a label and an input field and you’d have the label be one molecule and the input field be another molecule. And then you’ve got organisms, which are made up of molecules and organisms are made up of the simple stuff that we’ve got, but it’s more, more complex. So we’re starting to think about layout. We’re starting to think about design patterns and the combinations of things. And then you’ve got your templates, which are starting to give you a look and feel for a page or a feature. And then you’ve got your pages, which are your content strategy applied to that template. Um, so it’s a way of breaking down your UI so that you can think about the simple parts and pieces. So you’re not trying to tackle an entire design in one go.

Chris: It’s like, it’s like building blocks, right? Yeah, you’re not trying to build the whole house at once. You’re building the walls and then putting the walls together.

Jana: Exactly. So it’s it’s taken a little bit of time for us to wrap our heads around because it’s a different way of thinking about it, but it’s absolutely been worth the investment. Because it has enabled us to have much more reusable code. Um, which has allowed us to scale our design system, which means that our design teams can move much more quickly than they would be able to if they had to go from design to development with every single feature. So it’s absolutely been worth the investment, but it has taken some time to get there.

Chris: I mean, that’s the case with everything, right? Especially with processes and methods like this. So, all right, next question. So Creed does a lot of really cool work with non-profits and social justice organizations. Can you talk a bit about the importance of social responsibility in technology?

Jana: Absolutely. It’s the belief of myself and the belief of Creed that technology can be and should be used to increase equity and to increase access to information. So we are actively involved in doing what we can to help further the missions of the organizations that we believe in that are working towards social change and social justice. I think that as technology professionals, we have the privilege and the responsibility of being gatekeepers to who gets access to technology. And so it’s important to me and I think to Creed as a whole, to make sure that we’re giving a voice to the voiceless and that we are making sure that the things that we’re building, we’re building ethically.

Chris: Absolutely. I mean, we see technology being used in all sorts of ways, and sometimes it’s not always for the best purposes. So it’s really great to see a company like Creed taking that initiative to use it for good.

Jana: Absolutely. So our biggest clients are nonprofits, and so that’s who we serve. And so we, we like to, to give back in the ways that we know how. And so, we are trying to be as ethical as we can be in every aspect of our business. So it’s not just in the tech that we’re building, but it’s also in how we conduct business and how we hire people. We want to make sure that we are doing our part to try to make the world a better place. It plays along into how we structure our agile workflow within the projects because you can be effectively agile as long as you keep that north star in mind. And defining that north star and the values that surround it can help developers on the ground week to week be able to make those in the moment decisions, um, on how to take the technology here or there. Because they can have that value set from discovery, and they can know the client’s goals just as much as the PM does, just as much as our sales person understood during the sales process. Um, translating that into technical goals is, is important.

Chris: All right. Next question. So you’re a big advocate for accessibility standards. So what accessibility, best practices and considerations should be made when developing a digital product?

Jana: Everything. No. I think it’s so important to be reminded that every effort you can make to follow an accessibility guideline helps I, it usually has to do something with visual contrast or information organization. It can sometimes be portrayed as if you’re doing it just for a certain, certain sliver of people in the world, but usually it ends up helping everyone that comes to your site. Mm-Hmm. For example, it’s really important for screen readers, which are in use by people who can’t actually see your site very well. The screen reader will read the site to them. It’s really important for those to have a really clear table of contents, which we should all remember from our high school essay days, um, defined for, for a page of content. And on the content writing side that looks like making sure there’s a title, a subtitle and more heading is to make sure that the content has a hierarchy. Um, is this information content that’s underneath the previous. So we, we take that heading down a size, um, down a number, bigger number technically ’cause it’s heading 1, 2, 3, 4 bigger the number, the less of a heading. It is on the development side. It translates into making sure that we’re properly using HT tags, um, to keep the content hierarchy that was created during a content writing session. And on the design side, it means trying to have a visual consistency where every heading level two looks the same to the person that’s perusing your site. And if all of those things happen, the result is a net decrease in cognitive effort required from people reading your site content. However, that happens either by site or with a screen reader. Everybody scans content, everybody, even the people using a screen reader, they scan the content, they’re perusing at lightning speed, your table of contents and putting the effort into accessibly organizing your content will increase the chances that your messaging is retained despite the fact that people are scanning your page. So that’s kinda like my biggest example of how while it comes in a set of standards that people typically associate with a small sliver of society, it just helps everyone if you go through the effort. And I get a lot of joy personally out of writing image descriptions for alt text, so it’s fun too.

Chris: All right. Next question. So I did a Google search for application architecture and this is what I got back. A good software architect helps define performance, quality, scalability, maintainability, manageability, and usability. The goal is to ensure that your software is flexible, extensible, and can evolve as new requirements emerge. So that being said, what sorts of things can be done to prepare for evolving requirements?

Jana: Yeah. Most requirements are shortsighted because it’s really, really hard to plan ahead for the unknown. It’s really cognitively difficult. So the best thing I can think we as developers can do is to assume this might need to be replaced suddenly. So how do I save my future self from having that change take a long time? A couple examples. When the requirement is, let’s add Google Analytics to that website, let’s assume that it’ll need to be switched out quickly down the road. So do your best to put that Google Analytics code into a single file in a database or a configuration file so that again, you’re saving your future self. When the requirement is the button on our promotional landing page, that one-off page we have should be green, use this new font, it’s gonna be awesome. Let’s assume that it will be used beyond that page. Utilize a pre-processor to store the hex code of the green, the name of the font in a single spot. Create a class that you can use if also known as when that button shows up elsewhere. And make sure that the CSS for the button is scoped well to avoid conflicts in the future. And when the requirement is we’ve got our data in an Oracle database, let’s assume that could change. So utilizing design patterns like the repository pattern query, abstraction technology, like link to place some code separation between the way the database is connected to and the queries that’ll run, it just makes everything so much easier if red when it has to switch out for lots of reasons outside of our control. Um, so yeah, that’s a lot. But basically save your s future self. Think, think about future you, And there you go. And keep yourself from going through a lot of pain and having to fix it later.

Chris: All right. Next question. So getting to know you over the last few years as I have, I hear working with you at Creed it’s become apparent to me that you have very highly evolved problem solving skills. So with that being said, how do you approach issues and bugs?

Jana: I immediately question what I know about a problem. I have a healthy distrust of the information being told to me. Is what I’m being told a best guess or a known fact? Is it possible I’m being told a conclusion rather than the facts? And then what are some common double checks that I can clarify before I dive in? I try my hardest to do not dive in with an assumption. So the bug happened at 9:15 AM on Tuesday. That could be somebody saying in their head, I usually get into the office around nine. I check the application right away. So I think it was around that time, or it could be, here’s a timestamp screenshot I took of the bug happening at nine 15. That difference can be the difference between a successful and an unsuccessful search of the logs to find out what really happened. Because maybe you can search between nine 10 and nine 16 and look at the logs. Maybe you need to be way more generous to be able to find that bug. I basically assume everything needs to be clarified and I find ways for the code to either verify or tell me that I was wrong about certain assumptions that I have in where, where the train got derailed in the code to cause the bug. And then I always try to keep in mind that sometimes clients will have weirdly shaped windows and things will just not look right for them in ways that we’d never tried. So I try to make sure that I am thinking about those things, like check what their screen resolution is. It’s not a crazy thing to double-check. And maybe this is just some weird artifact of their browser combined with a weird setting on their computer. So, yeah, that’s how I approach bugs. I assume everything’s wrong. And then I just go about trying to verify or deny. All of those assumptions.

Chris: That’s awesome. That’s all the questions I had today, Jana. Thank you so much for taking the time to sit down and chat with me.

Jana: Absolutely. I appreciate the conversation. Thank you so much for having me.