DEV Community: Branden Hernandez

A Place To Store Projects

Branden Hernandez — Mon, 12 Jan 2026 16:15:00 +0000

Projects, Projects, Projects. Another year, another set of projects to do.

This year, I have given myself the challenge to do 52 projects this year. Each week, I will be doing a different project. So this is week 2 of Project 52.

GitHub is where all my projects are being stored. Yeah, this is an easy way to store all my projects, but how can I show them off more effectively? Code looks cool, but people want to see things. They say a picture is worth a thousand words, so that's what I'm doing. I'm building a website for all my projects to be in.

This is the game plan. This website will house all my projects. I can add pictures, videos, the whole nine yards. This allows me to show the world my coding abilities and also have a portfolio showcase.

Now it's time to get to work on the project.

The Process

As said before, I have a whole week to do this project. So why did I wait till Thursday to start the project? I don't have much time to make this very polished. Not only do I have to make the project, but I have to write all the documentation, record the GIF, and write this article you are reading now. I mean, as you can tell by reading this, I got it done, but this was super tough. This is only week 2, and I already feel like doing a project every week will be tough. But I got it done.

Due to the time constraints, I have decided to do a basic static website. It's just HTML and CSS. I'm hosting this website through GitHub Pages and GitHub Actions so I can have a CI/CD pipeline for my website. I do have plans to make this website better in between projects. But as one of my requirements, it has to run, and boy does it run.

Since this is a simple static website, I don't think there is a lot I need to say about this. But the most interesting thing I should talk about is how my deployment works. As I said before, it works through GitHub Actions. In the GitHub Pages section, you can deploy your static website using GitHub Actions. It will auto-generate a YAML file to do the deployment.

The only thing I needed to do was update where the site is being stored.

# Upload week2
path: './week-02-website/src/'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4

Now that it's up, here is the website in all its glory.
Wait till next week to see the next project.

Why This Year Will Be Different

Branden Hernandez — Mon, 12 Jan 2026 05:00:00 +0000

New Year, new projects to work on.

With the new year being here, I have some new goals that I want to complete. One of which is coding every day. So this year, I have decided to create Project 52.

Why Project 52

The goal of this project is to create something every week. Yes, every week. The projects could be big or small; it doesn’t matter as long as I build something that I am interested in.

So here is how this is going to work.

I pick a topic. It could be anything.
I recreate something cool I saw or create something that is entirely new.
I get to work on creating the MVP.
At the end of the week, I have to post the project in its state.
It must run and do something.

For more information, you can check out the repo where the projects are being stored.

Why Should You Care

Now, why should you come and join me in this process of building projects?

You would get to see the process of me building something. Not one-off projects that never get finished but small mini projects to test ideas and see where my coding abilities go.

The second reason is that you guys like me or something. Yeah. I honestly don’t know why you would want to watch me do this. I’m just a guy on the internet. But this is important to me.

But mostly, I was inspired by this YouTube where he created 52 projects in a year. So why can’t I do the same?

I also want to be those developers that code every day and have those big, fancy, all-green repos. I think to love something so much and do it every day is really admirable, and I want to emulate that in my work as a developer.

The First Project

Now, the first project is something you don’t have to wait on, but it is done and dusted. I decided to start small with a CLI tool. This tool is similar to neofetch but really, really bare bones. It’s the project from this roadmap. It shows the CPU, RAM, and disk usage. It also shows the top 5 processes for CPU and disk.

This was a pretty fun first project to make as the first entry to Project 52. I was able to learn about a tool called top, and that is what I leveraged to make the CLI tool.

top -n $numberofprocess | head | grep $filter

The program works by calling top, filtering down to the number of lines I need using the -n flag, piping that output into head, and then piping it into grep to filter for the specific lines I needed. I printed the final output to the terminal, which is how I got the results shown above.

More projects to come. The next one should be really cool.

The Power of Shared Definitions

Branden Hernandez — Mon, 13 Oct 2025 05:00:00 +0000

We’ve all been there. You walk out of a meeting thinking everyone’s aligned, only to realize later that half the team walked away with a completely different understanding.

It usually happens because of one simple thing: definitions weren’t clear.

Take the word “performance.”

To a developer, it might mean how fast code executes.
To a product manager, it could mean how quickly features are delivered.
To a customer support rep, it might mean how happy users are.

Same word. Three totally different meanings.

And what happens next? Endless back-and-forth, rework, and wasted time — all because nobody stopped to ask, “What do we mean by this?”

