TL;DR versions of articles I read today on software engineering. Sign up for my newsletter to receive these in your inbox every weekday.
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
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
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
Top comments (2)
That's such a critical mindset to have! I have seen junior engineers super relying on the debugger such that they can fix the data somehow, but they pay less attention to the fundamental causes:
I completely agree! A lot of times, I've seen developers fix a
NullPointerExceptionby adding a null check before the function invocation. But the variable should never have been null in that location!Longer term fixes such as investigating the workflow, figuring out data issues go a long way in building a robust system instead of immediate symptomatic fixes.