TL;DR versions of articles I read today on software engineering. Sign up for my newsletter to receive these in your inbox every weekday.

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

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

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

Debugging philosophy; goals of testing; & mistakes junior devs make