Solving Problems

The most common mistake I see when conducting interviews or watching someone try to solve a programming problem is they try to start writing code as soon as possible.

You must resist this urge.

You really want to make sure you take enough time to understand the problem completely before attempting to solve it.

Another big mistake is trying to over solve the solution on the first iteration. Keep it simple, don’t try to get fancy.

  1. Read the problem completely twice.
  2. Solve the problem manually with 3 sets of sample data.
  3. Optimize the manual steps.
  4. Write the manual steps as comments or pseudo-code.
  5. Replace the comments or pseudo-code with real code.
  6. Optimize the real code.

The only way you are going to have confidence in this process is to practice it. It takes a good amount of faith to believe that spending 70% of your 30 minutes to solve a problem just thinking about the problem and not writing any code is the right approach, so make sure you have that faith when you need it.

Act like you make $1000/hr

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

“Being busy is a form of mental laziness.” -Tim Ferriss

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.

We’re all busy — with work, our families, our friends. It’s not bad to be “busy.” But in the words of best-selling author Jeff Goins:

“The most successful people I know are not busy. They’re focused.”

Are you focused, making tangible action steps towards what truly matters?

…Or are you just “busy?”

When you’re busy, you are on autopilot. You can’t see the hours slipping away, time you’ll never get back.

How to think like a programmer

If you’re interested in programming, you may well have seen this quote before:

“Everyone in this country should learn to program a computer, because it teaches you to think.” — Steve Jobs

You probably also wondered what does it mean, exactly, to think like a programmer? And how do you do it??

Why is this important?

We all have problems. Big and small. How we deal with them is sometimes, well…pretty random.

Unless you have a system, this is probably how you “solve” problems (which is what I did when I started coding):

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

Look, sometimes you luck out. But that is the worst way to solve problems! And it’s a huge, huge waste of time.

The best way involves a) having a framework and b) practicing it.

Have a framework

To find the right framework, I followed the advice in Tim Ferriss’ book on learning, “The 4-Hour Chef”.

It led me to interview two really impressive people: C. Jordan Ball (ranked 1st or 2nd out of 65,000+ users on Coderbyte), and V. Anton Spraul (author of the book “Think Like a Programmer: An Introduction to Creative Problem Solving”).

I asked them the same questions, and guess what? Their answers were pretty similar!

Soon, you too will know them.

Sidenote: this doesn’t mean they did everything the same way. Everyone is different. You’ll be different. But if you start with principles we all agree are good, you’ll get a lot further a lot quicker.

The 5 Whys

Getting to the Root of a Problem Quickly

Have you ever had a problem that refused to go away? No matter what you did, sooner or later it would return, perhaps in another form.

Stubborn or recurrent problems are often symptoms of deeper issues. “Quick fixes” may seem convenient, but they often solve only the surface issues and waste resources that could otherwise be used to tackle the real cause.

In this article and in the video, below, we look at the 5 Whys technique (sometimes known as 5Y). This is a simple but powerful tool for cutting quickly through the outward symptoms of a problem to reveal its underlying causes, so that you can deal with it once and for all.

How to Use the 5 Whys

The model follows a very simple seven-step process:

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.”

Then, write your statement on a whiteboard or sticky note, leaving enough space around it to add your answers to the repeated question, “Why?”

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?”)

Asking “Why?” sounds simple, but answering it requires serious thought. Search for answers that are grounded in fact: they must be accounts of things that have actually happened, not guesses at what might have happened.

This prevents 5 Whys from becoming just a process of deductive reasoning, which can generate a large number of possible causes and, sometimes, create more confusion as you chase down hypothetical problems.

Your team members may come up with one obvious reason why, or several plausible ones. Record their answers as succinct phrases, rather than as single words or lengthy statements, and write them below (or beside) your problem statement. For example, saying “volume of calls is too high” is better than a vague “overloaded.”

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.

Step 5. 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 technique like Cause and Effect Analysis, Root Cause Analysis, or FMEA.)

If you identified more than one reason in Step 3, repeat this process for each of the different branches of your analysis until you reach a root cause for each one.

6. Address the Root Cause(s)

Now that you’ve identified at least one root cause, you need to discuss and agree on the counter-measures that will prevent the problem from recurring.

7. Monitor Your Measures

Keep a close watch on how effectively your counter-measures eliminate or minimize the initial problem. You may need to amend them, or replace them entirely. If this happens, it’s a good idea to repeat the 5 Whys process to ensure that you’ve identified the correct root cause.

References:

Main page