View on GitHub

reading-notes

Reading notes taken while attending Code Fellows classes.

Engineering

Index

Home
Takeaways
Discussion Questions

Takeaways

Anthony Moore

If, in your heart, you know your time is valuable…

People will recognize that.

People will respect that.

People will treat you differently.

Witty Quotes:

Richard Reis

How to be a good problem solver:

  1. Understand what is being asked
  2. Plan your solution
  3. Divide the problem into sub-problems
  4. Stuck?
    • Debug
    • Reassess
    • Research
  5. Practice (Solve problems frequently)

Witty Quotes:

John Sonmez

Steps to solve a programming problem:

70% of your time is spent on 1, 2 and 3 and the last 30% of time is spent on 4, 5 and 6.

  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. Optimize the real code.
  6. Optimize the real code.

Any language you expect to be able to solve algorithm type problems in, you should know how to do the following things:

Discussion Questions

  1. What’s the one thing I bring to this career (and a potential employer) that nobody else can?

    I have a history of 13 years in product testing and 3 in game development, because of which I have a refined sense of discovering, researching and communicating problems as well as creating documentation that describes both normal and technical versions of these problems. I’ve worked on literally dozens of AAA game titles and have gone through the versioning process nearly 1000 times over my career. I’ve worked with multiple companies participated in eaches approach to developing software. Having this background coupled with a passion for solving problems sets me appart from the crowd and gives me a resilence to illusive issues and hard to solve problems that many do not have.

  2. What are 3 things I’ll start doing to “un-stick” myself whenever I get stuck on tough piece of code, logic, or feature?

    • Employ the 5 why’s technique moving quickly from one “why” to the next to keep from jumping to any conclusions.

    • Go back to the whiteboard.

    • Use the 6 steps described by John Sonmez

Back To Top