I just finished the Week 1 self-assessment and feel good about how I handled it. I took the initial 30-40 minute class time given to us to solve the tree-map function and used it entirely to pseudo-code. It's a skill that I've noticed that I need to improve - no surprise since it's something that I've never practiced before. White-boarding is another problem-solving skill that I intend to work hard on improving.
One of the biggest lessons I've taken from Week 1 is the importance of approaching coding challenges deliberately. Thinking thoughtfully both about the bigger picture and then, through activities like 'acting as the interpreter', thinking precisely over each statement in our code.
I believe that practicing these skills now - while they might not satisfy the itch of 'immediacy/urgency' that I feel when I confront a coding problem to solve - they'll ultimately build my chops and my problem-solving proficiency in the long term. And they're going to be critical skills when mapping out bigger-picture challenges (like applications) that are to come.
In a nutshell, I'm trying to slow down in order to move faster.
I solved our assessment's coding challenge in good time. It took about three hours to go from my first line of pseudo-code to passing the tests. But somewhere shy of an hour before solving the problem and implementing all the required functions, I had a eureka moment. I realized that the course that I had charted in my initial planning session was off slightly, but decisively, and I knew what needed to change.
Our task was to build out a very bare-bones tree structure that included a data property and an array-of-children property. We were to create the functions .addChild and .map, the second of which returned a new tree that mimicked the structure of the original tree but with its values modified by the function's callback.
Here's what I wrote for addChild:
Tree.prototype.addChild = function(value){
var newTree = new Tree(value)
this.children.push(newTree)
return newTree
}
So it takes in a value, creates a tree node that stores that value, and adds it as a child of our original tree.
This made sense to me. And it still makes sense! But I ran into problems when using it in the recursive case of my map function. Because when looping over every node, all I could do was .addChild (add a child) to the original node. So the recursion would look essentially like this:
recursiveFunction(root.addChild)
which would produce a recursion roughly like this:
rootNode.addChild(rootNode.addChild(rootNode.addChild etc...)))
So although the function would traverse the entire structure and correctly apply the provided callback function to each child tree, it would then append all the newly created children to the root node of the new tree we were producing.
I was stuck. I had written an addChild function that made sense and so the problem had to lie somewhere in the map function, in how I was applying recursion.
What I wanted to do was not keep applying recursion to the same root node (as above), but create a new node (tree) independently of the root, every time I encountered one of the root's child trees.
Something like this:
var newtree = new Tree
rootOfCopy.addChild(newTree)
recursiveFunction(newTree)
But I wasn't able to do that because our addChild function did not accept tree objects. It only took in values, and created its own tree objects.
Well, it was time to change that. And once I did, everything fell into place.
That's been my biggest challenge in solving coding challenges so far. Making a critical assumption early on, a wrong assumption, that creates an intractable problem later on. Invariably, I recognize the error and fix the assumption, and close in on the answer shortly after.
How do I avoid making the early misstep? I'm not sure, but I believe that practice will get me there. Maybe it's building a stronger overall coding and problem-solving intuition. Maybe it's recognizing patterns in the problems, whether the patterns are in object design, or recursive loops. Maybe it's recognizing patterns in my own thinking.
I'm looking forward to getting out of my own way, and shortcutting from my too-often current process of solution -> aha moment -> correct solution to a process that looks like: solution.
Top comments (0)