Why Definitions Matter

Definitions are like the foundation of a building. If they’re shaky, everything built on top will eventually crack. Clear definitions:

Remove assumptions
Speed up decision-making
Prevent people from talking past each other
Keep meetings from dragging on unnecessarily

How to Fix It

Clarify early. At the start of a meeting, take 1–2 minutes to define the key terms that will come up.
Ask the “dumb” question. If you feel misalignment, pause and say, “Before we continue, can we clarify what we mean by X?”
Document it. Write down the agreed-upon definitions so the team has a shared language moving forward.

It may feel like slowing down, but it actually speeds everything up. The small act of aligning on definitions saves hours of confusion later.

Final Thought

Shared definitions aren’t about nitpicking words — they’re about making sure everyone truly understands each other. Because progress only happens when the whole team is on the same page.

Boosting Dev Productivity with Multi-Threading

Branden Hernandez — Mon, 06 Oct 2025 16:30:00 +0000

Nothing drains your energy faster than waiting on a slow script. That was my life until I discovered the power of multi-threading.

The Problem

I was tasked with deleting our old Cumulus pipelines.
A senior dev handed me a simple Bash script that went through a list and deleted each one.

Deleting a single pipeline wasn’t hard, but it took five minutes per pipeline. And there were 365 pipelines. You can do the math that’s over 30 hours of pure waiting.

My First Attempt

I thought, “There has to be a faster way.”

Since it was just a Bash script, I figured I could edit it. My first idea was to use tmux, spinning up multiple terminals on my EC2 instance. That would let me run several deletions in parallel.

But no luck I couldn’t install tmux on the server.

The Breakthrough

I turned to ChatGPT for advice. That’s when multi-threading was brought up.

Instead of waiting for one pipeline to finish before starting the next, I could run many deletions at the same time.

That one change meant I could delete as many pipelines at once. No babysitting, no endless waiting just blazing through the list.

The Result

What I thought would take a full week, I finished in under 5 hours.

I even had time left over to work on other tasks, doubling my productivity for the day.

When I shared the approach and wrote up documentation, our senior dev was impressed. What started as a painful, tedious job turned into a chance to show creativity and initiative.

The Lesson

Don’t accept “slow” as the default. If you think there’s a faster way, chase it down.

A little creativity and the right tool can turn a week long task into a single productive afternoon.

I Challenged Myself To Use The Hardest Editor

Branden Hernandez — Mon, 11 Aug 2025 16:30:00 +0000

Vim is known for having a very high skill gap. People that use it are seen as keyboard wizards that 10x their development. Its like they are typing some magic spell on the keyboard. Its a skill that every developer dreams of having. I am that developer that wants to have that skill.

For the next week I will be using exclusively Vim. So here is how it went.

Now here are the rules for this challenge:

I will write this article in Vim.
I will write and execute code.
I will use it for a whole week.

The Start

This challenge doesn't sound very hard at first but I was in for a rude awakening. I booted up Nixos and low and behold there was no Vim. I have always heard that vim is installed by default but it wasn't. This was the first roadblock of many.

After installing Vim I got to work. I knew Vim was bare but I didn't know it was, THIS bare. It lacked a lot of features that I became a custom to with VS Code. I had to learn a whole new system. I didn't feel fast like the 10x developers, I felt like I was going at a snails pace. Productivity was hard and the keybinds were even harder to master. If I didn't hit the right combo I didn't get to do what I wanted.

Opening Vim was just so hard. I didn't want to work on anything if it wasn't on VS Code.

NeoVim

Trying to stay consistent with Vim is the hardest thing I have done. But yet NeoVim came to the rescue. NeoVim is a fork of Vim and it is basically an IDE. I decided to use LazyVim and it changed my life.
Syntax Highlighting, cool look, keybind helper, and spell check, these are the things that I need out of the box. This has helped me feel like I know what I am doing and it makes vim easier. I am able to see what keybinds I can use at a given moment so that I am able to hit the right combo every single time. I don't need a mouse anymore, my keyboard is all I need to do the work.

I even found out you can install plugins like in VS Code. I can make this as bare or as complicated as possible. I was also able to install plugins for LaTex and have some pretty good support for that.

Writing

Now that I got my environment set up to my liking. Writing code is now the focus. I had two task that I needed to update my resume in LaTex so this was the perfect task for the job. I have already installed the necessary tools needed for the job.

