Re:Role | The Web Developer And The Presence

  |  Compiler Team  
Sviluppo e distribuzione delle applicazioni
Sviluppo professionale

Compiler • • The Web Developer And The Presence | Compiler: Re:Role

The Web Developer And The Presence | Compiler: Re:Role

About the episode

Web development has changed a lot over the years. And for startups, it’s a necessity, at least for marketing and securing capital. But digital strategy and product strategy don’t have to be separate. They can be considered as two parts of a company’s approach to growth.

The company, its business activities and its employees depicted in this podcast are fictional and are not intended to represent or depict any current or former business organization or any individuals living or dead. Any resemblance to any individual or organization is purely coincidental.

Compiler team Red Hat original show

Iscriviti

Subscribe here:

Listen on Apple Podcasts Listen on Spotify Subscribe via RSS Feed

Trascrizione

We're back, everyone. Let's check in on our team. After the initial launch of the app the team is riding high. The product manager is bringing in customer feedback and refining things in a well-thought-out loop. Some of that customer feedback though surrounds the company's website. The app is great, but these particular users want to log in to their accounts via a web browser. To check on their benefits, rewards, progress on their goals, et cetera. And since personal identifying information will be displayed, this authenticated experience must be built with things like information security and data privacy in mind. Sounds like a good case for hiring a lead web developer if you ask me. But there is some hesitance. Is there another way to get this done? Could an outside agency be a better choice? And what does their product strategy have to do with having a website? Is it necessary at the moment? Let's think all of these things through together. This is Compiler, an original podcast from Red Hat. I'm Johan Philippine. I'm Angela Andrews. And I'm Kim Huang. We're following a fictional startup as they grow their business. As things move along, our hypothetical team realizes it needs to fill new roles. We're calling the series Re:Role. Remember, any resemblance to real companies is purely coincidental and unintentional. Today's episode: The Developer. If you'd like to listen from the start of the series, check out our episode on the CTO. Producer Kim Huang is here with our story. We talk a lot about developers at Red Hat. We really do. Yeah, we do. And usually it's in the vein of software development. But for today's episode we're going to explore web development, more specifically the progression of web development for business through the lens of different experiences. Someone I talked to about web development is Jeff Byer, and I spoke with him about how he got started. The web was just starting when I was in college, and I read a pamphlet on how to write HTML. And that's where it all started for me. And I met my future business partner at college and we would converse. And right after college we started our own agency; a website company, basically, that we had for two years and didn't really go all that well. It wasn't enough to sustain a livelihood, but that's where it started. And I knew I wanted to work for myself, but this wasn't sustainable. We were getting small requests, people who basically just wanted to be online, but it was basically putting their business card online, something like that. And then we started getting larger requests, but we didn't know what to charge and how to charge them. Not only did we not know what to charge, people didn't know what to expect to pay. We were just learning as we went. This was the beginning of the age of .com, which gave rise to the web developer. But what did web development look like back then? After all, there were very few tools, no applications, no libraries, no frameworks. It was like this new frontier. Jeff talks about what web development looked like for him. It looked like a bunch of frames and texts going across the screen. It was not a pretty sight back then. But it was fun. It was, what a time. At the time I was writing raw HTML into Microsoft Notepad and publishing it through a command line based FTP to a free server that I got through my EarthLink account. I was reading all about how to do this and how to do that. And so doing everything in the command line was the way that I initially learned. Oh, he took me way back. No pun intended. Yes. I have very fond memories of doing raw HTML myself and not so fond memories of dealing with my FTP server. Things have changed though. Oh, yes. It's changed. Web development has made a come up. Yes. Web development back then was basically a lot of different styles, very little uniformity, very little in the way of uniform user experience. Remember the cursor is that instead of a regular just arrow, it was a magic wand with the little sparkles on it. Or you'd have a tail following your cursor along the screen or the... Unicorn tail. Yeah. Those were the good old days. You had the midis that would come on auto play. Whenever you got onto someone's website it was a very loud, obnoxious sound of someone's favorite song, but in midi form. We never liked that, to be honest. We never liked that, unless it was ours and then it was fine. Exactly. Also frames. I just have to talk for a second about frames, because I mentioned it to Jeff and we started talking about frames. It was so funny. Oh, I was all over the frames. I had frames everywhere. Frames and animated GIFs all over the place. Yeah. He's speaking to me. Yes, speaking directly to all of us. I remember when I figured out how to put an animated GIF at the top of my page as a banner. It was just so many huge moments for me because I was learning all this stuff, kind of just like Jeff. As I went in my bedroom, and it was so much fun, and it was ugly. Don't get me wrong. Oh my goodness, I think- But it was everywhere, right? It was everywhere. It was everyone, right? This was the industry back then. This was what it was like to surf the web, and it's basically everyone just kind of figuring it out all over the place. That's right. How did we ever find anything? How did we ever get to where we are today? I don't understand. Oh, remember guest books and site counters to see how many people had come to your site. Yes. Site counters were the wave. Just to know that people saw your website, and when you would go and check it out, and that number ticked up a few, you're like, I've made it. I've definitely made it. Right. Now, how did Jeff do? Because from what he was saying originally doesn't sound like after two years he was doing so great in this brand new field. Yeah, yeah. Jeff had actually left web development to work at a company that manufacturers and sells uniforms. But it wasn't very long before he got pulled back into what he loved. My old business partner said, "Hey, I'm here working at Sony. We need some help with some TV and movie properties. Can you come in and check it out?" And I said, "Sure." And I went in. I did a sample project for them. And in Flash, by the way. He got an offer that was significantly lower than what he was making at his current job, but he took it anyway. I love web development. I love everything about the internet, and I knew that that was going to be my career. I didn't want to fool myself into thinking that I was going to be selling uniforms for the rest of my life. Hey, that's a big gamble to make, right? It is. Yeah. You've tried it once for a couple years and it didn't really work out. Everyone's kind of trying to figure out what this thing is going to be, if it's going to be something. And he's got a stable job and he's pulled back into doing this again. And what's more, he's not just doing it from himself anymore, he's doing it for Sony as in, of Sony fame. That's Sony. Yes. He didn't give up on his dream. He believed that this was the way that the world was going, and he was okay with that. He was going to ride it out. And you know what? Sometimes you do have to follow your dream, even if it doesn't seem fruitful at the moment, if that's where you know want to be, you have to follow that and see where it takes you. Definitely. I want to want to level set, because what I want to do for all of the would be web developers or junior web developers that are listening, I want to illustrate the environment that Jeff was working in back then as a web developer. If anything that's expanded. It's just everything that the developer has access to now is doing several of those tasks that used to be mundane. Actually writing HTML by hand is no longer necessary. Because you start with any of today's tools. No matter what you're doing, it's going to do that for you. Ask any developer today if they had ever had to actually type "open bracket, HTML, close bracket," and none of them do, because every single tool you use today is doing that for you at some point. This is a time before things like Dreamweaver that came along and revolutionized the way that we do web development. Wow. We talked about, well, why a website? The app works great. What do you need a website for? And can we all agree that almost every tool, every business, every person, if you're putting some sort of content out, you really do need a website. You really need a place for someone to land, to learn about you and what you do and who you are. And I think our little startup is no different. I mean, my dog has a website, right? Wow. Everybody has a website. We're talking about how far we've come with tooling, how far we've come with standards, web standards, UX, progress is good. There's no more writing close brackets in a notes app. Things are more centralized. They have more uniformity. And we talk about that a lot in season seven of Command Line Heroes if you want to check that out. But as we've said before on Compiler, even though you have sophisticated tools to use, it's always important to know the fundamentals. Templates are specifically built to be as everything is possible to everyone. And when you're dealing with a specific client that needs something specific done to it, that's when you have to really dig in the code. Because there's no way that even with the WYSIWYGs that are available today, even that there's going to be a request that's just not going to be able to be done without actually writing code. WYSIWYG means what you see is what you get. It's an acronym that came along when applications started presenting the ability to see what you're doing as you're doing it. In web development specifically you can actually create websites in an interface that actually shows you not code, but what your actual website is going to look like when you hit publish. This is talking about WordPress and all these other very popular apps and very popular services that are being provided today. But before that, it really was, you really were living on a prayer. It was put it together and hope it compiles. I hope it's right. I hope you didn't miss a tag. Fingers crossed. Exactly. I told Jeff about the startup that we are following throughout the season. And their dilemma, and he had some thoughts. They built the app or whatever it is, and then the CEO says, "Oh, we don't need to hire anybody to do the website." And it's a specific set of skills to get the UX right and to get the interface right. And so as talented as the backend developer can be creating the app, the front end is a different story. Some startups need to get an MVP, right? A minimum viable product out the door. And if it's just telling people about the app, what's the harm in a low fidelity website? Well, none. But websites today look very different than Jeff Byer's internet. And what the team at the top of the episode needs is a little bit more sophisticated. And different times call for different approaches. We're going to talk about that next. We can all remember Amazon. From back in 2000 and, I don't know, eight, seven. It was how we did things. It was frames, it was boxes. It was very clunky. But it was the internet. Everything was new. And we just looked at it and said, "Wow, this is a great website. We can buy stuff on it." Was it the most appealing website? Not by today's standards. Not at all. But we had to start somewhere. And I'm kind of proud of the evolution. Websites were very clunky and folks had to use what was available to get those things up. And it takes a specific, like Jeff said, a specific set of skills, in order to get the job done, in order to make an experience that translates into something that is understandable or discernible for everyday consumers. I wanted to talk more about that, but first I'll introduce our second guest. This is Alvin Bryan. He's a developer advocate at Contentful, and he's based in the UK. And he introduced something to me that I think is very relevant to our conversation. Are you familiar with Metcalfe's law? It's basically, the simplification is again, the more people there are in the network, the more the connections in that network increase. There's simple logic there, but it's basically that. It's on one hand there's just, the more people they are, the harder it is to communicate with everyone because there are more ways to communicate. Okay. My favorite way of describing this is an example I've used before. Have you all heard of the game Telephone? Have I? Yes, yes. This is something that I feel a lot of teams that I talk to that work in tech use this to kind of demonstrate the fidelity of content or the fidelity of a message traveling over a longer distance. The longer the distance is, the quality kind of depreciates in that message. Say for example, you have a bunch of people lined up next to each other and you give one person a phrase, any phrase. By the time it gets to the other side, because they're going side by side, kind of whispering it one person to another, passing the message down. By the time it gets to the end, the person says what the message was out loud. And sometimes it can be completely different than what the person said in the beginning. Because of that exact thing that Alvin was talking about. The more people that are involved in communication, the harder it is to communicate. Because there's more kind of cooks in the kitchen, if that makes sense. On the other hand, it's also because in smaller companies it's easier to reach out to everyone because everyone does everything. And if I need to make a change to the product, it's easier to say, "Hey, Matt, can you make this quick fix because I got this customer who's wondering about this." And the answer could be, "Yeah, for sure. It'll take me five minutes, or I don't have time, but I can show you how to do it in about five minutes." And I'm like, "Yeah, sure, I'll fix it." Whereas now I have to go through a product manager to make sure there's space in the backlog and everything. It depends, it doesn't mean things don't get fixed. It just means it's a different process. I mentioned Jeff's work with Sony. That project turned out to be much larger and far reaching than he first thought it would be. They decided to start a social media site that was going to promote Sony Pictures, television properties, Sony Pictures properties, which included Columbia TriStar, and they wanted to mix it in with Sony corporate, Sony Electronics, and encourage people using the electronics to integrate with the media and have this whole Sony centric social media platform. And that part interested me. And I moved over to that. And we created a social media and content publishing platform, and we made it out of Flash. Which was the first time anybody had ever done that. Me and four of my other coworkers are actually co-authors of four different patents for creating this system. I just want to say, a social media platform created in Flash. I'm just going to say that real quick. Times have changed, Kim. Oh, wow. But hats off to him though, because if it worked, that is a huge accomplishment. Jeff's work was revolutionary at the time, and the complexity of it speaks for itself. But here's the big picture. What he's talking about is a digital strategy and a product strategy, that was transforming their business. They were trying to make a digital experience that would transform their business. They weren't just putting up a billboard, they weren't just putting up their business card. It was a lot different than anything else that Jeff had worked on. And it's a lot different from just saying that you need a website. At the top of the episode, the team is making a website for a very specific reason. For a very specific type of user that is digital strategy, that is informed by product strategy. That's an overall business framework that is going to transform their business. If the team is deciding between an outside firm for their web presence or delegating that work to one of their software developers they've hired. Those two things... it wouldn't be a giant leap for someone who has multiple skill sets. (19:26): Someone internally who already works at the startup could possibly do that. But I want to take a second and open it up for discussion. Let's think about all the things that this website needs to do. So for starters, it has to highlight the app. It should have a way of getting support or contacting someone about the application. If you want to find out more about the company, it should definitely have company information. To find out if they're hiring, where they're located, all the information. When you go to a site, you want a phone number, you want an address, you want to know where it is. If it's in your town, you want to know who do I contact if I have a problem? These are the things I think about off the top of my head that they're so critical. It almost doesn't matter what the service is you're providing. Let me ask you, Angela. If I wanted to make a website that would to require login for a person to enter their information, their login name, their password, and then get an authenticated experience that is tailored to whatever account they might have, what all goes into that just off the top of your head? Wow, there's a lot. You have to be able to have a way to authenticate and authorize. Where are these users coming from? How are you collecting these users? How are you keeping these users' credentials safe? Can people create their own accounts or their accounts created in advance? It has to be an authentication mechanism. There has to be some sort of database where you're keeping this information. It has to be encrypted. There has to be some sort of mechanism that if someone's password needs to be reset, how do we do that? How do we know that who's logging in is who they say they are? And how do we know once that person has logged in, they only have access to what they've been given access to. They don't have run of the website or the run of the information. How do we make sure that people stay in their little silos when they do access this information? And that's just the tip of the iceberg. Very much so. There is all kinds of things with conditional logic or seeing certain things that other users won't see, or maybe even different APIs. How would different APIs come in. And say, if you're logging in, this is a tech startup in finance. If you're logging in to look at your account, but then you have maybe, I don't know, frequent flyer miles or rewards programs, that's another API. Isn't that something else that needs to plug into the backend of that authenticate experience? That is correct. Depending on what my account gives me access to, or what services I have access to inside of this account, I should be able to access it very easily, very readily. You want your experience to be fulfilling. If you go to a website, you want what you want when you want it. All of those things have to be given a lot of consideration. How is that integration happening? How am I able to see this part of the information and that part of the information. There's a lot of moving parts, but there's a lot of integration that has to happen. And developers have to be aware. How do we put all the pieces together so folks can have the experience that they deserve when they come to our site? Now, I imagine that because we're integrating with other businesses, other financial institutions, that's a whole other layer of complexity and security that needs to be taken into account when building these websites as well. And that's authentication happening on their end as well. If you have vendors and companies that you work with and share that information to provide for your customers, how do you make sure that information is accessed properly? Again, that's all I can say. Yes, everyone should have a website, but depending on the complexity of what your website is trying to provide for its end users. You need to take all of that into account. And it's a lot of moving parts. Again, up and down as we do Re:Role, were finding out about all these important roles that play a part in this startup. There are roles we haven't even talked about yet. Yes. That are going to have something to do with making sure this website provides all of its customers with the experience that they're expecting. Not just web developers. Yes. And to wrap all of this up from the point of view of our team at the top of the episode in this situation, this is digital strategy and product strategy together. It's not just one or the other. These two are deeply intertwined. And that is something that a skilled and focused web developer can deliver and iterate upon. It's difficult for a person who may already have their own set of tasks or responsibilities or job duties to kind of take this on as another task on their board. It's not just another task. It is something that is much larger in its scope. And it's not 1995 anymore. People have expectations of what an experience on a website should be. They are expecting more than just a billboard. They're expecting the very complexity that Angela was talking about. And not meeting those expectations can be pretty dangerous for a company's outlook. (25:14): In the beginning the worldwide web was this new fancy thing and companies were aiming to create a digital presence at a time where it wasn't clear what that even meant for their business. Angela, you were talking about this earlier. What is a website for? What did it even mean at a time before e-commerce and you could buy things online. But that's all changed now. Companies understand the new tools and the technologies, and they understand the stakes. So I spoke to Andy Vitale, you might remember him from the designer episode. He said something to me that I thought was really vital for developers to remember. The worst quality product that you put into the world, it damages the brand. If we think about when you put something out there, that first interaction somebody has with it, they're going to notice how something looks and how it feels, more so than what goes on behind the scenes. I mean, great design goes unnoticed, but if something's designed poorly or looks poorly, people lose trust in that. And Jeff agrees with words he specifically has for companies looking at industry position and funding. Like our startup. Their catalyst would be when they're ready to introduce themselves to the public, if they've got anybody looking to invest in them they'll need a presence for investors to go read all the information about them. And not only read the information, but know that they care about marketing. And that their public image is valuable to them. I think that's what a website says a lot. You know, because you will be judged as a startup by your website. These days, it's unavoidable. All right, so what do we think? Well, they need a web developer ASAP. Yes. There is no way getting around a startup without having a web developer, whose total focus is on that online presence and how their company is presented to the world. That's a huge undertaking, and it's definitely a role that can't be taken for granted. It's up there. It's important. The sooner they get that, the better off they'll be. We started out with the internet being kind of the wild west, right? Websites are flashy- Pew, pew. Frames everywhere. They're kind of goofy, they're kind of silly. Some companies are on there using them as billboards and essentially as ads. There's something to look at, but eventually you go somewhere else to do whatever it is that business wants you to do. Eventually we get to the point where we are today where websites are so much more than that. And they're not a vehicle for you to get from eyes to do something else. They are the focus of the business. And that's what's true for our startup as well is that you go to the website to do the thing to whatever it is, to log into your financial institutions to buy the product. And that role of the web developer has become so much more important. Because if you don't have a web developer, your website isn't going to be as good as it's going to be. And if that's the center of your business, then you're going to be in a lot of trouble. For startups that are looking to stay very lean, like the one that we're talking about in our opening. Fewer people... it does mean smaller circles of communication, which is fine, for a time. If operations need to scale up, for example. Say that there are customers are looking for more features and they want more things: those circles need to scale too. And that goes for the different tools and technologies necessary to meet customer demands, and be competitive with other companies. Now, going back to web development itself. It took companies a long time to figure out what the digital experience or online presence was going to be for their business, and what it really meant. Smaller teams should as soon as possible solidify a strategy to define what their digital presence looks like. And how that translates into their product strategy. And a web developer is an essential part of that plan. There is really only one chance to make a first impression. Make it a good one. That's what your customers remember. I mean, this is such an essential role and I'm glad that we're having this conversation about it. Because even the small teams, they have to figure this out. Any company. I'm really glad we had this. We had this little jaunt down memory lane as to how it used to be. And how it is today. Some of us were there for the beginning and it wasn't always as nice as it is right now. We can really appreciate the growth. I hope you enjoyed this episode just as much as I did. We learned a lot. We went down memory lane, and we want to know what you think of this episode. Make sure you tweet us at Red Hat. Use that hashtag: #CompilerPodcast. And if you're being extra adventurous, why don't you show us some links to your old websites? We would love to see some of those. Let's do it. Show me some cursors moving across the screen. Show me frames, frames, frames, everywhere. We could all use a laugh. Thank you. And that does it for this episode of Compiler: Re:Role. Today's episode was produced by Kim Huang, Caroline Creaghead, and Johan Philippine. Thank you to our guests, Jeff Byer, Alvin Bryan and Andy Vitale. Victoria Lawton has all the animated GIFs and flash videos you could ever want. Just hit her up. Our audio engineer is Christian Prohom. Special thanks to Shawn Cole. Our theme song was composed by Mary Ancheta. Our audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Brent Simoneaux, Nick Burns, Aaron Williamson, Karen King, Jared Oats, Rachel Ertel, Devin Pope, Matias Foundez, Mike Compton, Ocean Matthews, and Alex Traboulsi. If you like today's episode, please follow the show. Rate the show, tell your friends, tell your family, tell everyone. It really helps us grow. We love that you listen and you keep tuning in and sharing your stories. Until next time, thanks for listening.

More about professional development

Keeping up with changes in technology requires training and and engagement with learning opportunities—either in a traditional setting, or individually.

Articolo del blog

Single-instance Oracle Database on OpenShift Virtualization

31 luglio 2025  |  Mikhail Mikhailitchenko

...

Cloud automation

Articolo del blog

Friday Five — August 1, 2025 | Red Hat

1 agosto 2025  |  Red Hat Corporate Communications

...

Cloud automation

About the show

Compiler

Do you want to stay on top of tech, but find you’re short on time? Compiler presents perspectives, topics, and insights from the industry—free from jargon and judgment. We want to discover where technology is headed beyond the headlines, and create a place for new IT professionals to learn, grow, and thrive. If you are enjoying the show, let us know, and use #CompilerPodcast to share our episodes.