Forem: Aaron McCollum

2026 Hopes and Goals

Aaron McCollum — Wed, 07 Jan 2026 05:21:08 +0000

Happy New Year! We made it. We survived 2025 with all the ups and downs it brought. Pat yourself on the back for making it — you deserve it. And now we have a new year to (hopefully) look forward to. This blog post will focus on career goals, but I also have a few personal objectives I'd like to achieve, which won’t be mentioned here. Below are some professional goals and brief descriptions of those goals I have for 2026.

Completing 100devs courses and assignments: This includes the big 100-hour project that will serve as my flagship project for my portfolio site. I have heard that Leon is considering a Cohort 3, so I’ll want to be available to help the newer students and sit in on any new content related to AI and the coding tools available.

Getting another job: 2025 was not a great year to quit your job, even for experienced developers, and I’ve been looking for my next developer role for about two months. A significant goal for me in 2026 is to secure my next role, which will enable me to continue growing my career.

Improve my AI knowledge and skills: As AI continues to grow, I am not content just knowing how to prompt an LLM for code. I have ordered The Developer’s Guide to AI, which should be released in March. The book will include projects and getting an LLM to run locally on a laptop, which I’m interested in exploring. I’ll write on some of these, probably around late spring and into the summer (my focus until then will be on 100devs and job searching).

Contribute to open source: I am getting my feet wet with freeCodeCamp and helping to develop some new labs for them. But I want to branch out from freeCodeCamp and find a few other projects to contribute to moving forward.

What goals do you have for 2026?

Creating a functional Contact form on your website

Aaron McCollum — Fri, 26 Dec 2025 09:52:30 +0000

Early on in most web dev learning journeys, you are usually taught how to make basic forms in HTML. You can use the <form> element and embed several <input> <label> <textarea> and more inside to create the front-end for your forms. Then you finish it off with a <button> element for submitting. But what do you do after you create the form itself?

A lot of websites today have a contact page, since it provides a nice UI/UX experience to get in touch with the person or organization, and you do not need to have a public-facing email address on your site which is open to spams, scams, and unwanted sales pitches. The contact page (or <section> if it’s just one webpage) is usually an HTML form with a few simple fields: name, email, subject, and message. Once you have used your HTML skills to create the form on the front-end, you will need a way to receive that information and be notified about it.

Netlify lets you do this very quickly and easily without having to write a lot of JavaScript and backend development. Better yet, not only can you be notified in your Netlify account about a form submission, but you can also receive an email notification each time someone submits the form on your site. It’s free as well (with limitations which we’ll cover farther below), which means it’s open to any developer who wants to add this functionality quickly to their site. Below are the steps:

Step 1: Connect your project to Netlify
The first step is to create your project, add your code, and connect it to Netlify. What I did was create a private repository on Github, add my project code there, then log into my Netlify account (free tier by the way) and connect my Github and Netlify account. This gave Netlify access to my Github projects, so I could pick and choose which ones I wanted to deploy with Netlify. Below is a screenshot of a few projects currently in Netlify using the code in Github repositories:

The top one, “aaronmccollum” is my portfolio site, which is where my contact form resides. Once my project was added and deployed, I was able to go to the next step.

Step 2: Enable form detection in my portfolio project
I clicked into my portfolio project to open it up. There a new side menu appeared for settings specific to my portfolio project. One of the side menu items is “forms.” Clicking that took me to the forms settings page. From there I could enable form detection.

When Netlify deploys or redeploys your site after changes made, it does a scan of your HTML. When you enable form detection, Netlify will include some special searching in your HTML for any forms. So I needed this switched on.

Step 3: Add some special HTML attributes to my and embedded form elements
So how does Netlify know once it’s reached a form it needs to track? When it scans your HTML, it’s looking for a specific attribute in your <form> element: data-netlify="true". The entire element could look something like this with the attribute added:

<form name="contact" method="POST" data-netlify="true">

The other thing you need to do is ensure your <form> element and all of your input elements, including <input> and <textarea> have name attributes. Netlify will use these later in the UI and in emails to help label the data that is submitted.

Once I pushed these changes to my contact form on my portfolio website, Netlify redeployed my site, parsed my HTML file with it’s updates, and since the form detection was turned on, began tracking any submissions to my HTML form on my portfolio page.

I ran a quick test by submitting a test submission, and it worked! When I refreshed my project in Netlify and went to the “Forms” section, I could see a new submission.

But that’s not all I wanted. I wanted an email sent to my email address every time someone submitted a form. Netlify offers a pretty quick way to do that as well.

Step 4: Add email notifications for your form submissions
In my portfolio project’s menu, I clicked “Project configuration” then clicked “Notifications.” This took me to all the notification settings for my specific project. Netlify lets you configure these separately for each project which is nice.

