Fourth of July is today!! I’m grateful for the fathers and mothers of this country who had the courage to literally fight with blood, sweat and tears for our freedom. Their actions have all led up to all of us being here today, doing what we’re doing. I’m allowed the freedom to code, and I’m so thankful for it. So! Today I worked on Ruby exercises and tried to implement the PEDAC process. It’s a struggle to get into the routine, but I heard it’s extremely helpful, so I’ll try to explain it the best I can.
How It Works:
P – Process the Problem – Here you identify the inputs and outputs of the problem, make the requirements explicit, identify rules and try to form a mental model of the problem.
E – Examples / Test Cases – Here you try to validate your understanding of the problem. Think of possible edge cases. From here until the ‘Algorithm’ part is where you ‘load the problem into your brain’ and is the entire ‘process the problem’ part from above. While you’re making your requirements and rules, you’ll try to push the boundaries of the problem to cover as many bases as you can. If there’s something you’re unsure of, you can ask the interviewer for clarification or if you should be worried about a specific edge case, and they’ll either say not to worry about it or that you should try to account for it. You’ll fall back on these examples when you get to your data structures and algorithms.
D – Data Structure – This is where familiarity with data structures and flow control, etc will come in. You will have to decide if the problem you have requires use of an array, hash, loops, etc. Think of the inputs and outputs, ask yourself: what methods will I need to possible use? Am I returning something or simply printing something and what data structure will be most useful for this? Is the input coming in as an integer and being outputted as a string? The possibilities are many, but it’s good to have strong fundamental knowledge of basic ruby structures so that you don’t have to spend hours researching which one is the best to use.
A – Algorithm – Here you will use computational words and language to start fully forming what your intentions will be for your code. You know what the inputs/outputs are, what structure(s) you’ll need, so now is the time to clearly map out what you want to write. The algorithm falls in between simple English and actual code, so that by the time you get to the last part, you’re not surprised or confused by what to do. Be as articulate as possible. Also, be aware every step of the way, as much as you can, of what your code is doing- are you expecting a return value somewhere?, if you are, what are you doing with that return value? Are you simply outputting something? Are you methods doing only one thing, and are they named properly? Ask yourself these to help you understand what you are trying to do.
C – Code – Now it’s time to write some code! This is about 10% of the process. By the time you get here, most of your time will have been spent just thinking about the problem so you shouldn’t be scrambling at this stage. If you get stuck or something isn’t working right, then you can go back and readjust where needed. I had to do that today, but I had most of the problem loaded into my head by that point that after I made the change, I was able to solve it with all edge cases covered fairly quickly. I felt like a champ!
Hopefully this helps you to better approach a problem. It has helped me tremendously to reduce the amount of stress of trying to solve Ruby problems. It also has forced me to slow down and become better at not just getting the right answers, but at problem solving in general.