DEV Community: Amanda Mayfield

Why did no one tell me how amazing Git Bisect was

Amanda Mayfield — Wed, 04 Feb 2026 20:26:47 +0000

Okay, so, I do my best to stay on top of technologies and tools, but with so many options in our ecosystem, its all too easy for helpful tools to slip through cracks. Well, this post is to make sure Git Bisect doesn't slip by for you!

I've been redoing my portfolio site and have continued to use the space theme of my original portfolio. (Don't judge, I'm a space nerd) I made a really cool, pure CSS, animated star field component for my banner image. I was very set on its design and it was the first component I made on the site.

My home page layout was a bigger puzzle for me and I went back and forth on it, moving things around, rearranging, etc. I finally got to something I was happy with using a bento grid layout and was super pleased. That is, until I scrolled up and saw my star field header had half stopped working.

Uh oh. When did that happen? Where did it happen? I had been distracted by my bento grid and I'm someone who also makes it a practice to use atomic commits with my changes, so I had like 20 commits to look through.

I lamented this to my husband, a fellow engineer, who said "Oh, just use Git Bisect." Huh wha? So, off I went and, you guys, it was mind blowing to me. I've been a software engineer for 7 years and no one had suggested this to me before.

How it works, to quote the docs, by "using binary search algorithm to find which commit in your project’s history introduced a bug".

git bisect start

You first tell it the commit where you first noticed the bug is "bad".

git bisect bad # Current version is bad

Then you go back to a commit that you know worked correctly and label it "good". The example uses a version but I just used my commit SHA. It's better to err on the side of caution and search widely, so I used a pretty early commit.

git bisect good v2.6.13-rc2 # v2.6.13-rc2 is known to be good

Then you're off! The algorithm picks a commit between those two goal posts and asks you whether the selected commit is "good" or "bad". It continues narrowing down until it finds the exact commit that introduced the bug. Et voila!

Pro-tip from the trenches: If you land on a commit that is so broken it won't even build, don't panic. Just type git bisect skip to jump to the next one.

So with that in mind, I narrowed down the commit that was the problem in moments. As I looked through it, I immediately saw the issue. Somehow in my bento grid madness, I had put a margin: 0 auto instead of a margin: 0 on the star field. Since my CSS animation relied on randomly generated pixel positioning per "star", that "auto" centering was shifting the entire canvas offset and clipping the animation.

D'oh! That was definitely not needed and so I removed it and was happy to see my full star field rendered in all its nerdy glory. I was able to track down the problem in mere minutes thanks so git bisect.

Important! Don't forget to "clean up" the bisect state, or you'll be stuck in a "detached HEAD" state, and your Git will act very strangely when you try to commit your fix. Use this reset command to get back to your normal work.

git bisect reset

Now, if you really want to feel like a wizard, you don't even have to manually check the site. If you have a test script (like npm test), you can just run:

git bisect run npm test

Git will literally do the binary search for you while you go grab a coffee. It runs the test, marks the commit, and stops when it finds the bug. Though this would be dependent upon having a test suite; still gotta test manually for a visual bug.

So, I highly recommend you put this one in your toolbox, if it wasn't already. Now, this will only be helpful if you use proper atomic commits and don't introduce multiple, massive changes in one commit. That's a good habit to instill anyway. :)

Framer Motion and the "Magic" of CSS Fundamentals

Amanda Mayfield — Mon, 26 Jan 2026 16:57:25 +0000

I’ve been using Framer Motion for the rewrite of my portfolio site lately, and honestly? It’s been such a treat!

My old site was built with the "old school" stack: HTML, CSS, vanilla JavaScript, and a dash of PHP for interactivity. You kids these days on my lawn don't know how lucky you have it! These incredible animation libraries are a fun, fast way to add high-end polish to your applications or websites.

But don’t be fooled! It is still vital to understand the "boring" fundamentals of CSS. If you don't know what these libraries are doing under the hood, you’re going to have a hard time debugging them when the "magic" breaks.

The Tutorial vs. Reality

I recently followed a tutorial for creating an infinite scroll gallery. You know the type, where images glide horizontally across the screen forever. I followed the instructions to a T and was thrilled with the result... until I tried to scroll sideways on my trackpad.