I scrolled down to “Form submission notifications.” This is where I added my email address to be notified each time a form submission was made.

When you add a new notification setting for this, you can use the following options:

Event to listen for: New form submission
Email to notify:
Form: the value of the name attribute in your <form> which Netlify may already have

Optionally you can also set up a custom subject line for the email, which could help the notification emails stand out if you receive a lot of other emails.

Step 5: Test
The last thing I did was send another test form submission in. Within about 10 seconds, I had an email with my form’s information. Because my form included an email field with name="email" in one of the <input> elements, Netlify will automatically save that email address as the reply email. This means if I want to reply to the sender, all I need to do is reply to the notification email sent to me, and the submitter’s email address will be in the address bar of my email.

A few things to know about the free tier
A free tier in Netlify gives you 300 credits per month to use. Redeploying your site cost 15 credits, and a form submission costs 1 credit. So this is not a limitless option to use. In my current cycle, I’ve redeployed my projects a total of five times, so I’ve used 75 credits alone in just redeploys. This means if you have a form, get some website visits (which costs a fraction of a credit for each visit), and you make an update or two, this can add up.

My thinking here is if I get to a point where my portfolio site is receiving incoming messages and visits to the point where I max out my monthly rate, I may be ready for a subscription. But for now, this free tier and the credits is allots to me each month is perfect.

Netlify also does help with spam detection and allows you to create an invisible honeypot element in your form to catch automated spam. I have not added one of those yet, but you can find them in Netlify’s documentation.

And speaking of documentation, here is the link to the Netlify forms documentation site where I was able to read up on all of this. I recommend reading through this when you use Netlify for the first time to connect a form.

Aaron is a Software Developer experienced in web development and business-process management applications. You can follow him on Bluesky or Mastodon.

Start, Stop, and Continue for 2026

Aaron McCollum — Fri, 19 Dec 2025 04:33:19 +0000

With 2026 just a few weeks away, here is what I’m hoping to Start, Stop, and Continue for 2026.

START: Getting serious with the job search. I have been working through 100Devs but am getting to a point where I can be applying for jobs. In the new year, I want to put my best foot forward when it comes to applying for jobs and networking, or potentially looking at freelancing.

START: Learning more about AI. I probably need to do a longer post on my full thoughts on AI in the professional workplace, but like it or not it is here. I have a book called The Developer’s Guide to AI on order, which should help with the learning. I never want to surrender my understanding of software development and coding to artificial intelligence, but I do want to learn how to better utilize the tools out there in case I need to use them for a job.

STOP: Bouncing around on topics to learn. This is something that has held me back probably since I started coding. I have shiny object syndrome. I get really excited about for a few weeks, lose interest, and find something else to explore. That’s great sometimes, but it’s resulted in me being a mile wide and an inch deep in my knowledge. The last few months I’ve stayed with 100Devs, and the structure there has been really helpful. Going into the new year, I want an entire year of locking in on certain things to learn that will be most impactful for the next step in my career.

STOP: Not taking care of myself. The last few years have had a few ups and downs, and I’ve seen the physical shape of my body worsen. I’ve been resolved to eating junk food, lounging on the couch, and spending too much time on the computer and not enough moving and getting my heart rate up. I need to get back in shape! So yes, this is sort of a START topic I suppose but I needed another STOP for the blog post. I’m hoping to drop 5–10kg in 2026 while improving my upper body muscle.

CONTINUE: 100Devs coursework through completion. I am 15/69 classes into the program. Some of the classes were networking nights instead of lectures so I will skip those, but I’d say I’m about 25% through the entire program at the moment. I’ve made two projects that I have ready to put in a small portfolio to showcase the progression of my learning. I’m in a good spot! And in 2026 I want to actually finish the program out and make one or two really good portfolio pieces.

CONTINUE: Networking and meeting people. Since landing in Seoul, I’ve been able to get involved with Dev Korea which has been a blast. I’ve also started connecting and reconnecting with friends on LinkedIn and making new relationships. I don’t have any specific goal here, except that I want to make friends and build out a network where I’m positioned to help others and can ask for help as well when needed. I do hope that my network can help with the job search in 2026, but I won’t put that expectation on any one person.

CONTINUE: Reading some cool books! In 2025 I read some pretty neat books, the best being Surprise, Kill, Vanish by Annie Jacobsen. Her writing style was very interesting, and she usually writes about some historical topics, so I was all in to that book. To finish 2025, I read Brave New World by Aldous Huxley, and that book has an incredible last few chapters (there is a very good debate near the end). I’m sure I’ll have one or two software books in 2026, but mostly I want to read more history and a few classic fiction books.

