So You Want to Learn Backend

It's me. I want to learn back end. If you do too, maybe I can help you out. Lets back up a little bit. I am a front end web developer, and I have noticed a flaw in my peers. It is not always present, but it is certainly prolific. For a job that is existentially deep learning, there is very little focus on how we learn. As a college educator this has always stuck out to me. We know we want to learn backend. But how do we learn back end? That's what I want to help you with. In my humble opinion our job isn't necessarily to write code. Our job is to provide value to others by solving problems. Code just happens to be the most effective tool for that. I find it's helpful to approach the the question of how do we learn backend like any other problem. Let me share one of the most valuable tools I've ever come across for problem solving. The APIE Method I don't mean to over sell this, but the APIE method has been a little life changing for me. It's a four step process for solving any problem. It is simple, approachable, and it's used everywhere from math to nursing. The four steps go like this: Analyze - Define the actual issue. Make sure you know what the question is asking you. Plan - Think of a systematic way to solve the issue. Implement - Enact the plan. Evaluate - Judge which parts of the solution worked, and which parts did not. The benefit of this process is many fold. Most importantly, it provides clarity of thought. Tell me if this sounds familiar to you: You want to build an app, maybe a website, and you have a goal in mind. You start to write it, and part way way through you run into error. You still have half of it to build, and you start to research a solution to the problem. Then crap, the solution is a little more involved than you hoped, you might have to use a tool you haven't before. So you start trying to learn how to use that tool, and you realize the app that's half built isn't going to work as is with this new tool, so you try to start some refactoring, and crap, it's still only half built and you're still trying to remember all the features you were wanting, trying to gauge how to this tool you half understand is going to work with them, and by this point, you have forgotten the original bug you were trying to fix. That means you don't know why you are trying to implement this solution which is driving a wrecking ball into your project. It is usually at this point I would throw my hands in the air and walk away. The APIE method prevents this because following it means trying to solve one issue at a time, and then taking time to understand the problems you run into. Both problem and solution are committed to memory, and the project has not devolved into a spaghetti mess of issues and half baked solutions. The path we take to learning backend development is just as complicated as building an app, if not more so. We will need a systematic approach to solving the issue, so lets break it down using the APIE method. Analyze - What does it mean to learn back end? What are the skills we need to call our selves back end developers? Since these are technical skills, we will need to have practice to actually encode this information as well. So to solve this problem, we need a list of skills and ways to practice those skills. Is there a place that maps this out for us comprehensively? Great news, there absolutely is: [https://roadmap.sh/backend] Road map is a fantastic tool for not only breaking down the process into individual steps, but also for providing resources for getting started. Just click on any of the boxes and you will be supplied with a list of resources. As with all important things, it's also worth getting a second opinion from someone who knows. I asked my mentor, a senior engineering lead at a local tech company, what his thoughts were on the matter. He gave me his own list of what he looks for when he has to make hiring decisions for backend developers. I would go over that as well, but that's a post for another day. So now we have a list of skills, now we need a list of ways to practice them. I am a big advocate for project based learning. Once you have a general understanding of how an aspect of back end operates, think of a project that would use that. Do you want to learn about relational databases? Make a relational data base. Bonus points if it fits into a real world situation. I have a database that tracks the lore of my dnd campaign. It doesn't have to be crazy, just real. Now for me, I want to learn backend in pursuit of becoming a full stack developer, so my projects are going to be full stack projects with emphasis on the backend. It looks like we have the list of skills and an idea of how we will learn them, lets move on to the next step. Plan - What steps are we going to take when to accomplish our goal? Making a plan is about two things: schedule and removing ambiguity. The advice I was given says that I should have 3 to 4 complete fu

May 2, 2025 - 21:38

It's me. I want to learn back end. If you do too, maybe I can help you out.

Lets back up a little bit. I am a front end web developer, and I have noticed a flaw in my peers. It is not always present, but it is certainly prolific. For a job that is existentially deep learning, there is very little focus on how we learn. As a college educator this has always stuck out to me. We know we want to learn backend. But how do we learn back end? That's what I want to help you with.

In my humble opinion our job isn't necessarily to write code. Our job is to provide value to others by solving problems. Code just happens to be the most effective tool for that. I find it's helpful to approach the the question of how do we learn backend like any other problem. Let me share one of the most valuable tools I've ever come across for problem solving.

The APIE Method

I don't mean to over sell this, but the APIE method has been a little life changing for me. It's a four step process for solving any problem. It is simple, approachable, and it's used everywhere from math to nursing. The four steps go like this:

Analyze - Define the actual issue. Make sure you know what the question is asking you.

Plan - Think of a systematic way to solve the issue.

Implement - Enact the plan.

Evaluate - Judge which parts of the solution worked, and which parts did not.

The benefit of this process is many fold. Most importantly, it provides clarity of thought. Tell me if this sounds familiar to you:

You want to build an app, maybe a website, and you have a goal in mind. You start to write it, and part way way through you run into error. You still have half of it to build, and you start to research a solution to the problem. Then crap, the solution is a little more involved than you hoped, you might have to use a tool you haven't before. So you start trying to learn how to use that tool, and you realize the app that's half built isn't going to work as is with this new tool, so you try to start some refactoring, and crap, it's still only half built and you're still trying to remember all the features you were wanting, trying to gauge how to this tool you half understand is going to work with them, and by this point, you have forgotten the original bug you were trying to fix. That means you don't know why you are trying to implement this solution which is driving a wrecking ball into your project.

It is usually at this point I would throw my hands in the air and walk away. The APIE method prevents this because following it means trying to solve one issue at a time, and then taking time to understand the problems you run into. Both problem and solution are committed to memory, and the project has not devolved into a spaghetti mess of issues and half baked solutions.

The path we take to learning backend development is just as complicated as building an app, if not more so. We will need a systematic approach to solving the issue, so lets break it down using the APIE method.

Analyze - What does it mean to learn back end? What are the skills we need to call our selves back end developers? Since these are technical skills, we will need to have practice to actually encode this information as well. So to solve this problem, we need a list of skills and ways to practice those skills. Is there a place that maps this out for us comprehensively? Great news, there absolutely is: [https://roadmap.sh/backend]

Road map is a fantastic tool for not only breaking down the process into individual steps, but also for providing resources for getting started. Just click on any of the boxes and you will be supplied with a list of resources.

As with all important things, it's also worth getting a second opinion from someone who knows. I asked my mentor, a senior engineering lead at a local tech company, what his thoughts were on the matter. He gave me his own list of what he looks for when he has to make hiring decisions for backend developers. I would go over that as well, but that's a post for another day.

So now we have a list of skills, now we need a list of ways to practice them. I am a big advocate for project based learning. Once you have a general understanding of how an aspect of back end operates, think of a project that would use that. Do you want to learn about relational databases? Make a relational data base. Bonus points if it fits into a real world situation. I have a database that tracks the lore of my dnd campaign. It doesn't have to be crazy, just real.

Now for me, I want to learn backend in pursuit of becoming a full stack developer, so my projects are going to be full stack projects with emphasis on the backend. It looks like we have the list of skills and an idea of how we will learn them, lets move on to the next step.

Plan - What steps are we going to take when to accomplish our goal? Making a plan is about two things: schedule and removing ambiguity. The advice I was given says that I should have 3 to 4 complete full stack projects, and 2 to 3 mock interviews under my belt to be ready. Knowing this, I started with setting an end point: when do I need to be finished with this? For me, I have 7 1/2 months to meet my particular goals. It started yesterday, and is going to end on December 15th of this year.

So I opened a word document and plotted out how 3 to 4 full stack projects fit into the next year. It's crazy how many things come into focus when you do this. It made me realize that I couldn't do this if I was working full time. So I made plans to readjust my finances and leave a part time job I had been holding. I realized that my schedule needed to allow time for this practice every week day, so I made plans to work in the mornings at my remaining job so I had time in the afternoons consistently.

At this point I a reminded by a favored quote Dwight D. Eisenhower: "Plans are worthless, but planning is everything." In essence, plans are going to change, and that is alright. We need to anticipate this and build flexibility into our plans, otherwise the slightest hiccup will shatter all of our well laid plans. Notice how I said 3 to 4 plans? 2 to 3 interviews? These allow for some flexibility. If I run into harder problems with on project, I can let go of the last one to add extra time. If scheduling issues prevent a third mock interview, I can settle for two.

Flexibility also comes from acknowledging you don't need to know everything right now. Of my three to four projects, I only have a solid idea of what I'm going to do for the first one. I know it is going to use Node.JS as that is the tech stack I'm most familiar with, I know what service I want it to provide, and I know when I am going to start it (currently set for April 20th). For my second project though? I only know that I am going to use PHP and give it twice as long as my first one to make sure I have time to learn it. For my third one, I have a vague sense that it will start in early September, and that it needs to be beefier than my other two. And the fourth one? We will cross that bridge if we even get to it.

Now that's a lot of flexibility, but it only works because I have a plan to fill in the missing gaps. Those mock interviews are going to be sprinkled in before each new project I start to find where my short comings are. I can then plan on making each of the new projects fit to what I need to learn.

Finally, plans should help you reduce ambiguity. Don't give yourself room to make bad choices. As James Clear says, "Automate good behavior." From the macro level, my plan may only look like a small handful of decisions that have been made. At the micro, day to day level, my plans are going to require dozens, if not hundreds of decisions. Having a clear idea of exactly how you plan to show up on the day to day eliminates so many opportunities for failure. For example:

Plan with high ambiguity: Today I need to work on my project.
Questions I have to answer to make that plan work: How much time do I want to spend on it? What aspect of the project am I working on? When do I plan to sit down and work? Where do I plan to work? Can I move it around other priorities I have to do today?

v.s.

Plan with low ambiguity: Today I will work for two hours on my project after I finish my final class. I will do so at my cubicle where I can focus, and I will continue where I left off yesterday. Anything else that has to be done today can be done after I finish my two hours.
Questions I have to answer to make this plan work: Am I getting tired of kicking so much ass? (The answer is no, you are not.)

All jokes aside, each little uncertainty is an opportunity for your brain to say "I don't wanna", because you now have to put in more effort to even get started. Deciding on a low ambiguity plan that you can replicate day to day means you only have to decide once, instead of hundreds of times. Despite what our ambitions are, when it comes to actually sitting down and doing the work, humans are exceptionally good at avoiding it. For more on this, I would recommend "The War of Art" by Steven Pressfield. The incredible and profound focus of the book makes an extremely clear point that is difficult to argue with.

Now we get to the juicy parts, implementation and evaluation. I will be blogging about my journey on a daily basis, where I will cover the roll out of each step, and evaluate it's effectiveness in post. For now, my questions for you are this: What barriers have you run into on your quest to learn new technology? Is there any thing you would like me to cover in depth as I move forward? Are dolphins mammals? Leave any questions or answers you have for me in the comments!