CodeCrafters, Stepping Out of The Comfort Zone
2024-09-03
I first heard about CodeCrafters on the DevTools.FM podcast, where it was a sponsored product aimed at developers that are stepping into intermediate to advanced waters. I believe the host, Andrew Lisowsky, was working through either the build your own redis project or the build your own git project, and both of those struck me as an impossible feat. But sure enough, one of the selling points of this framework of learning is that you teach yourself about how the software you use as a developer works.
Every month they offer a free project available to work through in many different programming languages. I started late last month when the free project was build your own http server, so this month I was determined to finish the free project build your own grep. I would have to say, that my use with grep had been pretty minimal, usually just a quick way to sort through server logs. So, I familiarized myself with some useful features via this informative YouTube video, https://www.youtube.com/watch?v=crFZOrqlqao&pp=ygULZ3JlcCBiYXNpY3M%3D
I decided to use Python for this challenge for two reasons, I want to keep the syntax somewhat fresh in my mind, and I have been exploring Mojo as a viable systems programming language. The first stage is always a freebie in these challenges, and really get the ball rolling, making a new git repo, and all the files and environments needed to run and test your work. CodeCrafters is notably different because it doesn’t teach you how to build the software or even an architecture to build from. When introducing a new concept, a whitepaper or documentation site could be linked, but the biggest resources you will have to conquer the problem are screencasts and code examples. Code examples are sometimes a great reference, maybe even an introduction to new ways of solving problems, but they can be also confusing, and as a free member you only get two of them to browse through.
As I made my way through the third challenge it started feeling easier, like I could just try something, or look up a new keyword I found for Python any() which basically OR’s out any boolean iterated with a loop or function call. It was a major confidence boost on the journey of building a regex engine. However, the fifth exercise stumped me. It was clear I was going to have to use recursion to step through each character and try to match the pattern to it, but the structure of how to accomplish that was shaky at best. Looking to the code examples also started to loose any helping effect, because the examples were likely predicated on a different structure than I started with, making reading through and understanding them a tedious task that left me with little insight, because all of the implementations weren’t handling every edge case, and this isn’t really designed to, its just a proof of concept.
So, that is how I decided to handle it, by any means necessary. Forging through that problem and every complex challenge after like the “+” modifier that allowed for one or many matches to the previous character in the pattern. Just like in a real project with morphing requirements, each stage built on the last, and my function got uglier and uglier. I even used a dictionary, because it is an easily mutable data structure perfect for memoization in recursion, just to mark the “^” symbol as a flag that only allows a match at the beginning of the line input.
Ultimately, I didn’t finish the three bonus stages of the project, but I felt rewarded getting where I did. Could my program handle *All* of the edge cases? Probably not, but I think I learned one valuable lesson. I spent hours trying to architect the best way to handle edge cases and the flow of parsing the input, when I should have just tried something, iterated on it, and kept passing the tests.
Comments