Oops! The entire gallery was bleeding off the edge of the page, creating a massive horizontal scrollbar that shouldn't have been there.

Digging into the Code

As I looked through the implementation, I found the culprit in the CSS. The tutorial had the container set to position: absolute with left: 0.

In this implementation, the scroll animation from Framer Motion is being set on the '.skill-scroll' component. The tutorial had the container written as position: absolute with a left: 0, presumably to position the container to the left of the screen and remain stationary through the scroll.

The goal was likely to keep the container stationary while the images moved inside it. However, this created two issues:

Redundancy: Framer Motion’s animation was already handling the x (horizontal) placement using transforms. The left: 0 property wasn't actually doing anything useful.
The Overflow Trap: In CSS, overflow: hidden doesn’t always "catch" elements that are position: absolute. Unless the parent container is also positioned (like position: relative), that absolute child will just fly right past the boundaries.

The Fix

Now, I could have added a wrapper element with position: relative to force the overflow to behave, but why add more code to fix a problem that didn't need to exist? I simply removed the absolute positioning entirely. Voila! A perfect, contained, infinite scroll.

The Takeaway

I was able to solve this in minutes because I understood how CSS positioning interacts with the DOM. If I hadn't known those basics, I might have assumed the bug was a "Framer Motion glitch." I could have spent hours scouring documentation for a library setting when the answer was just one line of CSS.

If you’re learning your way into tech right now, I do encourage you to have fun with the libraries. They are powerful tools! But focus on the fundamentals first. Use libraries to shorten your implementation time, but don't let it replace your understanding.

Please let me know if this was useful to you! Happy coding.

The Tower of Hanoi and why AI won't make you a skilled developer

Amanda Mayfield — Sun, 07 Dec 2025 02:15:20 +0000

One of my classes that I remember most fondly when I was getting my degree was called "Logic in programming". This was at a Dallas County Community College and, frankly, was an absolute gem of a class that was worthy of an ivy league school.

The very first day our teacher gave us only task: solve the Tower of Hanoi puzzle and break it into precise instructions. I've always been someone who enjoyed puzzles and took to the task with enthusiasm. All semester, it was mostly those types of tasks as I slowly learned Visual Basic and C#. He was teaching us how to solve a problem; not how to code. I treasure that experience as one of my most formative as an engineer.

Continuing from my previous post Being a JavaScript Dev vs. a Framework Dev, we now get into even deeper pondering. I worry that what is happening with Javascript and frameworks, is also happening with engineering as a whole, thanks to the prevalence of AI. Many newer developers are no longer learning how to solve problems, but simply how to use a specific tool, resulting in an AI-first approach that gives false confidence about the difficulty of programming. Learning how to swing a hammer well doesn’t make you skilled at building a wooden shelf.

I recently heard a story from a friend. They have been occasionally mentoring someone trying to break into her first role in tech. She was lamenting that she seemed to reach a plateau in her coding skills and was struggling to debug something. With questioning from my friend, she admitted the root of the problem: she couldn’t debug without the use of AI and AI wasn’t helping her with her niche issue. Thus, she was absolutely stuck. This person was a full stack dev and had touched front and back end systems, yet she lacked the most important core skill as an engineer: the principles of problem solving.

This was shocking to me. It seemed inconceivable to be relying on AI so much. Yet, I don’t blame the aforementioned coder because technology as a whole seems to push AI as a panacea, especially to newer developers. That is where my problem lies. I do not disagree with using AI as a tool for occasional help, advice, organization or output amplification. I do disagree with using it to replace your own problem solving skills entirely.

AI isn't going anywhere, and in many ways, it will become an essential part of the workflow. However, our value as engineers will never lie in the ability to simply copy-paste a solution. It lies in our judgement. In our ability to critically assess an AI's output, debug it when it inevitably breaks, and architect a system from vague business requirements. If you don't know why a solution works, you can't be the one who fixes it.

If you are a newer developer, I urge you to treat your problem-solving muscle as essential. Don't outsource the struggle. When you encounter a puzzle, step away from the AI prompts at first. Take the time to sketch out the logic on a piece of paper, trace the data flow, and deliberately work through the problem without a safety net.