Writing was not that hard. The experience was just me trying to get use to Vim Motions. But deleting things felt amazing. If I didn't like a line dd. Oh I don't like the rest of the sentence I am writing d$. I need to go to the top of the page to import a new module gg.

Moving the cursor felt great. Most importantly FAST. I tell it where to go at all times. I became the wizard that I have seen or at least a novice one.

Takeaway

I have finally joined the church of Vim. As you can see I was able to post this article all using Vim. I like the power that this gives me. It was hard but I think with more time I will be only using vim into my workflow. Like with my Nixos With time I can see myself using these tools more and more. I am one step closer to being a 10x developer.

I am still new to this and I can use some help learning new things. If you have any tips or tricks please let me know in the comments below.

I Tried NixOS for a Week So You Don't Have To

Branden Hernandez — Mon, 04 Aug 2025 16:58:00 +0000

Linux is something I've wanted to try for a long time. I've been looking for an alternative to Windows, especially now that Microsoft is integrating AI into everything. Don't get me wrong, I like AI but I don't need it embedded in every part of my system, especially my personal computer. So I started weighing my options and finally decided to give Linux a shot.

Everyone talks about the benefits of Linux, but what had always kept me away was the overwhelming number of distributions. There are so many to choose from, and none of them ever felt like the right fit. I wanted something that worked out of the box without too much setup. I wasn't interested in reinventing the wheel. I just wanted a reliable, customizable operating system that wouldn't fight me every time I needed something simple.

After some research, I landed on NixOS.

Why I Chose NixOS

The things that stood out to me were declarative configuration, reproducibility, atomic upgrades and rollbacks, system stability, and the Nix programming language. These features felt like the answer to everything I didn't like about traditional Linux distributions.
I decided to try it out for a week and see if it was something I could stick with long-term.

What I Liked

After a week, one thing became clear: when NixOS works, it really works. If I need to install something, I just search for it on nixpkgs, add one line to my configuration.nix, and apply the change. I don't have to worry about missing dependencies or messing up my system. If something fails, it simply doesn't install, and my system stays clean.

The declarative configuration is probably my favorite part. The Nix language feels like a mix between JSON and functional programming - it lets you describe exactly how you want your system to be. I can make deep customizations without editing dozens of config files scattered across my system. I just edit one file and rebuild.

Another underrated feature is reproducibility. If someone else has Nix installed, I can share my configuration and they'll get an exact replica of my system. That's huge. It's like sharing your entire dev setup with just one file.

What I Didn't Like

That said, there were definitely some pain points:

You have to update everything through the config file. While it's great for system-level installs, having to declare simple apps like Google Chrome in the config file feels tedious. Yes, you can install things outside of Nix, but doing so breaks the beauty of reproducibility.
Another layer of abstraction. Managing your system through config files sounds great in theory, but in practice it can get muddy. Sometimes I'm editing dotfiles, sometimes it's the configuration.nix, and sometimes it's service-specific files. It's hard to know where to make changes unless you dig deep.
Flakes sound powerful, but are confusing. Flakes are a newer way to manage your Nix setup with better structure and pinning. In theory, you can use a flake.nix and flake.lock to lock in your config, dependencies, and dev environments. In practice, it's a bit of a headache to set up and adds even more abstraction. I can see the potential, but it's not beginner-friendly.

Final Thoughts
Overall, NixOS is a brilliant concept - and for the right kind of user, it's a dream. It's stable, customizable, and once set up, incredibly smooth to maintain. But for someone just getting started, it can feel like a lot. The learning curve is steep. If you're okay with writing config files and debugging strange issues from time to time, you'll love it.

After a week, I'm not ready to make NixOS my daily driver just yet. But I'm not giving up on it either. I see the potential, and with more time and tweaking, I could see myself fully transitioning.

If you're curious, try it in a VM or on a spare machine. You might be surprised how much you learn - not just about Linux, but about your own development workflow.

I Thought Networking Was Useless. I Was Wrong

Branden Hernandez — Mon, 28 Jul 2025 16:12:00 +0000

Networking changed everything for me and here is how.

I'm like your stereotypical developer , awkward, introverted, and with very little social skills. I've always heard that networking is important. People say you meet lots of others, build connections, and grow your career. But for someone like me, the idea of walking into a room full of strangers was terrifying. Still, after getting laid off in 2022, I knew I had to try something different.

At the time, I was looking for a new job in tech. I felt like my role didn't appreciate me as a developer. I felt like a tool that was being used. I didn't like the constant sense of uncertainty within the company. So I decided to attend a few networking events. This was way out of my comfort zone.

