From Webmaster to Software Developer in the Age of AI

Joel: Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron: And this is Aaron.

Aaron: I remember years ago, the term that we used to use for ourselves was web developer, and you know-

Joel: Not webmaster?

Aaron: Oh, well, webmaster. Yeah, that too. But after webmaster, then it was web developer. And I remember going through that part of my career, going like,

"This doesn't feel exactly like me." Because I can do web development like this guy or gal over here, but I also can do technical stuff.

I can really think, I can launch my stack, all that kind of stuff. And at that time, when you talked to web developers, they're like, "Yeah, I don't know.

I use, you know, GoDaddy hosting," or something. Like, they had no idea. They web developed, maybe, their WordPress site together and go out, you know.

No, you know, no judgment, just that wasn't me. And so, I'm like, "Well, I'm not a web developer. I'm not a developer. I'm a programmer."

Joel: Mm-hmm (affirmative).

Aaron: Makes sense, right? Like, because it feels like a more technical term than developer.

Joel: Well, and is it even like web developer versus programmer? Like, "I can do like console apps and stuff too," or?

Aaron: Sure, yeah. Especially throughout our career, you know, we've done different types of development, built different apps. Even like with the Laravel stuff,

we can do console apps really easily with that. You know, it's sort of web but sort of programming, and now it's just all it seems all programming.

And so, I started calling myself a programmer. Or every once in a while, a web programmer if it was someone who didn't know what programmer meant, you know?

So, I would say, "Oh, you know, programming on the web." I thought that was interesting. And then, of course, the world is shifting again, and now I'm trying to think

of a new term maybe, or an old term, to describe what I do. And there is a term that people have been using when it comes to AI that I absolutely do not do and completely disagree with.

Joel: Okay.

Aaron: You know what that term is?

Joel: Vibe coder?

Aaron: Yeah.

Joel: Okay. Because there's a couple I can think of, but that's the one that came to my interest.

Aaron: Yeah, you know, vibe programming or vibe coder, or something like that. I mean, first of all, maybe because I'm an old man, what's vibe?

But no, it just felt like someone taking the thing that I was good at, programming or coding, and then joking about it and saying,

"Well, there's another tool that can do it with no thought whatsoever, and I just go on vibes and does everything you do." So, I don't know about you,

but I took that not offensively, but a little bit of a like a dig, you know? It's just like a little bit of a pain, I guess. Like, "But you're not coding,

you're not programming." Follow what I'm saying?

Joel: I think so. Like, it's interesting to me too that some people actually adopt the term vibe coder as like a good thing. And others like,

"Oh." Like, if you call somebody a vibe coder, it's almost an insult. But like you're going a step further, and like the existence of somebody either

being called or calling themselves a vibe coder maybe influences how you think about your own work.

Aaron: You know, in a way, yeah. Because that term just kind of felt like maybe the next iteration of software development but not the right one, right?

Joel: Yeah.

Aaron: And so, I'm trying to think of a thing to equate it to that a lot of listeners might realize. So, it's like maybe the idea of using a huge, giant PHP package,

which we've talked about before, for just one single feature. And so, the vibe is, "I know there's a package out there to solve this, so I'll just install this."

And it installs 27 other things, but it solves my one problem. That's the vibe, that's just what I feel, and it solves the issue. But the coder, the programmer side,

is like, well, it's only one small feature. Technically, it's seven lines, and I'm not going to reinvent the wheel,

but I can write that because it is in the coding language. And I know I don't need to bring in all this other stuff.

Joel: Yeah. Would you say the differentiation there, like, looking for parallels to the comparison you're making, is caring more about the

internals than only caring about the end result?

Aaron: I would say that's a great question, and I think that's the way that people are phrasing it. But that's not the question.

Joel: Okay.

Aaron: I care about the internals as much as I've always cared about the internals. There was a time in my career where I was more interested

in the code than the outcome. I think a lot of developers maybe went through that process where you start making stuff super complicated just because

you're learning and all that kind of stuff. So, to me, when you say care about the internals, that's what that sounds like to me.

