Skip to content

prework401.md

Latest commit

 

History

History
87 lines (55 loc) · 4.53 KB

prework401.md

File metadata and controls

87 lines (55 loc) · 4.53 KB

How to Solve Programming Problems

A simple set of steps

  1. Read the problem completely twice.
  • This is the single most important step. You may even want to read the problem 3 or 4 times.
  1. Solve the problem manually with 3 sets of sample data.
  2. Optimize the manual steps.
  3. Write the manual steps as comments or pseudo-code.
  4. Replace the comments or pseudo-code with real code.
  5. Optimize the real code.

Pretend Your Time is Worth

“Pretend your time is worth $1,000/hr. Would you spend five of them doing extra work for free? Would you waste one on being angry?” -

Busyness” Isn’t a Badge of Honor; It’s a Sign of Weakness

If you let it, your world and the people around you will take all your time. Your time is not unlike your paycheck; if you don’t budget for things, you’ll have nothing left over by the end of the month. This is how lives are wasted — by doing thankless work for ungrateful takers that didn’t deserve your time in the first place.

“The most successful people I know are not busy. They’re focused.” “Indeed the state of all who are preoccupied is wretched, but the most wretched are those who are toiling not even at their own preoccupations…If such people want to know how short their lives are, let them reflect how small a portion is their own.”

As You Think, So You Are “As a man thinketh, so is he. As he continues to think, so he remains.” -James Allen

How to think like a programmer — lessons in problem solving

  • Try a solution.
  • If that doesn’t work, try another one.
  • If that doesn’t work, repeat step 2 until you luck out.

Almost all employers prioritize problem-solving skills first. Problem-solving skills are almost unanimously the most important qualification that employers look for….more than programming languages proficiency, debugging, and system design

Demonstrating computational thinking or the ability to break down large, complex problems is just as valuable (if not more so) than the baseline technical skills required for a job.” — Hacker Rank (2018 Developer Skills Report)

Have a framework

1. Understand Know exactly what is being asked. Most hard problems are hard because you don’t understand them (hence why this is the first step).

2. Plan Don’t dive right into solving without a plan (and somehow hope you can muddle your way through). Plan your solution!

3. Divide Pay attention. This is the most important step of all.

Do not try to solve one big problem. You will cry.

Instead, break it into sub-problems. These sub-problems are much easier to solve.

4. Stuck? By now, you’re probably sitting there thinking “Hey Richard... That’s cool and all, but what if I’m stuck and can’t even solve a sub-problem??”

First off, take a deep breath. Second, that’s fair.

Don’t worry though, friend. This happens to everyone!

The difference is the best programmers/problem-solvers are more curious about bugs/errors than irritated.

5 Whys

  1. Assemble a Team Gather together people who are familiar with the specifics of the problem, and with the process that you're trying to fix. Include someone to act as a facilitator , who can keep the team focused on identifying effective counter-measures.

  2. Define the Problem If you can, observe the problem in action. Discuss it with your team and write a brief, clear problem statement that you all agree on. For example, "Team A isn't meeting its response time targets" or "Software release B resulted in too many rollback failures."

  3. Ask the First "Why?" Ask your team why the problem is occurring. (For example, "Why isn't Team A meeting its response time targets?")

  4. Ask "Why?" Four More Times For each of the answers that you generated in Step 3, ask four further "whys" in succession. Each time, frame the question in response to the answer you've just recorded.

Tip: Try to move quickly from one question to the next, so that you have the full picture before you jump to any conclusions.

  1. Know When to Stop You'll know that you've revealed the root cause of the problem when asking "why" produces no more useful responses, and you can go no further. An appropriate counter-measure or process change should then become evident. (As we said earlier, if you're not sure that you've uncovered the real root cause, consider using a more in-depth problem-solving