#Issue15
3 posts

The fundamental philosophy of debugging

Realize that you don’t already know the answer. Don’t try to guess the causes. Look at data until you understand what is causing the problem.
Read more

The fundamental philosophy of debugging

  • Get thoroughly familiar with what a working system does.
  • Realize that you don’t already know the answer. Don’t try to guess the causes.
  • Look at data until you understand what is causing the problem.
  • Compare the data that you have with what you know the data from a working system should look like.
  • Fix the cause of this anomaly, not the symptoms.

Full post here, 8 mins read

Mistakes I’ve made as a junior developer and how you can avoid them

Don’t jump at the first offer. Research on what you are worth, what the company culture is like and what kind of projects will you be working on. Code is never self-documenting however clean it is. Use comments extensively.
Read more

Mistakes I’ve made as a junior developer and how you can avoid them

Jack Finlay’s reflections on his first two years as a software developer.

  • Don’t jump at the first offer. Research on what you are worth, what the company culture is like and what kind of projects will you be working on.
  • Code is never self-documenting however clean it is. Use comments extensively.
  • Don’t wait before asking questions. If you don’t ask, you run the risk of wrong assumptions and of building something wrong.
  • Don’t get stuck only using proprietary tooling and languages. Code in your time outside of work to ensure you have skills that are transferable to other companies.
  • Take care of yourself. Read, write, exercise and take some time off.

Full post here, 8 mins read

Your test should verify if the code solves the problem, not if it runs

Write code such that if you separate the structure of the code according to the structure of the problem, you won't have to change the structure of the code unless the structure of the problem changes completely.
Read more

Your test should verify if the code solves the problem, not if it runs

A few salient points from the post:

Your code is fragile if

  • structure of the code allows you to make a breaking change without a test failure
  • you have a high degree of coupling between code and their test files

Write code such that if you separate the structure of the code according to the structure of the problem, you won't have to change the structure of the code unless the structure of the problem changes completely.

The tests should stay passing in a refactoring operation. Otherwise, that's not refactoring. If you make changes in the code that doesn’t change behavior, you should not make the tests fail.

Full post here, 10 mins read