I started by searching online and downloaded the Meetup app. That's where I found a community called Grammerhub. They met online through Discord, which felt like the perfect entry point for someone like me. I joined and quietly listened in on their Monday sessions, where they discussed different tech topics. I was excited at first, but quickly felt like I couldn't relate to the others. They were all smart and confident - I felt like an imposter. Eventually, I stopped attending.

Still determined to grow, I started going to in-person meetups for developers in my area. I polished my resume, practiced my introduction, and gave it my best shot. But these events didn't turn into job offers or meaningful connections. No one even wanted to add me on LinkedIn.

I asked why and got honest feedback: my LinkedIn was bare. No one knew what I did or who I was. And they were right. I had barely filled out my profile. It was just my name and my resume. So the very next day, I gave my LinkedIn a full overhaul. I added projects, wrote a proper headline, and cleaned up the layout.

As I kept attending events, I started to get a few connection requests here and there. But it still wasn't what I had hoped for. I tried talking to anyone who would listen, but the people I really wanted to talk to were always surrounded. I felt like I had to fight just to get a conversation. And even then, it often led nowhere. Everyone wanted a job. The competition was intense.

After about a month of this, I felt like I had hit a wall. I had maybe ten new people added on LinkedIn, but no real leads. Then, one Monday afternoon, I opened Discord and saw that Grammerhub was having another Learning Day. I decided to join.

This time, something clicked.

There were people just like me - developers in transition, trying to improve, looking for opportunities. I finally felt like I belonged. This was a true network, a group of individuals who supported each other and wanted to grow together. Everyone was open, willing to help, and ready to share knowledge. It was refreshing.

After that night, I started participating more. That's when I met Allen, the person who created Grammerhub. Allen was an amazing leader who genuinely cared about helping others grow. A great mentor - just don't let him near production, he wasn't the best coder.

Allen invited me to join a group project the community was organizing. The idea was simple: we'd be put into random teams and build a website under certain constraints, with a tight deadline. This was right up my alley. I had done similar things before, but my coding skills were rusty. I hadn't coded in nearly a year. I remembered some things, but had forgotten a lot. You know what they say - if you don't use it, you lose it.

So I took it as a challenge. My team and I got to work and built the website within a week. It felt amazing. Then, we were asked to rebuild the site using Solid.js. I had never used a JavaScript framework before, so this was new territory. We took two weeks and got it done.

After that, we had to host it using Netlify. That part was easier for me - hosting was something I had done in my job before, so I got it done in a couple of days. These projects weren't just technical practice - they were real experiences that helped rebuild my confidence as a developer.

But Grammerhub wasn't just about code. I also attended their networking events. That's where I finally met the people I'd been chatting with online. It was great to connect in person and share stories. One event even had a LinkedIn representative who taught us how to improve our profiles so recruiters would actually look at them. They also explained what building a network really means and how to do it well.

I was blown away. I realized how wrong I had been about LinkedIn. I had been treating it like a static resume when I should've been using it to build relationships. The kind of network I had in Grammerhub - encouraging, collaborative, growth-focused - was exactly what I needed to recreate on LinkedIn.

As Grammerhub grew, something amazing started happening. People in the community began landing jobs. And because we had such a strong bond, those who got hired started recommending other members. That sense of pay-it-forward community created a ripple effect of success.
That's when I finally understood the real power of networking.

It's not about how many people you meet. It's about connecting with the right ones. It's about being part of a space where people want to help each other grow. Networking helped me find confidence, community, and clarity in my career path. And most importantly, it showed me that I don't have to go it alone.

Paid to Wait, Pressured to Deliver: My First Coding Job

Branden Hernandez — Mon, 21 Jul 2025 16:30:00 +0000

My first coding job was not what I expected. I was getting paid to do nothing! Or so I thought.

I landed it straight out of college, and at the time, I thought I had hit the jackpot. A full-time coding job after a simple interview process? It felt too good to be true, and in many ways, it was.

Training Days

Orientation started with a group training program. We took classes and had to pass tests on Java, MongoDB, and Splunk - tools I was already familiar with from college. Some of my new coworkers, however, struggled. Curious, I asked around about their backgrounds. To my surprise, most didn't have a programming background at all.

That was red flag number one.

Still, I continued with the three-month training program and passed everything with flying colors.

The Reality Sets In

After training, we learned how the company actually worked. We were told that we needed to apply to internal "projects" to stay employed.
That was red flag number two.

