Ant Steps: Your Pathway to Becoming a Stronger, Faster, and Happier Developer
OK people. Let's be honest. Coding can be very frustrating. We have to deal with bugs, misunderstandings, new technologies, confusing requirements, and bad code.
The list goes on and on; however, what if I told you I have a technique that will make all the frustration go away? Too good to be true you say?
Well, It is too good to be true. I don't have a technique like that, but I do have something that will greatly reduce the amount of frustration you may experience while coding. This will help you:
- Encounter fewer and simpler bugs
- Become a faster developer without compromising code quality. Your manager will love this
- Be happier, more relaxed, and more confident while you code!
Does it still sound too good to be true? Well... it is not!
Ok. What is this technique?
I won't make you wait any longer. Here is my top-secret technique. I call it "Ant Steps" 🐜:
When you code, take very small steps and verify every single step as you go.
I can already hear you thinking "That's it? I thought you had something better for me".
Patience young padawan. Let me elaborate a little bit more. Yes, this is classical advice, and you might have heard it before. This is something I used to tell my students all the time. I remember hearing myself saying "Take very small steps and always verify the code is behaving the way you think it's behaving".
After a few years of teaching, I became a developer again, and I realized I either had forgotten how to take small steps, or I never fully understood the concept.
So, What happened?
When I started to work on my new codebase, I noticed I was wasting my time in "silly mistakes". I was getting lost in the codebase a little bit too much. I had to constantly go back and forth when I was working on a task. Above all, I was becoming increasingly frustrated. Coding wasn't as fun as it should have been.
I pair with my manager Spartacus (we'll use that name to protect his identity) regularly. I noticed how he made several small comments about how I was trying to go "too fast". I also noticed how his coding approach was much more methodical than mine.
I did what I always do when I find something I might need to improve within myself: throw a tantrum and cry!
Nah. I decided to read books, study, and ask questions! I realized how, over the years, I had moved from "ant steps" to "elephant steps". I moved too fast, and I assumed too much about the codebase because "I had been coding for a long time" and "I knew what I was doing". With that in mind, I formulated a more structured technique.
Before we continue I know you are wondering about something. Let me answer your burning question! I named this technique ant steps because of a saying my mom had when I was a child.
If said I was going to do something, she would always ask "¿Pasos de elefante o de hormiguita?" which translates to "Elephant steps or ant steps?". It was her way of asking if I was going to be careful about whatever I was supposed to do.
Introducing: Ant Steps 🐜
Make small changes, and verify them. That's all I had for several years of my development journey. Once I became mindful of the process, a few questions came to mind.
What's a small change?
I thought about this for a while. In the end, I realized the key factor was in the verification process. If a change doesn't work, the reason should be immediately obvious. In other words:
If you aren't sure why a change didn't work, the change was too big.
How do you verify your changes?
First of all, I like to keep in mind the main purposes behind verification:
- Making sure you understand the existing codebase
- Making sure the new code you are adding behaves the same way you think it's behaving
OK, but how do you verify? Just running the code... right? That's what I thought for a while, but there are other ways to do it:
- Printing values in the console
- Test-driven development
- Placing a breakpoint in the code
- Asking questions to co-workers, clients, or product owners
- Using your browser's developer tools
Why are smaller changes better than bigger changes?
I want to spend a bit of time in this section because it's a critical part of getting comfortable with ant steps.
When you are coding, you have a mental model of the code you are working on. You are constantly running that model in your mind to understand your code or to make changes to it. First, you run your new changes in your brain; If they succeed, you type and run them with the computer. This cycle goes back and forth during the programming process.
That's a good thing! and as you become a better developer, your ability to create and run these mental models will increase. It's one of your most powerful tools. The downside is that when it comes to running a large codebase, brains are not as good as computers.
The more code you are trying to run with your brain, the harder it will be to get accurate results. With too big a codebase, running the mental model becomes nothing more than guesswork. Mistakes can, and will, happen whenever you code based on guesswork.
I like to think about it like this: in the game "The Legend of Zelda: A Link to the Past" your lamp made dark areas of the game look like this:
Notice how can see a lot of detail in a small area surrounding Link; the game's protagonist. You can see a couple of small steps, but the visibility sharply decreases away from Link. What if you wanted to interact with the pink enemies on the left side of the picture. You could:
- Try to remember or guess what's on the left side of the screen.
- Take small steps and update your mental model accordingly.
I know which option I prefer. What about you?
Isn't that too slow? I gotta go fast you know?
"Slow down! Speed racer". One of my old co-workers used to say that to me 😂.
I thought so too! but that is not the case. I've realized that the time you "waste" when taking small steps is nothing compared to the time you waste trying to recover when big changes go wrong.
I found a great quote during my research in the book Extreme Programming Explained. Kent Beck and Cynthia Andres write "the overhead of small steps is much less than when a team wastefully recoils from aborted big changes" (Page 33)
Have you ever seen memes like this one?
Sometimes writing 1000 lines of code without verification does work, and it feels great! Howeveri gue let me paint you a scenario. Legal Disclaimer: Any similarity to Vinicio's real life is purely coincidental.
I, like the person in the meme, decide to write 20-50 lines of code over 2-3 files and functions. I also decide to implement a few refactorings and renames along the way. I haven't run my code in about 20 minutes at this point.
Why did I do that?. Maybe I'm confident because I "know" the codebase, and I "know" what I'm doing. Maybe I just have an impending deadline, and my impostor syndrome is acting up again.
Whatever the reason may be, I finally run the code. I'm secretly expecting to feel like the guy in the meme and.... (drums please) the code doesn't work. It's time to start the debugging process; right? What could have gone wrong?
- Did I introduce a defect in the new code I added? Which one of the 20-50 lines could have broken?
- Did I introduce a defect with any of the refactors and renames?
- Which one of the files has the defect?
- Did I add the code in the right place?
- Is it one bug or many bugs?
So what do I do? I can either spend the required time to debug this and hope it resolves quickly enough or....start again from a clean codebase. The choice is yours.
That's a lot of food for thought huh? Thanks for reading up until this point! I'm proud to have you as part of the Cadejo family. If you like this article so far, please subscribe to my newsletter 😇
Let's end with a more high-level thought. Why do we usually gravitate to taking big steps? I remember reading Drawing with the right side of the brain by Betty Edwards. She states: "Beginning students most often admire drawings done in a rapid, self-confident style".
Sometimes, a part of us may want to feel like that guy in the meme I showed you earlier. We want to be able to code 100+ lines and having them run perfectly on the first execution. It doesn't matter if we are just learning how to code or if we have been coding since middle school.
Sadly, that is not the process process artists use to draw, and that's not the process we'll use when we code. As my mom says all the time "Voy despacio que tengo prisa" (I'm going slowly because I'm in a hurry). Whenever you feel yourself going back to bigger and bigger steps, remember our motto: "I'm going slowly because I'm in a hurry" 🐜.
In the end, this is the complete meme I showed earlier:
Beck, Kent, and Cynthia Andres. Extreme Programming Explained. Addison-Wesley, 2006.
Edwards, Betty. Drawing on the Right Side of the Brain. Penguin Publishing Group. Kindle Edition.