What are your START, STOP, and CONTINUEs as we go into the new years?

Aaron is a Software Developer experienced in web development and business-process management applications. You can follow him on Bluesky or Mastodon.

Podcasts I listened to in 2025

Aaron McCollum — Mon, 15 Dec 2025 08:13:37 +0000

Happy almost new year! 2025 was a fun year, filled with a lot of learning, a big move, and some life changes. But what remained constant throughout the year were the podcasts I listened to.

I like podcasts a lot. They are great for commuting if you have to go to the office for work (which I would), and they are also great when I’m doing something a physical task like cooking or cleaning. They make the difference between having fun doing chores and dreading it.

This year I mostly listened to IT/developer podcasts. They’ve been great for motivation, staying up to date, and entertaining me on long drives to see the parents (nearly a full day).

So without further ado, here are the podcasts I listened to this year with a small explanation for each one on why I love them and recommend giving them a try:

Hanselminutes with Scott Hanselman: Scott is someone I look up to in the world of IT. He’s a really cool dude, someone who loves open source, and his podcast is almost 20 years old! Seriously I think his first episode was in 2006 talking about the Xbox 360.

Scott’s podcast is perfect for a commute, usually going for about 25–30 minutes. His guests are pretty diverse in their career fields as well, as are his topics. For any general tech/dev person out there, this is a great podcast to check out.

The freeCodeCamp Podcast: I’ve been a big fan of freeCodeCamp for a long time. They are a fantastic FREE resource for learning web development including JavaScript and Python, and their Youtube database contains thousands of hours content in other areas.

Quincy is a great host, and you can tell that he truly has a passion for what he does. His guests are usually developers who transitioned careers, all of which are unique stories. As someone who changed careers myself and got into coding in my late 20’s, I resonate with that.

The Programming Podcast: This is a newer podcast (~1 year old now I think?) with Danny Thompson and Leon Noel. They sometimes have guests, but what I enjoy the most is their advice for getting a job in 2025, resume tips, interview tips, and how to network and “get after it.”

Leon is the lead teacher for 100Devs, which I’m doing right now, and Danny currently works in the AI space. So their podcast also talks about current events around the new AI tooling, which any dev will benefit from.

The Vergecast: This is the podcast I’ve been listening to for the longest time. I found these guys back in 2021 after reading their blog. This is a general IT industry podcast which goes over current events in the IT space and product reviews. They also have some ancillary podcasts that I haven’t listened to as much (mostly due to time), but this is the flagship one. They also bring some great humor to the podcast. Their guests are usually their writers who come in to talk about a news piece they wrote or current events.

KSR Radio Podcast Network: I love Kentucky Wildcats, and KSR is the best at any UK content. The best times are during big news, like a coach getting fired or a big win/loss. The last few years with Calipari leaving then Mark Stoops being fired has yielded some fun times listening to speculation and rumors.

Orange and Brown Talk: This is a podcast for Cleveland Browns fan (your’s truly for sure) with the writers from the Cleveland Plain Dealer. If you’ve somehow found my software blog and are a Browns fan, they have some of the most educated and balanced takes and thoughts on the current state of the Browns, which frankly is never good.

What podcasts did you check out in 2025? Any recommendations?

Things learned from making several HTML/CSS layouts

Aaron McCollum — Fri, 05 Dec 2025 05:47:08 +0000

The past week and a half for 100Devs has involved making several layouts. Initially, we just wrote the HTML code for popular sites already in existence. I wrote the HTML for the BBC homepage, TechCrunch, and a few other sites. Then Leon brought in CSS, and we were instructed to go back and use CSS (CSS floats specifically) to update the websites we had already written HTML for, and we had some new layouts given to us to create brand new with both HTML and CSS. Below are some lessons I learned from these layout projects.

Make your layout before adding content

What made the BBC and TechCrunch projects hard was that I already had my HTML content and images there. The words and pictures were more of a distraction while I was trying to set up my float containers and figure out which containers needed to be inline and which needed to be block.

The result was site layouts that were about 80–90% there, but they were not exact matches. What they did help achieve was getting me comfortable using floats to align my content side-by-side on a page, or use nested floats to get a 2x2 build (for the BBC site).

It’s not too bad! I was pretty happy by the way it turned out, but you can also see that it is not what the real BBC site looks like. The finer points of the design are rougher than the real thing. But doing this project, as well as updating the TechCrunch site, taught me that it’s harder to add the layouts after you add the content. Instead, I should add the layouts and frame everything out and get it just right before adding the HTML content.

Make sure your page margins are also set and good before adding content