As it turns out, this wasn't a traditional tech company. It was a recruiting agency. They hired a wide range of people, trained them, and then placed them at client companies based on skill fit. We were contractors without official contracts or clear expectations.

At first, I didn't worry too much. I was still getting paid while waiting to be staffed, and they covered the cost of external training. It seemed like a decent deal.

Then came the kicker.

If you didn't land a project within a set timeframe, you'd be fired and possibly asked to pay back the money you earned during that time.

Stress hit me hard.

Hustle Mode

Over the next three months, I gave it everything I had. I applied to every internal project I could and earned as many certifications as possible in Python, JavaScript, Java, web development, and databases. I didn't want to take any chances.

The consistent paychecks kept me going. Every two weeks, I got paid, even though the uncertainty hung over me like a cloud.

Eventually, I landed a project with Kraft, working on their DevOps team focused on cloud solutions using Azure. My main responsibilities included fixing virtual machine images, configuring security groups, and managing user access. While I didn't get to do much coding, I learned a lot about cloud architecture.

One highlight was building a Python script that scanned virtual machines for suspicious user activity and shut them down automatically. That was a proud moment for me.

After three months, Kraft laid off all of us contractors due to budget cuts. Just like that, I was benched again and had to look for the next opportunity.

Back on the Bench

Despite being promoted to "senior" after my work at Kraft, I still had to find a new project. I used that time to dive deeper into Azure, earned another certification, and kept applying to internal projects. Six months and two certifications later, I landed a new role with Rosenthal Collins Group.

This time, I was tasked with rebuilding their HR employee portal using Flask and SQL. It was a solo project, and I wasn't very experienced with Flask, but I did what I could. After three months, the project was paused because of budget constraints, and I was asked to leave.

Time for a Change

At this point, I was tired. The constant job instability and pressure were overwhelming. The paychecks were nice, but the uncertainty wasn't worth it anymore. I decided to stop looking for new internal projects and instead spent my time on the bench applying for jobs elsewhere.

I knew I was lucky. Some of my coworkers got laid off after only a few weeks on the bench, and others never found a project at all. A lot of the layoffs felt random, and I couldn't understand how the company operated this way. It was nice to have steady pay, but it felt like I was unemployed most of the time.

I didn't feel like a developer. I felt like a tool that was moved around as needed, without being appreciated. I wasn't learning much at the companies I was placed with. I jumped from one contract to the next without really understanding how each company worked. It was always fast learning with very little time to deliver quality work. Once I got the hang of something, I'd be off the project due to budget constraints.

This was technically my first job, but I ended up working three different roles under the same title. I didn't get to sharpen my skills the way I wanted. Instead, I became a generalist who could do a bit of everything, but without deep knowledge in any one area.

A Brighter Chapter

Thankfully, my journey ended on a high note. After a year of sitting on the bench, I was officially laid off, but to my surprise, I wasn't asked to pay anything back. I had been with the company long enough that their repayment clause no longer applied. It was a huge relief.

During that year, I kept busy. I took on part-time and freelance gigs in the restaurant and Audio-Visual space and sent out countless resumes. That hustle paid off. Before officially leaving the company, I landed a role at The Coder School. A place that would become one of the most meaningful stops in my career so far. There, I discovered the joy of teaching and mentoring, and I learned how to make a difference, one line of code at a time.

Looking back, my first job wasn't what I expected, but it taught me a lot: how to adapt quickly, stay resilient, and find purpose in the chaos. And most importantly, it reminded me to always strive for better.

Too Many Handshakes: A Tale of Corporate Chaos

Branden Hernandez — Mon, 14 Jul 2025 16:29:00 +0000

Why are there so many handshakes involved in getting anything done at work? You'd think changing the color of a button wouldn't require 10 layers of approval, yet here we are. Let me tell you about one particularly frustrating experience I had that perfectly sums this up.

I was assigned a seemingly simple task: migrating our email service from SparkPost to Amazon SES (Simple Email Service). The majority of the work was already completed in our test environments. Now it was just a matter of replicating those steps in production. Easy enough, or so I thought.

The first step was to set up the necessary production accounts. To do that, I had to submit an internal request. That request didn't go to my manager, it went straight to his manager. Odd, but I went along with it. Once they approved it, the ticket came back to me to confirm the approval. Yes, I had to approve the approval.