That ability to solve puzzles independently is the foundational skill that was taught to me in that Dallas classroom. In the current muddy waters of AI usage, it is still a skill that separates a durable, adaptable, and genuinely skilled developer from one who just passes the output of a prompt.

Invest in your logic first. The code will follow.

Being a JavaScript Dev vs. a Framework Dev

Amanda Mayfield — Mon, 03 Nov 2025 18:24:44 +0000

I read an interesting article yesterday about Backbone.js vs. React that I’ve linked below.

https://backbonenotbad.hyperclay.com/

Now, obviously given the name of the blog, it’s not exactly the most unbiased source. However, I really resonated with the core message of the article and find it to be a problem more than ever with the advent of the "vibe coding" era. It begs the question: Are we becoming framework developers or are we truly JavaScript developers anymore?

My experience with Backbone.js is not extensive. I had to mess with it some at my last job during a legacy code rewrite. It was vanilla JS, PHP, and Backbone.js, and at the time I thought nothing of it other than, wow, this is a bit verbose. So, it tickled me to see it brought up in the article.

However, as I’ve been diving more deeply into foundational JavaScript again, I’ve been viewing it in a different lens in a post-framework world. I find myself wondering, is React even JavaScript anymore? I fondly remember Kyle Simpson of You Don’t Know JS disagreeing with the syntactic sugar of the Class keyword, and I can’t help but wonder what he thinks of React now. The level of abstraction is just so profound.

This is not to say that React is a bad thing. I think it’s great (though I’m a Vue-lover at heart!) and I’m happy that many developers thrive in it. It’s obviously helped us move our projects and work along so much faster. But I’m also beginning to wonder if some people are only framework developers. I think of this quote from the article: “React looks cleaner. It reads better at first glance. But that readability comes at a cost: you're trading explicit simplicity for abstraction complexity.”

As we continue to learn these tools that make development easier for us, I think it’s important to remember where we came from. We should invest our time in learning, remembering, and studying the boring, old fundamentals and not just the shiny, new (admittedly fun!) framework features. To not spend time and effort understanding the real fundamentals feels lazy and short-sighted.

Please continue to use and learn a framework, but only as a tool to shorten the implementation of JavaScript, not the understanding of it.

If you’re looking for a good challenge, try this: Take a feature you recently built in React/Angular/Vue and challenge yourself to build the exact same thing using only vanilla JavaScript and the native browser APIs. I guarantee you'll learn something new!

How I was naive in my job hunt

Amanda Mayfield — Wed, 22 Oct 2025 17:19:29 +0000

I’ve been doing the job hunt all wrong.

Like many of you, I’ve been on the hunt for a few months now and it can be exhausting. Sending application after application and hearing nothing back is demoralizing.

A few weeks ago, I attended the Commit Your Code tech conference in Frisco, TX, and it truly changed everything for me. I met an incredible community of developers helping each other learn, grow, and navigate today’s job market, especially through the 100Devs and CYC Discords.

I’ve been in the industry for over six years, but the most important thing I’ve learned recently wasn’t technical — it was personal.
I realized I’d been naive about how the job hunt actually works now.

Back in 2021, when dev demand was at an all time high, I was spoiled. I didn’t have to apply for jobs. A friend made an intro, I interviewed, and BOOM, hired immediately. For better or worse, that market’s gone now, and for a while, I was still acting like it wasn’t.

I’ve had to accept that I can’t take employability for granted anymore. The game has changed. I need to be proactive in new ways: by networking intentionally, building real connections, and creating a visible online presence.

This shift hasn’t exactly been intuitive for me. Funny enough, we’re expected to pivot constantly on the job, by learning new stacks and new systems; when it comes to our own careers, that same adaptability can be hard to find.

But here’s the thing: problem-solving is what we do.
Does this market kind of suck? Absolutely.
Can we master it like any other new challenge? Definitely.

So if you’re out there grinding, wondering if it’s still possible, know that I think it is. Rethink your strategy. Build proof. Connect with people who are learning and sharing too.

It’s not easy work, but it beats sending 1,000 applications into the void. You’ve got this. 👊