Leon assigned two new layouts for us to work on as well: Source Inc. and Level Ground MMA. With my newfound knowledge in hand about framing out my layouts before adding content, I did exactly that and started with Source. What I did NOT do was make sure my page margins were set. This would have made it much easier to ensure all my containers and content was aligned on the right and left of the page. I could have used one CSS rule and one selector to handle this, but instead I used several rules and selectors to handle it and had to make sure all of them had the same margin declaration.

On my second site, the Level Ground MMA site, I remembered to set the margins at the same time as getting the layout framework set up. This made it much easier. You can check out the finished Level Ground MMA clone here, since I made this one a public repo on my Github: https://kyaaron.github.io/Level-Ground-Company-Site/. As a note, I did not make a media query for this for mobile, so it’s best viewed on a laptop or desktop. This leads me to my last lesson learned.

Make sure you ALSO write your layout media queries before adding content

Yep. I didn’t do this. And it’s on my to-do list to add a mobile media query to the Level Ground site, however now I feel it’s going to be more of a challenge due to the distracting words and content on the page. Doing a media query for mobile devices, or vise-versa doing a mobile-first layout then adding desktop media queries, would be best to code before adding content. That way, I can test out the layout changes using just a simple border: 1px solid black declaration on every container to make sure the layouts are responding correctly, then add content.

To sum all of this up, I need to make sure everything about my layouts are complete before adding content including my media queries and page margins. Once I have all of that working, then it’s time to add the HTML content and style it up to make it look nice!

Let me know how you prefer to framework your pages when creating them in the comments.

Branch development with git

Aaron McCollum — Tue, 02 Dec 2025 10:39:26 +0000

Branch development is a key aspect of software development. The idea here is you clone (i.e. copy) the code you’re going to work on onto your own computer, then you can make your necessary changes, then lastly save it back to the official code repository. In other words, you take the copied code and “branch” off with it to make changes. Then you “merge” your branch back into the main repository of code.

In my old job, Pega handled this on it’s own. It had it’s own branching tools, so I could copy the low code settings into my own branch, make my changes, then check them back in to the official code. But outside of low-code tools like Pega, developers primarily use git to help manage their branch development.

With 100Devs, I’ve been pushing the HTML and CSS projects into Github. In the past, I would not create branches. I would just clone the code down, make changes, then merge the code straight into the main branch without creating my own branches or opening a pull request. While that would work for small one-developer projects, that won’t work long-term in my learning.

Below is the workflow I’ve been using for the past few weeks. I’m writing this mainly for myself — I forget the terminal commands sometimes and will need a reminder. But hopefully this can also help you, the reader, if you are just starting out and learning git.

git checkout -b <branchName> : This command does two things — it first creates a new branch with whatever value you provide (without the < and > symbols), and it automatically checks out your code into this new branch.

git branch : This will list out all the branches you have. The branch you are currently working in might have a * beside it’s name, be colored green, or be bolded in the terminal.

git status : This shows all the updated files that are not staged for the next commit. Usually a terminal will show these files in the color red.

git add <fileName> or git add . : The first command adds a specific file name to the staging area for the next commit. The second command adds everything that’s been changed. Be careful with the second command, as you may not want to add everything for the next commit quite yet.

git commit -m “<commit message>” : This commits the changes in git. This won’t send the code remotely to Github quite yet, but it does save the code into a new “version” of your codebase. I always add a message, and I am learning to follow conventional commits.

git push origin <branchname> : This pushes your code remotely into Github. If a branch does not exist yet, it will create a branch in Github with your updated code. Github will then give you the option to open a pull request, or open a draft pull request (which I didn’t know about until a few days ago, and I love that feature).

That’s it! I wanted to document the common commands I use in git. I’ll be posting again soon with some more learnings from 100Devs, but I wanted to get this post out first as I know it will come in handy later on for more projects I’m building.

What other git commands do you think I should know and put into practice?

Creating an application using Vite

Aaron McCollum — Wed, 26 Feb 2025 22:34:40 +0000

Up until recently, you could create a React application using Create-React-App. It was a lightweight way to create React applications quickly and was supported by the React documentation. Create-React-App has been discontinued - it will still work I suppose, but it is no longer the recommended way to create React applications.

I first came across Vite while going through freeCodeCamp's new curriculum. About a week later, while furthering my React studies on Scrimba, they also suggested using Vite as a worthwhile replacement. After building a few projects, I definitely agree.

Vite is a build tool for creating React applications. Of course, I could try to create my own React applications using no build tool, but that can take a long time and there are many files to configure. If someone else has done this work already, I'm going to take advantage of that!