I care about the end result, but I care about the end result not today. I care about the end result tomorrow and next month and next year

and five years from now, if possible. And I think that's the difference.

Joel: So, kind of like short-term end result versus long-term end result?

Aaron: Right. And in order to guarantee a long-term end result, it's like everything else in the world, programming or otherwise, where you need a little

bit more thought up front, a little bit more planning up front. And you need to watch the process too, because the end result isn't necessarily what's great.

You might go to a kitchen, and then they serve you a burger in four minutes, but the whole kitchen is messy and destroyed, and you can't get

another second burger out the door. Well, that's a problem. You just vibed me a hamburger. Yes, it was done,

but where's my second hamburger if I ever need one? Going to take 27 minutes now.

Joel: Two hamburgers. Okay. Yeah, I like that. And I totally get what you were saying. And in my head, I was not framing it that way, but I've heard that,

like, the person who just cares so much about the craft and the satisfaction it brings them is like completely blind to the outside world.

Whether it's terms of stakeholders or business value or anything, like being able to ship anything. So, I wasn't framing it that way,

but I have heard some people kind of like look down on people that care about the code as if that's what they care about.

Aaron: Right. Well, and it's not that you don't care about the code. It's just it's one of many things that you care about, and one of many

things you balance out. And so, when I started thinking about that again, it sort of backed me up a little bit. Backed me up in the chain or the business cycle,

I don't know how to explain. But where I'm like, you know, I'm not coding as much anymore. I do care about that stuff, but since I am working with

AI tooling and stuff like that, I'm spending a little bit more time in my business analyst brain. Because I have to think these things through

and make sure that what they automatically come up with, the AI tools, isn't wrong. So before, I used to make the thing and think about the

thing at the same time, sort of. And so, as I'm typing it out, I also know if it's wrong in a way, you know?

Joel: Yeah.

Aaron: You kind of know if you're doing something wrong because it's not working. Whereas with the AI tooling, it either is wrong or right, and it does it,

and then you look at it. And so, I was like, "Well, I'm not really programming, but I still look at everything." I still care because I

know that the long-term building blocks means long-term success. And so, what is that term for what I'm doing? Everything's a cycle, man.

I think I'm going back to being a developer because I still understand intensely, in detail, the things that are being made,

but I don't necessarily need to because I've developed enough experience over the years to be able to assess them.

But I still look at them. But now I'm taking pieces of work that other junior developers/AI tools have done and develop them together into something that's holistic.

Joel: Yeah. It doesn't strike me wrong, but it does definitely fit in with the cyclical nature of technology for sure. What's old is new.

Aaron: Yeah. So I think it's like, you know, I used to be a web developer, then I became a software programmer, and now I think the term is software developer.

And that's the thing. You know, it's software and solution development that is what our job is now, because a lot of the technical parts are

being abstracted further and further. And we've done that throughout this whole career, you know, throughout the whole iteration of stuff.

You just have to do basic code, you have to do assembly, and it's abstracted to nicer and nicer types of code, nicer and nicer.

So, this is just the next abstraction. What I'm excited about, though, is that I actually get to do some of the cool stuff,

the fun stuff that I enjoyed along with programming more. You know what I mean?

Joel: Like what?

Aaron: Well, like the sort of thinking about the process and the project.

Joel: Yeah.

Aaron: The taking a look at stuff, being able to finally do all the things I know are best practice because I have some tools that can save me some time.

Joel: Right.

Aaron: Because that was also the thing too. Is like, there's a bunch of best practice stuff, but we're balancing the business needs.

So, I can do less of the good stuff because I know you still need to get it out the door. Whereas with the AI tooling and all this stuff,

and being now a software developer, looking at the stuff holistically, stepping back a level and having my AI minions sort of work on some of

the very small details while I put together the larger ones. While still paying attention to every single thing.

Joel: Oh, sure, yeah.

Aaron: That's what's exciting now, and that's kind of what I'm doing next and what I'm working on.

