Forem: Thomas Hammon

LH2L: Evaluating Plans and Progress.

Thomas Hammon — Wed, 16 Jul 2025 17:48:34 +0000

Welcome to another installment of Learning How To Learn! Last time we discussed how to create a node server and Bloom's Taxonomy of Learning. This time we are going look at the larger project they were being used in, and evaluate our progress.

Where We Started
In my first post in this series, we discussed the four step plan to solve any problem, the APIE method (The four steps are Analyze, Plan, Implement, Examine.)

There we went over the problem, and the first two steps. The 'problem' was that I didn't know backend development. Then we analyzed what it would take to learn it, and created a plan. The plan was to have 3 - 4 fullstack projects that would be the meat and potatoes of the learning, and 2 - 3 mock interviews to gauge my progress and direct my efforts effectively. In this post, we will go over the last two steps, implementation and examination.

Implementation
Since my first post, I have completed 1 mock interview and 1 full stack project. Lets start with the mock interview.

These interviews as designed to be tests. Not as in pass fail, but as in diagnosis. There is no job offer on the other side of this interview, and that's really good for learning. In the words of James Clear,

"Goals are good for setting a direction, but systems are best for making progress."

There's no pot of gold at the end of this rainbow, so I have to make the ride worthwhile. Being goal oriented towards a job changes how I view that interview. My goal becomes "passing the test". Without the looming pressure of a job on the line, my focus shifts from employment to understanding my readiness as a candidate. That's what I need most desperately at this stage, is to have a crystal clear understanding of my readiness as a candidate.

So if I'm getting a diagnosis, I want a good doctor to do it. My interview was conducted by my friend and mentor, a senior engineering manager at a local tech company. He has interviewed applicants many times before, so I felt he was qualified to conduct this interview. The interview took about 30 minutes, and it was split into two sections: questions about me and my history, and questions about the technically heavy aspects. These are all the questions that were asked:

What got you into software engineering in the first place?
What are some of the hardest technical problems that you have had to solve?
Can you describe a project that did not go as planned? What happened and how did you adapt?
Can you tell me about a time where you had to optimize some code either for performance or for scale?

For the technical portion of the interview:

What is the event loop, and how does it work?
What is Middleware, how does it work, and can you provide me an example? (Long time followers of this series will recognize how this example targets the first three layers of Bloom's Taxonomy)
Can you explain the concept of streams and how they improve performance in Node.JS?
Describe how you would implement error handling in a Node.JS application and what are some of the best practices around that?
What is your understanding of object oriented programing?
What is your understanding of functional programming?
Can you talk about the difference between authentication and authorization?
What are some of the differences between a relational database and a noSQL/document database?
What is an ORM and what are some that you may have worked with before?
What are the 5 most common HTTP verbs and what kind of functionality to the map to on the server?
How would you handle logging and monitoring in a Node.JS application?
What are some of the typical layers in a backend application, and what function does each of these layers server?
Do you have any questions for me?

17 questions, all based on a example job description we had agreed upon a month before the interview.

That brings us to the project portion of the implementation. Having completed the interview, I set to work creating a fullstack application that would allow me to answer a few of those interview questions.

My application was an internal wiki for my DnD campaign. The frontend was going to be a plain, no frills set of pages that would contain text based information. It would also connect related information to each other, so that my users could find an entry, read all of the relevant information, then see everyone and everything that was related to it.

For the frontend, I used:

Next / JavaScript
Pico CSS / Vanilla CSS

and for the backend:

Node.JS
SQLite

The end goal was essentially a C.R.U.D. app. I wanted my non-technical players to be able to Create, Read, Update, and Delete the information in the database. This would require me to figure out how to transform actions on the frontend into changes in the database. If I could do this, then it would solve a genuine issue my players have been running into.

Examination

Lets now examine if those two implementations did their job correctly.

Lets look at the interview again, and when I tell you that this mock interview had me feeling worse then that last time I went through surgery, I mean it. It was the kind of interview experience that made me wish I had worn brown pants. Out of the 17 questions, there were maybe 5 I feel like I gave really good answers to. The other 12 ranged from not great to complete ignorance. I was mortified by the end of it.

Which was exactly what I needed. My mentor had chosen his questions well, and we now had the clearest view of my readiness as an applicant that I had ever had.

It is worth noting that he did not expect me to answer every question well. The experienced among you will have already seen how these questions range from basic to advanced. These questions included things he knew it would be unreasonable to expect out of entry level applicants, because it would allow him to see just how deep someone's knowledge goes. That being said, I did not get the fictional job I was interviewing for. I have a lot of learning to do before I am ready for another interview.

The project delivered. It was an incredibly motivating experience. It was the perfect mix of familiar competence and new learning. Having a good back ground in React and JS, I wasn't starting from scratch Next.JS and Node. Given this was the first time I was building an API, I chose to go for the most basic and functional one I could manage. And that was a tall order still. I only have routes for GET, POST, PUT, and DELETE, and it only maps those request to the database. I did not include anything like authentication, authorization, or pagination. The scope of this project was small enough, along with my target audience, that those weren't essential to the success of the project.

It went half a month over schedule. I feel good about that, though. Part of that was due to the fact that I got started late, I had an opportunity for freelance work, and moved during that time. Other than that, I have been spending four hours a day at my local library cranking out code and fixing bugs. Hands down, this past month and a half has been the most consistent and productive period of my learning journey. I have never before had so much skill gain in such a short amount of time. And if I keep busy, I won't loose it.

All in all, I sank between 80 - 90 hours into this project, and each one felt important and worth while. If I had to redo it, I could probably do it in 30.

And I can't overstate how satisfying it feels to have something you built function and provide value to someone. The fact that it works and my players use it is awesome.

The only real concern I have with the project is it didn't move the needle very much, in terms of my candidate readiness. Of the 17 questions, there are only 2-3 I feel like I could answer better now. It is possible that this project gave me the foundational knowledge necessary to understand the answers to as much as 7 others, but that is not the same as knowing.

Conclusion

I think the system is working very well, and that going through this cycle again would put me significantly closer to my goal. I am worried that my learning is general and not specific, accidental and not focused. With the next project, I would like to link specific goals of the project to specific learning objectives. For the time being now, I have a functional project I can demonstrate and I feel confident adding Node.JS to my resume. That's enough for me.

Do you have any ideas for projects I should consider? My next step takes me into the world of PHP, so if you know of a project that works well with laravel, be sure to leave it in the comments!

LH2L: Servers 101 (Now 2x as basic!)

Thomas Hammon — Fri, 09 May 2025 18:19:08 +0000

Welcome to another installment in Learning How to Learn. For context, I am on a journey to teach myself backend. To do that, in addition to all of the technical knowledge, I also need to know how to learn and be a teacher. So today we will breach fundamental concepts in both areas: levels of understanding and servers.

Lets start with levels of understanding. In the world of education, there is a helpful framework called "Bloom's Taxonomy" that breaks them down easily:

Remembering
Understanding
Applying
Analyzing
Evaluating
Creating

This covers everyone from the newest student to the oldest expert. So if I have this goal to learn backend, my very next question is to what level should I be learning backend? Well my goal is ultimately to be employable, and the standard for employment seems to be around 3 and beyond. Lets breakdown those first three levels a little bit further.

Remembering - This is the most basic, rote task imaginable for learning. This is being able to parrot back a definition or a fact. Being able to identify the target when presented with it. In practice it looks like this:

Q: What is a server?
A: A server is a piece of software that takes in requests and provides responses.

Understanding - When we are striving for understanding, we start to expand from definitions to understanding how the target is used. Can we explain why the target is necessary? Can we discuss it in a broader context?

Q: Explain how a server works to me like I have no technical knowledge.
A: A server is like the engine of your car. First it exists in an ecosystem. Just as the engine is supposed to take in fuel from the tank and produce force to turn the wheels, a server is made to take requests from the client and return a response to them. Secondly, engines have two specific states: On and Off. If the engine is off, pressing the gas isn't going to do too much, neither will turning the wheel or pressing the break. In the same way, the server has to be on to take in requests and provide a response.

Applying - At this point, you know the definitions and further more how they are supposed to function. This is where you show you know how to use them. In an interview, it may look like this:

Q: Can you show me how you would code a basic server in a node environment?
A:

import http from 'node:http'

const PORT = 8000

const server = http.createServer((req, res) => {
  res.end('Hello from the server!')
})

server.listen(PORT, () => console.log(server running on port: ${PORT}))

With answering these three questions, I have demonstrated a that I understand a single aspect about servers on an actionable level. There are many other aspects about servers alone that I will need to understand on this level to get hired, not to mention all of the aspects of backend. But now I know when I understand something enough to move on to the next topic. This should streamline your process or learning largely.

This brings us to the second part where we actually discuss the technical parts a server. Huge shout out to Scrimba.com for being my source of learning on this topic. The code snippet I posted above came from their course on node.JS, I highly recommend it. Lets go through it line by line.

import http from 'node:http'

Pretty straight forward. The node http package has everything we need to get a server started. Note how it is being imported from 'node:http' instead of just 'http'. Essentially, this is due to http being a core node module. Importing it directly from node should prevent bugs, and offer some small performance benefits on larger projects. There's no harm in it on the small scale, so it's a good habit to be into.

const PORT = 8000

Much like channels on a TV, we have to tell our computer which port to listen for traffic on. This will be more important later.

const server = http.createServer((req, res) => { res.end('Hello from the server!') })

This is the meat and potatoes of the code. The .createServer() method returns a server object with dozens of different methods that can be called against it. For ease of use, we assigned it to the server variable. The method takes in an arrow function which itself has two arguments: Request and Response (req and res as seen above).

Generally speaking, everything interesting about servers happens in that little arrow function. As it stands, this server will only do one thing: return the string "Hello from the server!" If you want to have a more useful, or even just functional server, it happens here.

We will start simply with this .end() method. Getting a response from a server is somewhat of an ongoing process. The .end() method tells the client that no further responses are expected, and concludes the response process. It takes two parameters, the data you want to send, and the encoding you want to use. utf8 is standard, and node will default to it if none are specified.

Now as we discussed earlier, server objects have two states: running and not running. You need to get it running to use it, and that brings us to the final line:

server.listen(PORT, () => console.log(server running on port: ${PORT}))

We are calling the .listen() method on the server object that is being referenced by the server variable. This will start the server, and tell it which port to listen for communication on, as defined by the PORT variable. As we say earlier, the current port is 8000. The second argument is a callback function to log information to the console when the code is executed.

The whole process finally kicks off when you run the code. In the terminal, run npm start and the code will execute. Notice how the process does not exit, or even conclude in the terminal. You will see "server running on port 8000" in the console, and your little blinking cursor. At this point, you should be able to ping localhost:8000, and you will get the response you placed in earlier: "Hello from the server!" To shut down the server, press [control] + [C], and the process will finally exit. Pinging localhost will no longer return anything.

That's all she wrote! Congratulations, your first server is underway. Let me know what aspects of servers you're interested in learning more about in the comments, and I'll see you next time.

Learning How to Learn Backend

Thomas Hammon — Thu, 08 May 2025 17:11:54 +0000

As I shared in my last post, I am currently on a mission to learn backend development. But the more I get into it and find other people who also want to learn, I find that there is very little focus on how people learn. I am here to help bridge the gap. In this blog post I am going over a very important topic, which is building a framework of knowledge.

Building a framework of knowledge is all about understanding how the human mind stores information, which is through relations. We don't remember specific points of information as much as we remember how those points of information are related.

For example, is there a song that every time it comes on, you remember where you were when you first heard it? Or is there a particular smell that always reminds you of your grandparents' house? This is because your brain was built to connect the dots, and it explains why the first part of learning is always the hardest: the first dot, by nature, has no other dots to connect to. If you have a whole host of dots that are unconnected, it will be even harder to remember them. Let's see an example.

This is a process that happens to everyone at least once. We are going to start on step 2, and I want you to try to figure out what is happening here:

2 - Calibrate the first stage machine for desired capacity and temperature.

3 - Introduce chemical components based off of selected capacity.

4 - Secure the entry port and activate the machine.

5 - After the primary process has completed, transfer contents into the second stage machine.

6 - Calibrate for desired duration or moisture content.

7 - Secure the entry port and activate the machine.

What's going on in this process? Is there any way to know for certain? How long do you think it would take you to memorize steps 2-7 in such a way that you could repeat them back to me? All of this information is so abstract that we can hardly interact with it. We need something we understand to ground it to, and then the entire process can snap into place. Behold, the first step:

1 - Load your dirty laundry into the first stage machine.

Just like that, the process goes from obscure to mundane. This is the problem I have ran into while trying to learn over and over again. The information is not grounded in any framework of knowledge, and so remembering it, let alone using it becomes impossible. To effectively learn, you have to start with laying a foundation of dots that the rest of the information can connect to. This is the framework of knowledge.

The most effective framework I have found is answering the question "why do we need this?" Ask that question at the biggest levels first and then drill down. You aren't going to understand why you need JWT if you don't understand why you need authentication in general. And you won't understand why you need to worry about authentication if you don't know how the front end connects to the back end, and why those concerns are separated.

Answering "why do we need this" also tells you how to use the tool you are learning. Let's start with answering the big question.

Q: How does the front end connect to the back end and why are those concerns separated?

A: The front end is made to be customer facing, highly abstracted process for non-technical people. The back end is made to be developer facing and to carry out the processes that is hidden from the client. They are connected by API calls that communicate via HTTP requests.

Because we are communicating with the front end via HTTP requests, it might be hard to know who is actually on the other end, which brings us to the next question:

Q: Are there any issues that arise out of not knowing who is requesting information from the database?

A: Yes, there is sensitive information stored in our database. We have to create a process that authenticates the user before we share their information.

Now we know what authentication provides to us in theory we can ask this question:

Q: What technical solution can we implement to make sure we are sending information only to authenticated users?

A: We can provide requests with a JWT to ensure authenticity.

Obviously, these are very vague explanations. The point is to illustrate how each level of learning becomes a framework for the next level of learning, and so on. At each level, you should strive to create a solid understanding before progressing on to the level.

What are some helpful ways that you have found to explore a new technology? Let me know in the comments!

So You Want to Learn Backend

Thomas Hammon — Fri, 02 May 2025 20:23:55 +0000

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 essentially 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!