In order to use Vite, you need to install Node.js if you haven't already, and it needs to be a version higher than 18.0.0. Originally I had a higher version of Node installed (I think it was 22.0.0. or 23.0.0, I can't remember), and that caused some trouble with using Vite. Currently at the time I'm writing this, I'm using Node version 20.0.0 with zero issues.

Once Node is installed, do the following steps:

Navigate in your terminal to the folder you want your project to be stored in. For me, I usually change my directory to Desktop and store my project there.
Run npm create vite@latest
This will start the tool's prompts. It will ask you just a few questions:

What is the project's name?
What library/framework are we using?
What language do you want to focus on? (For example, when I choose React for question #2, it will then ask if I want to focus on JavaScript, Typescript, or a few other options).

Once these questions have been answered, Vite will build out the project. At the end, it will give you three commands to run in a row:

cd <project-name>
npm install
npm run dev

That last command will be one you probably use a lot, as it is the command that starts up the live server so you can see your work rendered in the browser. I personally find myself starting and stopping the server as needed, usually when I need to use my terminal for something.

And that's it! In the folder you selected, your new Vite project will be created. At this point, you can go into the project itself and clear out all the default stuff (styles, text, images, favicons) and begin creating your JSX files, stylesheets, and link them together.

Documentation link: https://vite.dev/guide/

Watching Claude play Pokemon

Aaron McCollum — Wed, 26 Feb 2025 10:08:34 +0000

Currently Claude is playing Pokemon Red on Twitch. It was hard to tell what game it was playing, since the color palette of the game is very colorful with reds, greens, blues, and different shades of others (much unlike the real games being played in a blue or red hue). Now that I'm reading the Twitch "about" section, I see they are using Danny-E 33 + FroggestSpirit's full color patch which helps Claude see the screen better apparently.

This looks to be a passion project, likely a Claude super-fan or someone from Anthropic doing this on their own time. This is an experiment to see if Claude can actually beat the game on it's own with no outside help. It can learn the game, develop strategies, develop a battle theory when fighting other trainers, have goals for Pokemon levels, and learn the maps to move around.

I'm pretty fascinated right now while watching. Claude is moving very slow. Veeery slow. But I'm reading the left-side thought process that Claude has while seeing the game on the right, and I'm thinking to myself "This is exactly what my 9-year old brain was thinking when playing this game for the first time." I had Pokemon level goals, I had certain strategies to beat Brock's rock Pokemon at the very beginning (I had yellow and found out the hard way that Pikachu has zero use in that gym fight). It's pretty neat now to see an AI developing these same goals.

But as I mentioned above, it's very slow. I suspect in 5-10 years we'll have models that can play this game much quicker. But it soon gets a little boring watching the stream intensely, and the game music gets repetitive when listening to the same Viridian Forest theme for 30-40 minutes.

I've given it a follow and will be lurking to see how far we get. At the time of this writing, Claude has made it to Pewter City, and it has one Pokemon above level 10. That's expected for a player who has just entered Pewter City but it looks like it has several hours of training before it's ready to fight Brock.

You can follow along here: https://www.twitch.tv/claudeplayspokemon

Tips for remote work

Aaron McCollum — Sat, 23 Mar 2024 22:58:41 +0000

Remote work is all the rage these days. Especially after the Covid pandemic and companies embracing a lot of video technology and security applications that make working from home very possible, there are a lot of positions now which allow for someone to do their job to the fullest extent and never walk out the front door. And it's fantastic! There are less cars on the road, more time to spend with your family or handling life, and you'll have more time for hobbies or getting active.

Three out of my last four jobs involved working from home. In 2020, the customer success manager position I had was quickly forced to go 100% remote when Covid hit. Then in 2021, I started another customer service job that was 100% remote from the beginning (and I was in a different country with a 13-14 hour timezone difference). Most recently I started a developer position which is about 60% remote. I've figured out through these experiences (especially with the time zone difference) that there are ways to do remote work well and there are ways to not do it well.

As such, I wanted to pass along six tips I have for remote work to help it go well for you. Working from home is a fantastic perk to have for the job that can come with a lot of benefits, but it does come with some responsibility on your part in order to be a good thing, and it does carry some extra challenges.

Make sure your internet is good. This is basic, and I don't think it will be an issue for most people these days, but I still have to list this. You have to have good internet - enough to have video calls while potentially sharing your screen and/or multitasking. Your company will probably set you up with a laptop with enough hardware resources to do this, but it will be up to you to have good enough internet service.
Be visible and involved at your company. Use Slack, Teams, Workplace by Facebook - whatever your company uses for communication and instant messaging, and be active there. This is crucial! I could probably write up a whole post just on this tip, but this is one of the most important things when you work remote. Being visible in your company opens up more doors with promotions and leadership opportunities, develops better working relationships with your colleagues, and can help satisfy the social itch which you may not have at the house (unless you live with others who are also at home all the time). You don't have to be in the social space every day, but checking in and posting a few times a week is good.

Yes, it's possible for you to be a complete recluse, never sign into your company's communication tool, and rely on your brilliant work to turn heads and lead to promotion or that next job elsewhere. I have coworkers right now who do this. I wish you the best of luck - that's the harder path. Be involved, be visible.
Communicate a lot. You'll have to communicate more when working from home than when you are in the office. Most communication at home will be asynchronous. You lose context with asynchronous communication, and you do not get instant feedback or communication back most of the time. If you are on a group project working with other team members, let them know when you are going to be away for an extended period of time (e.g. lunch), and hopefully they'll do the same for you. It's a good way to help manage expectations. No, you do not need to let everyone know every time you go to the restroom or feed the dog - but usually I'll let my team know if I'll be away longer than 15 minutes. Think of it as doing a service to others, they'll know not to expect anything from you for the next X minutes.

It takes awhile to feel out what's best and expected on your team. You don't need to ping them every 5 minutes with updates (please don't!), but the point of communicating more when working at home is to not leave your team in the dark guessing on where you are and what you've done. This doesn't help you, them, your company, or your customer. When you start remote work, ask your manager what is expected and how to best communicate with your team - then do exactly that.
Go touch grass. A big mistake I've made before is never leaving the house to go for a walk outside. Get out! Get away from the screen for awhile. Ping your team, tell them you're going on a walk and will be out of pocket, then lock your PC and go enjoy a nice walk. This will help clear your mind, boost creativity, and get you some steps in for the day. If you're like me and don't have a gym membership of any type, this will be good for you physically as well.
Minimize distractions. There are more distractions at your home. That's reality. You have pets, other family members, your own personal computer with Twitch, video games, chores that might be calling your name, and more. A nice part about being in the office is that a lot of these distractions are removed for a time period. At home, they are right there and they're calling your name! This is something I have to work on every day - minimize these distractions. Turn on some lofi music instead, and keep these distractions for your lunch break or when you reach a stopping point in your project and need to move around. Personally, I like to vacuum during the work day, but I'll do it when I've been at my desk for awhile and need to move around.
Turn off that computer at closing time (if you can). A big downside from working from home can be the blurring of the line between personal and work life. Managers may call you at 7pm and think you can quickly open your PC to review a document, or maybe you'll remember something you forgot to do and before you know it, you're working again after hours. I will say this now - most jobs are not that crucial. Whatever it is, it can be handled tomorrow. Once 5pm or 5:30pm hits, turn off your computer and get away from work. Treat it exactly like the office - you leave work at a certain time and you are not there again until the next weekday. This can also be the same for the company Slack channels. Yes, I'm a big proponent of using it to your advantage (see #2 above), but you don't have to be on Slack after hours either.

There are some instances where you'll need to be on call, just like the office, or you'll need to work late to make sure your next product release is pushed successfully. But most of the time, most jobs are not that crucial and that email can be answered tomorrow. Enforce boundaries and keep that work/life balance.

In closing, hopefully these tips help! I firmly believe that if you learn to do most or all of these successfully, your WFH experience is going to be really good for you. You'll build a good reputation for yourself quicker, stay productive and do good work, and be healthy. From one remote worker to another - I wish you luck.

My software development journey

Aaron McCollum — Wed, 13 Mar 2024 12:15:08 +0000

A few months ago, I accepted my first software development position with my company. It was a really cool moment, and it was a culmination of around four years of work, practice, courses, and being swayed back and forth on different languages and techniques. Several people in my life now have learned that "I work in I.T." and ask about how I made the career switch, and when you get the same question several times you know what comes next - a blog post!

Below will be a brief recap of my career, what I did and my motivations for doing it, and a few lessons I've learned along the way that I would give to anyone else looking to get into I.T. or software development more specifically.

Where I started

I went to school for Sports Management. I wanted to work in the front office of a major sports team. That was the line I repeatedly told anyone who asked. I did not have a specific role in the front office defined in my goals but usually would default to something like "probably sports marketing." That's a role that has a sexy title but keeps you away from being in sports sales. Funny enough, sports sales has the highest number of job positions available and seemingly the lowest amount of people interested.

I graduated from school (both a bachelors and masters degree in Sports Management), and found positions with the Washington Nationals first (Inside Sales) then D.C. United (Account Executive) where I spent roughly the next four years of my life. I loved it at D.C. United despite the atrocious stadium we had to work in (that could be another blog post, but we were young and could work through anything). But I spent almost four years in the same job and knew that sales just wasn't my thing. And with life changes occurring in my late 20s, I needed to find something new that would fit the life I wanted. I guess that's a vague way of saying I wanted to be paid more and work a normal amount of hours in a week (sports can have you work way over 40 hours per week and the salaries can be heavily diminished due to "demand" of people wanting to get into the field).

The interest in I.T. begins

In 2018, I made a bold jump to take my first job out of the sports management career. It was scary, since I felt I was starting over at 28 and even though, yes, I was still young, I didn't feel young. But I found a position at a real estate tech startup (Compass) as a Customer Success Manager for the real estate agents. I loved it there. While at Compass, I started editing the HTML for our Agent's profile pages. I was just following a script made my someone else, so I didn't know exactly what I was doing. But my interest in learning about HTML started there. In the summer of 2019, I enrolled in my first HTML course at Codecademy and built the brown bear website. I think that course, as of this writing, is still there today - good times! I found freeCodeCamp shortly after and did their HTML/CSS course, and I did a short Python for Data Science course to close out 2019. I was hooked - I wanted to be a software developer.

But how could I do it? Bootcamps are quick but were expensive and I'd have to leave my job, plus take the extra time after the bootcamp to find a job. That's a lot of money to spend/lose and the opportunity cost could be very high. Learning on my own is mostly free, but it can take much longer to make that transition. And as much as I would have loved to go and get my Computer Science degree, that's another 2+ year commitment that would cost a lot of money that I didn't have. For the time being, I would learn on my own.

The strategy

In 2020, I left Compass due to moving out of the area, and in early 2021 I joined Cybrary as a member of their customer experience team. It was a good role that gave me access to a lot of online training for I.T. and Cybersecurity. On one of Cybrary's podcasts, they invited Meg West onto the show. She described how she was able to get her first Cybersecurity role by laterally moving within her company from her non-I.T. position to a cyber role. The hardest part is getting that first job, and sometimes the best opportunity to land that first role can come at the place you're already working. That was a lesson which sticks with me to this day.

One of my good friends in I.T. recommended that while at Cybrary I should get my Security+ certification. It's a great entry-level certification, and it's a door-opener for I.T. roles of all types. It took about four months of hard studying, but I passed the test! Almost immediately a service desk position opened up at my friend's company that required the Security+, and I applied and got it. With Meg's story in mind, I got to know our software development team within the first few months and started studying the tools they used to maintain our applications.

While at the service desk, I worked as hard as I could to learn the job, build a reputation of consistency and excellence in the office, and be open about my career goals with my manager. My manager told me he expected that his service desk technicians would want to move elsewhere in tech and he envisioned the service desk as a training ground for better things. I told him early on I wanted to be a software developer, and if there was ever a fit I would want to check out opportunities within the company.

The Offer

Over the summer of 2023, I worked to earn two required certifications for our software development team. I didn't know if anything would materialize, but I wanted to put myself in the best position in case an opening came up. The manager on our development team included me on some of the team's meetings, and I was given a small application assignment to work on while having down time at the service desk.

In the fall, I was informed that a position would be opening shortly that would be using Pegasystems for development (it's a low-code Platform as a Service (PaaS) for creating business-process apps). The position required a certification for Pega that I did not have (Pega Certified System Architect), but I started studying while going through the application process. The exam was hard, and I failed the first time by one question. The second time, I passed and was offered the role on our software team - I had made it! My first day was December 1, 2023.

The lessons I learned a long the way

It's been a few months since I started my position on the development team at work. I have loved it, but it's been the hardest job I've had. There is a lot still to learn, but my team is really great and has helped me when I have questions or get stuck something. I tried to be as brief as possible while providing as much context as I could, but there were a lot of things I left out in the essence of time. But below are several lessons I want to pass on in hopes that it can help someone else who transitions careers like I did.

Look at where you currently are: if you are already working at a company, see what types of software development opportunities already exist. Find the manager of the Dev team and let them know about your interest. Ask to shadow someone for a few hours, or if there are any volunteer projects you can hack on. Also, ask if you can join their meetings every once in awhile. Also, look at the job board on your company to see what job requirements are provided for the role you want. After you gather this type of information, start studying those languages and tools.
Don't be afraid of the service desk: the service desk is a great place to get your foot in the door. There are many in the I.T. field who will absolutely refuse the service desk ("I just don't want to work with customers"), but don't be that person. The service desk is a straight-up skill-builder and will only help you get better.
You don't need a Computer Science degree or to be some sort of math genius to code: you may already know this, but a CS degree and exceptional math skills are not required. They certainly help for sure, and being good at math is needed if you want to be on the cutting edge of AI and machine learning. But a software developer does not need to have a CS degree. Math-wise, know what PEMDAS is and some basic logic, and you'll be good. Those who require a CS degree are, frankly, way behind the times.
Consistency is the king of learning: having discipline and consistency in learning, especially if you're self-taught, is crucial. Make a goal of spending X minutes a day coding based on your schedule, and really try to hold yourself to it. In 6-8 months of being consistent with learning, you'll be thrilled at the process you have made. (Check out Atomic Habits by James Clear by the way- fantastic book).
Build your portfolio of work: This is a mistake I made and will not make again. When I applied for the developer role at work, I didn't have a portfolio saved to show them what I had done. That almost cost me the job. If you haven't started one yet, start saving your projects to Github. Proof of learning and building side projects is very helpful.
Build your reputation wherever you are: my last piece of advice is almost one of the most important - build your reputation at work. Be professional. Be on time. Find the metrics that you are judged at for work and exceed them. Be friendly with everyone and also be present and visible in the company. This can greatly help you later on. And this is possible even being 100% remote! I was 100% remote at Cybrary and in a vastly different time zone, yet I was active on the company Slack and I went to as many company meetings as possible.

So that's it! That's my story up to this point. I was as brief as I could be, and I left out other things that I may write about in the future (tutorial hell, being distracted by the next shiny object, imposter syndrome). All of these topics happened to me along the way as well. Thanks for reading, and I'll see you at my next post!

Semantic HTML

Aaron McCollum — Sun, 11 Jun 2023 20:49:56 +0000

HTML has both semantic tags and non-semantic tags. Semantic tags use words that help you understand the purpose of that tag, instead of a non-semantic tag that uses a word unrelated to what's going on.

Specifically, **semantic **means "of or relating to meaning in language" according to the trusty Merriam Webster Dictionary.

Practically, an example of semantic vs. non-semantic is:

<div> is non-semantic. It doesn't really explain what's going on here. It's just a div.
<header> is semantic. This tag explains what it's purpose is: it's a header and will contain header information at the top of the page.

Semantic tags are good for SEO and accessibility. Browsers are able to interpret these semantic tags for screen-readers and other software to help make the web as accessible as possible.

Semantic tags that are common are below (along with their meaning):

<header>: usually contains navigation links or header tags at the top of the page.

<nav>: usually contains a nav bar of some sort (lists)

<main>: contains the main content of a page. This can contain article tags, header tags, and others.

<footer>: contains the information at the bottom of a page. Contact information, bottom navs, copyright, terms of use, site map.

<section>: group related content inside of a main div. Usually done by topic.

<article>: contains content that makes sense on it's own. This can be a single article, post, write-up. This would be inside a section.

<aside>: contains information that is not needed but can enhance the information presented in an article or section.

<figure>: you can insert an img inside here.

<figcaption>: inside the figure element, you can insert a caption for the image.

<audio>: plays audio files. It can use the "autoplay" and "controls" attributes to enhance it.

<source>: goes inside the audio element, and you can use the "src" attribute to specify an audio source.

<video>: used for displaying videos. Can take the "src" and "controls" attributes.

<embed>: used to embed content into a site, including audio, gifs, and videos. It can also take the "src" attribute.

In general, it is good to use semantic HTML tags when you can. It assists other devs, helps accessibility software do it's job better, and overall makes the code look cleaner and easier to read.

A Short History on the C Programming Language

Aaron McCollum — Thu, 27 Jan 2022 09:21:59 +0000

The C programming language is one of the more classic languages we have today. C was developed by a computer scientist named Dennis Ritchie, when we worked at Bell Laboratories (affiliated with AT&T), between the years 1969 – 1973. The Unix operating system was new at the time, and Ritchie and his colleagues were developing programs during that time period to do things with Unix.

The language prior to C was simply called the “B” programming language, however that language had shortcomings, such as it was slower and not able to take advantage of some features in Unix. Ritchie took most of the syntax from B, and he added improvements such as having data types and giving the language the ability to represent structured data. Logically, he called it “C.”

In 1978, Ritchie and Brian Kernighan wrote and released a book entitled “The C Programming Language” which for a long time was the unofficial documentation of the language. It would be another five years though before C was ratified, and the first formal version of the language became official. In 1989, the American National Standards Institute (ANSI) standardized the C programming language.

Today, C is still a primary language for operating systems, as Unix and Linux have major parts written in C, and other operating systems like MacOS and Windows also contain a lot of C code. Additionally, other programming languages have C as the “under-the-hood” language, like Python, Java, and C++. Having a good understanding of C can be helpful when working with other products that are developed by the language.

Links to learn more:

"A Brief History of C Programming"

"What is C Programming Language? Basics, Introduction, History"

"The History of the C Programming Language"