Most people will start with using “git blame” (or the respective functionality within their IDE/editor).
But on most non-trivial projects, you usually end up with a refactoring commit, a rename, or a trivial cross-project fix like switching to another assertion library. At first glance, we only see the most recent changes, not the most important ones.
We need to carefully remove layer by layer of sand and dirt that has been swept over the real changes to unearth them.
-
Simplify Protocol Refactoring
The other day, I went grocery shopping. While waiting in line, I thought about some struggles I had in a test I wrote earlier that day.
When it was my turn, the cashier scanned my items and said what I owe him. And I just gave him my whole wallet. He stared at me blankly and gave it back. A little confused for a second, I took out my card, paid, and left the store. And at that point, it hit me what was wrong with my test.
Instead of giving the cashier our whole wallet, let’s just give them what they need. Not more, not less.
Sometimes, you need to make code more trivial to see the higher-level patterns that solve the issue at hand more elegantly.
-
Java Syntax Puzzlers
Working on language-specific tooling exposes you to all kinds of edge cases and delicate details and language has to offer. Some of them are well known and generally seen as “unprofessional” (hello goto). Others are actually not known at all. And with all due respect, I quite enjoy discovering the edge cases of the language syntax – a lot of times to confuse my co-workers who think they know the Java Language Syntax.
And given I love a good puzzle (especially the Java Puzzles), let’s try a puzzle but using the Java syntax only, without any runtime behavior.