“Developers won’t write features and fix bugs but shift to DevOps and SRE because of AI”

Forrest Knight‘s journey didn’t begin with aspirations of becoming a software engineer. Originally, he aimed to follow in the footsteps of his family into a blue-collar career after high school.

Yet, life had a surprise in store for him, and he stumbled into the world of computer programming.

Years down the road, Forrest has become a FullStack engineer and a full-time content creator on YouTube, boasting a dedicated following of over half a million subscribers. In this interview, he shares some of the insights into his craft of development, unveiling the secrets behind his successful journey.

How to choose the right tech stack?

Your proficiency in full-stack engineering spans Java, Spring Boot, Gradle, TypeScript, and Angular. How do you approach selecting the right technology stack for a given project, and do you have any favorite combinations?

Forrest: That proficiency mostly comes from my time at Prime 3 Software, building upon my Java skills learned during my CS degree. And luckily for me, I didn’t have to decide on a stack for that project – it was already underway.

But when I do have to pick a tech stack for a project, I’ll figure out the scope, look at what similar apps are using, see how those match my current skills, and choose a stack based on that.

I also want to make sure the technologies are set in stone. I don’t want to have an application built on something that will be deprecated in two years.

For my current project, Dev Notes, where I’m building a community platform for software developers, I chose React with Next.js, TypeScript, NodeJS, and Supabase.

React because it just felt better than Angular. Next.js because it made React feel even better (yes, I know these aren’t quantifiable, but sometimes you just have to test out different technologies to see what you like best). TypeScript because it’s just adding a static type checker to JavaScript, plus I have more experience with TypeScript, plus I’m coming from a Java background, and TypeScript is more friendly to Java programmers than JavaScript. NodeJS to keep with TypeScript on the backend. And Supabase because it has a great free tier and is effectively just an open source Firebase. As of right now, this is my favorite stack.

How do you see web development evolving, and are there specific technologies or frameworks that you are particularly excited about?

Forrest: In terms of libraries and frameworks, I believe people will continue to create more and more – unintentionally making it more confusing for web devs everywhere – but really to solve something they find lacking in another framework or that improves their specific use case. Right now, I’m really just focused on my current stack and improving on that one.

Building a project is the best way to learn

What strategies do you use for continuous learning, and how do you determine the depth of knowledge needed for a new technology or programming language?

Forrest: Creating content has helped me learn and understand things more than almost everything else because I have to actually understand it if I want to describe it in a way to allow others to understand it.

I say “almost” because I believe building a project you’re interested in is the absolute best way to learn a new programming language or technology. And I don’t mean following a tutorial where someone else has already done the heavy lifting, but actually hitting roadblocks and using the tools at your disposal to overcome them.

As for determining the depth of knowledge needed, I don’t think that matters. Either you’re going to figure out how to build something, or you won’t, and the more you build something with that language or technology, the better you’ll know it.

Also, your YouTube content covers a wide range of technology trends. Are there specific trends that you find game-changing in the next few years?

Forrest: Well, I have a video that opened many peoples’ eyes while also making many others upset and infuriated – my video about the impact that AI will have on developers. AI is the game-changer whether people want to believe it or not.

Tractors took the jobs of farmhands, but here’s the thing: we still have folks employed as farmers. My dad was a farmer all of his life. But instead of doing everything manually, they’re there operating those tractors and other technologies that didn’t exist 200 years ago.

That’s how I see AI changing software development in the next 5-10 years. Many devs will still be needed, but their jobs will look much different than they do now. It’ll shift more towards DevOps and SRE than writing features and fixing bugs.

AI may not be the best coder, but it excels at writing thorough unit tests

Also, as a Full-Stack Developer, how do you ensure seamless integration between the front-end and back-end of your projects?

Forrest: Most of it is handled by my tech stack. Next.js provides SSR, SSG, and API routes. Node.js allows me to use the same language on the frontend and backend, plus the NPM ecosystem provides tools and libraries that can be shared between the frontend and backend. React’s component-based architecture, state management, and hooks help with this as well.

You emphasize the importance of unit testing. How do you approach creating effective unit tests?

Forrest: I focus on a small “unit” of code and test a single aspect of that code at a time.

Honestly, with Java, I just used Mockito for everything at my job and used SonarQube to see test coverage. Now, while AI still lacks in writing great code, it actually does a pretty dang good job writing unit tests.

What factors do you consider when building enterprise software? How does this differ from smaller projects?

Forrest: I make sure my initial code meets 3 high-level goals. It solves a specific problem so that it’s reusable (write 3 functions that solve 3 different problems instead of 1 function that solves all 3 at once). It’s easy to read, understand, and maintain. And it’s scalable and extendable. I also have to ensure that I’m using proper data structures and algorithms that can also scale.

With smaller projects, these details don’t matter as much because you’ll never face the issue of needing to reuse the same piece of code a dozen times. Or you can use an algorithm with a poor time complexity as the dataset increases because your dataset is so tiny that you’d never know the difference.