The request then moved on to another team. I showed my manager, and he told me to wait until the next day. Some work should be done. I came back, expecting progress. Nope the ticket was still in the same state. I followed up again, only to be told that my manger's manager still hadn't approved it. When I questioned why so many layers of approval were needed for something that had already been greenlit twice, my manager realized something was off.

After investigating, we found the ticket had been rerouted to yet another team for review. And that my manager's manager was just put as a placeholder since they are the first level of approval. At this point, no work had been done. Nothing had changed in production. We were just stuck in a bureaucratic loop of people approving other people's approvals.

The kicker? The teams involved were under our team in the org chart. This change had to pass multiple tiers of approval for a configuration I was more than capable of executing safely. Meanwhile, I was still waiting for the production accounts to be created to start the actual task.

I decided instead of waiting, I went ahead and completed steps 2 through 5 of the migration. They were quick updates to YAML files no approvals needed. But step one? Still pending. It was absurd. This was supposed to be a one-day task. We are 3 days in and still hadn't completed the most basic prerequisite.
On day four, I finally got an update, my request was denied. The reason? There was "no production account set up." That was literally what I needed the approval to do in the first place. I was stunned.

I resubmitted the request. Three more days later, I finally got the green light. Within ten minutes, everything was up and running. That's right, ten minutes. After a week of waiting through pointless red tape, the actual task took less time than making a cup of coffee.

I asked my manager why the process was so convoluted. His answer?

"Honestly, I don't know. The whole thing is just dumb."

And that sums it up.

If you had any experiences like mine tell me about it in the comments.

FlavaQuest - Month 3: Losing Motivation

Branden Hernandez — Mon, 07 Jul 2025 16:34:00 +0000

I hit a wall, a motivation wall.

For the past two months, I've been building FlavaQuest with a lot of excitement and focus. But this last month? It's been tough. Even with all the documentation and planning I did previously, I hit a motivation wall.

The Feature Creep Trap

I had high expectations of many different features I wanted to add. I wanted the app to look good for the potential user that I would have. I wanted to add so many things to the app when in truth I didn't plan out those features. I put myself in a hole where I felt overwhelmed by the number of things I wanted to add and ended up not adding anything.

That spiraled into feeling overwhelmed. I kept thinking, How can I build all this? But here's the thing: I don't even have users yet. Who was I building all these features for? Instead of narrowing my focus, I was expanding it endlessly. And that ended up killing progress.

I got so caught up in the potential that I didn't do anything. I really needed to stick to a MVP that is easily obtainable. The MVP I had last month was still too big that I lost the vision.

Losing Interest in the Project

This one's hard to admit. I lost interest in FlavaQuest.

That doesn't mean I'm giving up on it. I still want to finish the app. But right now, it's not my priority. Life threw more responsibilities my way, and my energy shifted. It's just not exciting me at the moment and that's okay.

FlavaQuest is still my baby. It's something that I truly believe in. I know that I will finish this project to the best of my ability.

I Wanted to Build Other Things

Building smaller projects was so much easier to do. I was able to pump out more projects on a smaller scale that allowed me to feel more productive.

Learning felt fun and because those projects were smaller, the scope of the project was easier.

These projects had clearer defined goals. A lot of which didn't need loads of documentation for. Something very simple that could be done in a weekend. And it was so much more fun and rewarding. I got instant feedback from these shorter form projects.

I felt like my skills as a developer were growing because I was exposing myself to new technologies. What makes this even better is that I was able to finish a lot more projects and prove to myself that I can finish something.

These smaller, focused project like:

My Chess Stats Card
Updating my GitHub Profile README
Rebuilding my personal website (more on that soon)

These projects were clear, rewarding, and gave me immediate feedback. They helped me grow as a developer and gave me a sense of accomplishment, something I really needed.

Each project taught me something new. I felt like I was exploring again. And most importantly, I was finishing things.

So, what now?

I'm still building FlavaQuest. I'll keep sharing updates about my journey, because building in public is something I really enjoy. But I'm also giving myself space to explore other ideas.

Let me know in the comments:
How do you stay motivated during long-term side projects?
Have you ever stepped back to rediscover your spark?

From Rejection to Redemption: How I Landed My SRE Role

Branden Hernandez — Mon, 23 Jun 2025 16:46:00 +0000

Countless applications. Hundreds of rejection emails. Failed interviews. It was easily one of the worst experiences of my career. Let me tell you how I eventually found my current job.

The Layoff

It was May 2023. I saw a new meeting pop up on my calendar with no description, just an invite.

Instantly, I knew what it was about. Companies were laying off developers left and right. I had already heard rumors about cuts at my company too.

