Naive Programming: The mark of plebs?

Now that I am finding my stride a bit more as a developer, I have noticed that this unexplained need to prove just how clever you are as a developer. After spending (wasting?) several months worrying about if I was “clever enough”, I noticed that a disturbingly large number of my peers have the overwhelming need prove they are, indeed, more clever than the programmer sitting next to each other. Watching these battles, is somewhat akin to witnessing two scrappy cats duke it out over their food bowl. I find this trend is even more puzzling since these programmers, like myself, only have a few years of work experience in programming.

Recognizing that I could benefit from some more consistent programming techniques, I decided to do some digging on various programming styles. With the help of various Katas and a couple Test Driven Development classes at Codaisseur, I stumbled upon Naive Programming.

Naive Programming is exactly what it sounds like: finding the simplest, most straight forward approach to solving an algorithm. When the course instructor suggested using this approach, I was definitely intrigued. I mean, shouldn't I be flexing my muscles to find the clever approach? The other half of my pair programming team wasn't having it “There is a better way to do it”, so I let him drive and I took the opportunity to observe and learn from a “cleverer” programmer. By the time we left for the day, the code was filled with bugs and I had a hard time following all of the loops, mappings, conditionals, and indexings, let alone why they were being used.

With the help of exercism.io, I decided to check out Naive Programming and was pleasantly surprised by the outcome. However, when I consulted professor Google, it was clear by the number of programmers calling Naive Programming unsophisticated or implying that they are not worthy of being in production codebases, that this technique was apparently beneath any self respecting coder.

Now I get that this technique may not be the optimal solution, but I believe that, particularly for those of us who have enough experience to really make a mess, but not enough experience to always see the full extent of the potential fallout, Naive Programming is a great tool.

Why you ask? I'll give you 5 reasons:

~ It gives you a starting place

I have always struggled to find a starting place when it comes to writing algorithms. My brain just seems to freeze and then I begin this existential crisis about whether or not I will ever “prove”myself as a coder because I couldn't solve this single, insignificant algorithm. Naive coding solves this issue. It gives me a starting point every time, without fail. Break down the problem and just make the solution work. It doesn't matter it is clever, elegant, or perfectly written. Does it work? Great.

~ It increases readability for others
How many times have you looked at legacy code and thought WTAF is going on here? You dive in and after a trip down the worm hole of time, you come back up only to discover that the same issue could be solved in a couple of extremely simple lines. In my relatively short time developing, I have seen it more than once. If the original coder had reached for the simplest solution, it would have been much easier for his or her successor to understand what was going on, and maybe, just maybe, you wouldn't be looking at the code for bugs.

~ It helps you breakdown predefined methods.

I know I am guilty of it. Predefined methods. I use them all the time. I know what they do, what kind of object I can use them on, and what kind of behavior to expect. What I don't always know is exactly how they work. By taking the Naive approach, I am breaking things down to absolute simplest form. I am coding out these methods myself, so I really know what they do. The other day, I was working on a filtering algorithm. By writing out the full loop and creating a conditional statement, I knew exactly what I was looking for and was able to refactor to use a method that I wouldn't have thought of previously.

~ It gives you the most flexibility to evolve your solution
When I started developing, I was introduced to this lovely infographic

What I didn't realize, is that my solution will never be the same as my colleagues, and even amongst us developers, our interpretations can be VERY different. As a result, I have developed two reflexes. 1.) Check in with my senior often, which I know can feel like overkill, but I am inherently lazy and this saves me a lot of time rebuilding and him a lot of time telling me what isn't what he pictured, explaining what needs to change, and re-explaining what he envisioned from the beginning, in a language that isn't his mother tongue. 2.) Keeping the solution as simple as possible. The simpler my solution is, the easier it is to modify, and the the easier it is to part with. It's also easier for my colleagues to build off of or modify.

~ It requires you to thoroughly understand the problem at hand.
What about Naive Programming only providing a blanket case solution, you say? And I would agree with you there, but (because there is always a but) I would also argue that if you truly understand your problem, and its caveats, that solving that problem in a clear and simple way should pose absolutely no issue. Perhaps using Test Driven Development?

Go on. Give it a whirl. Give exercism.io a little site traffic and see what you think.