Here's the thing... My favorite part of my career on Broadway was when things went wrong. Running a show over and over again no matter how good it is you get sort of into a zone where "Wait we're in Act Two?", you go on autopilot. Maybe I can't admit it but I'm secretly an adrenaline junky, but how your mind can think of solutions and run through problems in a moment like that is really exciting. That and chatter over a walkie talkie makes you feel important. So, how does this relate to code? Well its problem solving... somethings not working, either input isn't going through, data is not being manipulated or TypeScript just hates you.
We will go through my journey, because I love to talk and just had a large cup of coffee.
My strategy in code has changed now I'm working with bigger and bigger projects. Where I started, came from my knowledge in audio but some of the basic rules still apply.
First and foremost... READ THE ERROR MESSAGE!!! or log, oh heroku how I've grown accustomed to your logs... sorry My Fair Lady joke. Most times they will tell you what line it broke on. This won't tell you why but it gives you a starting point. Most of the time it's a silly typo or just data parsed differently (thank you linters for showing my faults 90% of the time). If it goes beyond that... then what?
Usually you have an idea and work on that... move on to something else... then go back to your first idea and wonder why it still doesn't work. That's not very efficient. In audio, the practice usually is you can start at the end or the beginning and chase it down the chain. So if you don't hear anything from a speaker, you go to the speaker... is it plugged in? Yes, does the cable make another speaker work? Maybe... but you chase it from one end to the other. You can start at the console if that makes more sense... audio is passing to what point? Now here I've realized this logic has a lot to do with physicality. These are physical objects that have a linear path. In some places it's a long walk from speaker to amplifier to console so you chase it down the chain instead of having everyone wonder "Why is this person walking in circles?". With code... everything is at your fingertips more or less. You may have to log into a server or check an API call but you're seated, the circles are all in your mind.
I have a habit of trying to figure things out before going straight to google. It is a more constructive method for me to learn that way, so instead of doing the walk back from the end as I would with audio... Binary Search works amazing in this to cut down what the problem may be.
You have input and you're expecting certain output. So hopefully you have a grasp of where the ins and outs are happening. The most time efficient method would be to go to the the middle and see if you are getting what you expect there. Print statements are handy for this... Most of the time things will be fine midway through, so you jump to the next midway. There if you get an undefined or an error, you know it's before that. And again you travel... So this may sound like an odd method coming from the logical down the chain of events. Say you have an error on step 9 of 20 step process... The first place you would try is 10... no go, then 5, nope 7 or 8... nope you'll reach 9 in about 5 steps depending which side of the rounding you decide on. So that's 4 less steps than start at the beginning. and 11 less if you started at the end. Depending how much wading you need to do in the code, this seems way more reasonable and you feel like you're making progress. Instead of sitting and trying random solutions, you figure out what it isn't until you found out what it is... Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.
So there you are... But when that fails there may be a rubber duck nearby.
Top comments (0)