When I joined the call, I saw my HR representative. She told me that I was being laid off along with the rest of my team.

My heart sank.

I didn't know what to think or do. I accepted it quietly, packed up my things, and left the company that same day.

It was a weird feeling, I'd never been laid off before. I'd always left companies on my own terms. This was completely different. The first thought that hit me: "How am I going to pay the bills?"

I needed to find another job. Fast.

The Grind Begins

I brushed up my resume and hit the job boards. LinkedIn and Indeed were my first stops.

I applied to hundreds of jobs. No hits.

Then I found a listing for a part-time teaching position at a coding school called theCoderSchool. I figured it could help me cover some bills and keep me busy while job hunting.

I took the job and honestly, it turned out to be one of the most rewarding experiences I've ever had.

While working there, the owner of the school heard about my situation and recommended a platform I hadn't heard of before: Dice.com.

I gave it a shot. Almost immediately, my phone started ringing. I landed a bunch of interviews but I failed all of them.

Reality Check

Through all these interviews, I realized something hard to admit: I wasn't a strong coder.

At my previous job, coding wasn't the main focus. I mostly worked on cloud infrastructure and basic scripting. Looking back, I was a DevOps Engineer without knowing it.

But now, I was applying for pure software developer roles I wasn't ready for.

I needed to level up. Fast.

I started grinding LeetCode every day. I joined a community called Grammerhub to practice and get feedback. Slowly but surely, I started making progress. I was getting further into the interview process.

But still no offers.

At this point, I had applied to over 400 jobs.

Mindset Shift
Around that time, something shifted in my head: "It's not me that's the problem. These companies would be lucky to have me."

With that mindset, I pushed harder.

I heard about a big Google event happening nearby. This was it. My shot.

I printed 100 copies of my resume, dressed sharp, and treated the event like a mission.

I networked like crazy, handed out resumes left and right. I learned a lot including how tough it is to get referred into Google. Unless you personally know someone well, it's nearly impossible.

Still, I didn't let that stop me.

I kept applying. At this point, I was averaging 10-20 applications a day.

Leveling Up

I built my personal website: branden-hernandez.com. I knocked out 50 LeetCode questions. I kept attending networking events.

At one event, things felt different. Everyone I met was in the same situation as me. Jobless, frustrated, applying to hundreds of roles with no luck.

Talking with them made me realize: I'm not alone. It gave me a second wind to keep fighting.

The Breakthrough

A month into the grind, I finally got an email for a promising opportunity. I scheduled the interview two rounds later, I got an offer.

They liked that I was teaching kids how to code. They liked how I explained complex ideas clearly. They were impressed with the side projects I built while in Grammerhub.

Best of all? There was no LeetCode grind. No "whiteboard coding" or crazy technical interviews.

They were looking for someone to mentor into a Site Reliability Engineer and I fit the mold perfectly.

This was the resume that got me hired:

Final Thoughts

Job hunting is brutal. You can do everything right and still not land anything for months.

But if you're reading this and feeling stuck remember: You're not alone. Keep improving, keep learning, and keep showing up. Someone out there is looking for exactly what you bring to the table.

Keep pushing. Your breakthrough is closer than you think.

Vibe Coding Isn't Magic - But It Made Me a Better Developer

Branden Hernandez — Mon, 16 Jun 2025 16:58:00 +0000

I Tried Vibe Coding. Here's What I Learned.

For the past few weeks, I kept hearing people talk about this thing called Vibe Coding. It sounded cool, but I had no idea what it actually was. Was it just coding with lo-fi beats playing in the background? Was it a new framework? A mindset? Turns out, it's more of a workflow and philosophy than anything else.

So, I decided to give it a try.

I wanted to see what it was like to build a small project from scratch while letting my vibe guide the process.

Setting the Stage

To test this out, I needed a project. Something small enough to finish in a few days, but big enough to challenge me and push me out of my comfort zone. That's when I remembered a GitHub profile I had seen:
👉 sciencepal's GitHub profile

They had a chess graph embedded right in their README, pulling live data from Chess.com. As someone who plays chess regularly, this immediately caught my attention.

That was the spark: I was going to build a Chess.com stats card for GitHub READMEs.

The Idea

Here's what I wanted this project to do:

Fetch my current Chess.com stats using their public API
Show my ratings for Daily, Blitz, Bullet, and Rapid games
Display my profile picture and current league
Package all of that into an SVG so I could embed it in my GitHub profile

