Intro: When All You Have Is A Hammer
"When all you have is a hammer, everything looks like a nail". This is known as the "Law of the Instrument" or "Maslow's Hammer" (plus some other monikers). The meaning behind this is that sometimes we get familiar or comfortable with a tool and bias towards using that tool to solve problems. This post is a tale of a recent experience I had where I let go one of my hammers and added something new to my mental tool belt.
I deviated from programming early on in my studies and moved to a more operational role. One thing that was readily apparent is that the tools and systems I learned about handled problems to varying efficacy. MySQL is not always the best database. Nginx isn't the best load balancer even if you can get it to load balance. Just because I can write a 1000 line bash script doesn't mean I should.
Ultimately, I've had to continue learning about new ways to solve problems. I subscribed to various blogs, watched conference talks as they were posted online, followed engineering leaders on Twitter, and even gave up Perl (this was about 8 years ago :) ).
I've recently started focusing on my programming skills again, but before I talk about that, first a flash back to when I first started programming as a teenager.
A Pattern
Given an m x n 2D array which represents a maze, return a list of indices representing the solution to navigate the maze.
As a 17-year old programming newbie in Java, I was stumped. Every time I ran some tests, "ArrayIndexOutOfBoundsException" or "Error: Returned solution has 0 entries". Smashing my face on the keyboard and a few choice swear words later... I gave up.
It was a rough experience, but what I remember most was when another programmer showed me how he would mark paths he had traversed with a 2D boolean array of the same size to track where he had been. I thought it was the most brilliant solution ever. Clearly I hadn't been out much, but it was like a light turned on in my head. I distinctly remember him saying "Sometimes it's just easier to use a separate structure for tracking things". Note that he said "Sometimes" and not "Always" because I didn't at that point.
I soon saw other programming challenges where maintaining another structure to track "visited" items proved very handy. The first time I reused this approach was when I wrote a program to find words on a Boggle board. Handy! But it didn't always work and even made the problem harder.
Present day
Fast-forward to present day... I'm happy to say, I am now working on my programming skills again! I love to build!
Hackrank is where I currently spend a lot of time working through various programming challenges and reading the associated discussions about how others have solved the problems I was working on (this is actually one of my favorite things about these challenges).
Cycle Detection
SPOILER ALERT - I talk through some details about solving a Hackerrank challenge here
Recently, I came across a challenge that prompted this post: "Cycle Detection". In this challenge you are supposed to detect a loop in a singly-linked list. I knew this pattern! I would just keep a separate structure with the nodes I had visited and detect the loop if I crossed one of those nodes.
Fortunately, all the edge cases on all these problems I had working on made the cogs in my brain start turning. Something about the solution didn't seem right. It's not wrong, but what if I had a linked list that had a million nodes? What if it had more? Was there another way to solve this problem?
After submitting my solution, I flipped over to the "Discussion" section where my eyes were opened and I drooled over someone else's short and elegant solution.
They simply had another pointer that traversed the list twice as fast. If the first pointer and the second pointer where ever identical then there was loop in the linked list. Clever and SO much simpler than my solution!
Where else might I see collision type problems? Maybe I had just discovered another pattern... I casually added that to my mental tool belt. It was interesting as I thought about that solution and how both of these techniques could be used in networks (among others).
Your Mental Tool Belt
Learning the fundamentals is a lot of fun. What is even better is when you start to draw connections between various fundamentals and you see a bigger picture. Learning different ways to approach problems gives you more to work with and enables you to move beyond your hammer - or rather, it helps you identify when the hammer is the right tool for the job.
What makes you and I better at what we do is learning how to solve problems and learning new ways to do it! Even for the simple things. Even as we become more advanced and develop expertise, it is important to set aside our bias (hammer) and see how else we can do things.
Do you have more than just a hammer? Do you see too many nails? Keep honing your craft, try something new, explore a new subject, read another book, read another dev.to article - whatever you do... keep learning!
Top comments (0)