Amusingly (now that I’ve had some time to wind down), a large part of my day was spent untangling a combination of every one of these except “missing impl[i]ed return type”[1]. The code directly scrutinized was only about ten lines combined, and had been thoroughly tested for its expected behavior. What I expected to be a minor refactor taking maybe 5 minutes caused me to:
- think I’d identified a potentially really nasty bug (incredibly, I hadn’t!)
- second-guess several tests and expand their assertions to confirm that they weren’t coincidentally passing (amazingly, they weren’t!)
- start dozens of debugger sessions ever-expanding in scope (I learned a lot, at least there’s that)
- shave at least three whole yaks (which are currently represented in a huge comment explaining what I found, because fixing anything I did find is wildly out of scope for what I’m working on, and liable to present more yaks needing a shave)
- adjust my small refactor to account for the relevant knowledge acquired in this process (two lines of code changed, plus said huge comment)
- end my work day early out of sheer exhaustion (granted it started early and tired, but adjusting for today’s whole extra pot of coffee I expect this would’ve been the outcome on a more typical day as well; if anyone on my team is reading this, sorry I didn’t push my changes yet! You’re not missing much besides trivia we’ll be glad to know later)
Anyway, I’m obviously biased at the time I’m writing this comment, but I applaud this effort! In particular I find unexpected side effects and name/type mismatch can be day- or even week-swallowing challenges (and yes I know naming things is a hard problem).
Some feedback on the UX: on mobile, if you select an antipattern to read about, once you reach the bottom you have to scroll up to select the next one. It gets a bit tedious when you want to read about all six antipatterns.
Amusingly (now that I’ve had some time to wind down), a large part of my day was spent untangling a combination of every one of these except “missing impl[i]ed return type”[1]. The code directly scrutinized was only about ten lines combined, and had been thoroughly tested for its expected behavior. What I expected to be a minor refactor taking maybe 5 minutes caused me to:
- think I’d identified a potentially really nasty bug (incredibly, I hadn’t!)
- second-guess several tests and expand their assertions to confirm that they weren’t coincidentally passing (amazingly, they weren’t!)
- start dozens of debugger sessions ever-expanding in scope (I learned a lot, at least there’s that)
- shave at least three whole yaks (which are currently represented in a huge comment explaining what I found, because fixing anything I did find is wildly out of scope for what I’m working on, and liable to present more yaks needing a shave)
- adjust my small refactor to account for the relevant knowledge acquired in this process (two lines of code changed, plus said huge comment)
- end my work day early out of sheer exhaustion (granted it started early and tired, but adjusting for today’s whole extra pot of coffee I expect this would’ve been the outcome on a more typical day as well; if anyone on my team is reading this, sorry I didn’t push my changes yet! You’re not missing much besides trivia we’ll be glad to know later)
Anyway, I’m obviously biased at the time I’m writing this comment, but I applaud this effort! In particular I find unexpected side effects and name/type mismatch can be day- or even week-swallowing challenges (and yes I know naming things is a hard problem).
1: ;)
Some feedback on the UX: on mobile, if you select an antipattern to read about, once you reach the bottom you have to scroll up to select the next one. It gets a bit tedious when you want to read about all six antipatterns.
Thanks! very good point. I added a button to the bottom now to scroll up to the selection point again.
The source for this "web page" is at https://github.com/Linguistic-Antipatterns/linguistic-antipa...