Sounds simple, right? Yeah… not quite. I had no idea how to do any of these things:

Work with the Chess.com API
Render dynamic data into an SVG
Host and serve the card in a way that works on GitHub
Deploy a project with Vercel
Create API routes from scratch

But that's what made it the perfect "Vibe Coding" project.

Getting Into the Flow

The whole idea behind Vibe Coding is to stop overplanning and just start building with AI. You tell AI what to do and AI spits out the code you need.

So that's what I did.

I opened up ChatGPT and typed my first prompt:

"Create a chess card stat app that pulls from the Chess.com API and outputs it to an SVG."

Boom! ChatGPT gave me a sample API call in JavaScript and told me how to run it. I tested it in and saw the data coming through. So far, so good. The first version worked! Kinda. I was able to get the name and picture, but the ratings were not showing.

I asked for a few tweaks, but this is where things started to go off the rails.

When AI Gets in the Way

Instead of tweaking the code, ChatGPT rewrote everything. The new version didn't work. I couldn't figure out what broke. I asked it to generate another version, but that didn't work either.

I showed it the original code and asked it to iterate on that and yet it still didn't work. At this point, I was frustrated. I felt like I was fighting with the AI instead of coding.

So, I took a step back, looked at the original working version, and started reverse-engineering it. This turned out to be a great move. By digging into the logic, I started to understand the code. It wasn't about copying and pasting anymore, it was about learning.

That's when I remembered: AI should be a learning tool, not a shortcut.

Breakthroughs and Setbacks

Once I had the API part down, it was time to render everything into an SVG. This part was tricky. I didn't know how to generate an SVG dynamically with data. So I asked ChatGPT.

It gave me an SVG template, but I didn't understand what it was doing. I took a break.

The next day, I started Googling more about SVGs and realized something huge: SVGs are basically HTML with a twist. You can style them with CSS-like rules and treat them almost like regular markup.

That changed everything.

Suddenly, I could look at the AI's SVG output and understand what it was doing. I started tweaking the styles, moving elements around, and customizing the layout.

Time to Deploy

With the card working locally, it was time to put it online. I had heard a lot about Vercel, but I'd never used it before. I figured it was worth a try.

I asked ChatGPT how to deploy a basic project to Vercel. It gave me step-by-step instructions and it worked! Almost.

The site deployed without any errors, but the SVG wouldn't render. After some back and forth, ChatGPT explained that the image needed to be served through an API route if I wanted to embed it properly.

This was all new territory for me. I had never created API routes or serverless functions before. But again, with some help from AI and some trial-and-error, I got it working. I moved the logic into the /api folder and, just like that, the card appeared.

The final hurdle was getting my Chess.com profile picture to render. It turned out that I needed to embed the image directly into the SVG using Base64 encoding. I asked ChatGPT how to do that, and it gave me a neat little function. Boom! Everything was working.

What Vibe Coding Taught Me

This project took about three days. It wasn't smooth sailing the whole time, but I learned so much.

Here are my biggest takeaways:

1. AI isn't magic but it is powerful

It's tempting to let AI code entire projects for you, but that usually leads to confusion and broken code. The real value is in having it explain concepts and fill in the gaps.

2. Work in small, meaningful chunks
The smaller your prompts and changes, the better results you get. Instead of asking ChatGPT to "build a full chess card," I got better outcomes by asking things like "How do I embed an image in an SVG?" or "How do I fetch data from this endpoint?" AI is just Google with less steps.

3. Learning > Speed

When I tried to go fast, I hit roadblocks. When I slowed down to learn, I made real progress. The best part? I came out of this project with actual skills I can use again.

4. You still need to understand your code

Vibe Coding is about flow, but not blind trust. Let the AI help you learn, not do everything for you. Understanding your own code is what makes the process satisfying and sustainable.

Final Thoughts

Vibe Coding isn't a silver bullet. You're not going to build the next billion-dollar app overnight by prompting an AI. But you can use this method to unlock creativity, stay in flow, and learn faster than ever before.

For me, it's not about replacing my skills with AI it's about enhancing them. AI is a powerful tool.

I'll definitely keep using this approach for side projects, personal tools, and experiments. I'll just do it with a "learn-first" mentality, not a "solve-this-for-me" mindset.

Check out the project here.

👇 Have You Tried Vibe Coding?

I'd love to hear your thoughts. Have you tried building a project this way? What worked? What didn't? Would you do it again?

Drop a comment below and let's talk about it 👇