Joel: Yeah. Well, that is interesting. Like, the example, maybe this doesn't fit with what you're thinking. But the example that popped in my mind is like

when you develop an application long enough, and you realize like this core word you are using isn't the right word anymore, and you're like,

"Oh, it's everywhere, though. Like, I'm going to have to do all..." But now, you could just like, "Hey, where are all the places that this

word changes from A to B? What are all the impacts?" Like, all the labels, all the tables. And like that you might just suffered with it in

the past and now it's like, "Oh, I can have the robot go crank on it, and then I don't have to deal with it anymore." But, yeah, I like that

because that is a fun part of the project too. It's not just like, "Oh, I get to be in my ID writing code." There was definitely a time where

that was exciting, but like the business side of it and the higher-level thinking and kind of like leveraging up your own skill and taste in things,

I think is a great skill to have too. So, with this realization, Aaron. You know, because naming things is important and it sort of helps

shape things in your mind. Like, I can sense a little bit of excitement or optimism even, you know, maybe for what the future holds.

Like, how do you think that'll shape your work? Having this understanding of your role and maybe even the label to assign to it?

Aaron: Yeah, I think optimism is a good word. It's just a bunch of change too. You know, it's going to be difficult and interesting to look at.

Because one of the things you challenge or you question yourself is like, "I've built up all these skills. Are they still worthwhile now if

AI tooling is doing it?" I think a lot of people are saying no. I'm saying they are still worthwhile because those tools are coding something,

and you need to be able to review them and make sure it's still something that makes sense. But it changes, and it doesn't change the way I

approach my work, right? So I've always approached work and saying, like, "Okay, before I get started, I need to understand what the problem is,

what people might have tried before, what you think the solution is, and then let me come up with a solution," you know? And then I'll try to assess

that against all these different things. And then so there's a little bit of planning, there's a little bit of then, you know, getting into the

weeds and involvement, saying like, "Here's sort of some mockups, here's some thoughts, here's how we're going to solve that." And then doing the work,

coding it, all that kind of stuff. Writing unit tests, looking at it in the browser, accepting it, documenting it, and then throwing it all off to the stakeholder.

That's a normal process. I don't think much of that is really going to change, it just changes the way I do it. So, for example, all those processes still happen.

They just happen a little bit more compressed and possibly a little bit better. So, while I have an AI agent maybe doing some code for a small block,

I can then start documenting what that feature is in human words because I don't use AI to do that documentation because it would just be copying itself.

But in human words, and then I can use that also as another test against the code with maybe another AI model or myself, my own brain, and say,

"Is this what that was doing?" you know? And so, I'm still making sure the code is accurate, I'm still making sure the product is done,

it's done in the way it is. But some of those things are getting compressed. But like I said, what's nice about that then is, other times when

I'm looking at my unit tests, which are the things that make sure the code hasn't broken in the past or in the future, I will write 80% of those or whatever.

But I need to get the project out the door. Right now, I can get close to 90-95% because I can have that tooling work on that as well. So, it does change stuff,

it allows us to do more things. The nicer thing too is one of the skills you might have ran into with me is like I can look at a design and tell you if it's

not great or what user experience needs to be done better, but I can't necessarily do that next step. And so being able to describe those things to an

automated agent will not replace the designer, but it gets me to a place where I can get a better wireframe out the door to show the client that I

think this is what you're asking me to build, saving time and money ahead of time. So, I'm pretty excited about some of these things. I'm a little sad,

to be honest on other things, or I'm losing some of the attachment to a craft that I'd built 20 some years, but I'm pretty excited too because I

think any client I end up working with is going to get even more value out now. And I'm excited to see some of the cool stuff that I'm going to do.

Joel: Aaron, I really liked the views you shared today. I thought it was a nice, hopeful view for our craft.

Aaron: Oh, thank you.

Joel: If people wanted to find out more, or maybe even work with you and get some of that in their own company, where should they go?

Aaron: Well, I'm still kind of spinning up a little bit more of my social media. But in the meantime, you can go to morebetterfaster.io and click on 'Book a call with me'.