4 ms·

I wrote something on this idea as well referring to it as Debug Driven Development[0]. Similar to TDD or Domain Driven Design (DDD) we should aim to write code

I wrote something on this idea as well referring to it as Debug Driven Development[0]. Similar to TDD or Domain Driven Design (DDD) we should aim to write code that is easy to debug. Store intermediate values in a pipeline in variables, store predicates in a variable with a human readable name, and avoid in lining complex function calls. There are other techniques that serve this purpose and additional reasons than what this article explores of how or why this is helpful. [0] https://sambernheim.com/blog/debug-driven-development https://sambernheim.com/blog/debug-driven-development

minimaul 4y ago
I really like this concept! It's something I regularly say to our juniors - if you have two ways to do something and one is much easier to debug later, it's probably a better choice. It's a nice extension of not writing unnecessarily overcomplicated code and keeping things readable.
- bern4444 4y ago
  Thank you! It’s easy to fall into this habit especially with chained methods where it looks so nice. I have to remind myself of this concept often as it’s just so easy to do things quick and dirty
- PointyFluff 4y ago
  Past Barry writes comments to Future Barry, so Future Barry knows what the fuck is going on and doesn't have to try and figure out the spaghetti-code Past Barry apishly bludgeoned into the keyboard with his penis-tipped meat-stumps. Both Barry's think the other is an insufferable asshole.
- fragmede 4y ago
  Kernighan's lever: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
WorldMaker 4y ago
From a slightly different perspective, and not entirely disagreeing with you but moving into a related discussion: as an industry we sometimes forget that we can build higher level debuggers just like we build any other higher-level abstractions. If the question is "how do we insert a console.log here?" (or a logging.log() to a file on disk. Or RS232 null modem command sequence plus log ASCII. Depending on the app and era) it's sometimes fine to say that question is too low level on specific output format and that we should be reaching for higher-level debuggers. I understand the problems that higher level debuggers take time for someone to build, install, or at least train on using, and that's often time that projects can't afford, but there can be huge benefits to Developer Experience if you build or find debuggers specific to your abstractions, especially in places like functional programming pipelines. (As some easy examples, I've worked with the Redux Dev Tools a few times and getting a "redux-eye view" of an application's data state is sometimes incredibly more useful than trying to add a bunch of console.logs into all your actions and reducers manually. Similarly, I've become a big proponent lately of using RxJS-Spy for RxJS work: it adds a single operator `tag('pipeline-name')` that is a no-op in Production builds and then gives you a great Dev-time API for observing [or debugger breaking] specific pipelines or pipelines filtered by regex of name, all without manually adding or removing `tap` and `console.log` in those same pipelines.) We don't always have to stick to lowest common denominator debug tools. We don't still need to make sure that we can pipe to our dev terminal over serial port to get our debugging done or log everything to plaintext files that are hard to manage. I think sometimes people forget that. Similarly, I do find a responsibility that if I write code that is best debugged with higher level tools, that I make sure to document those tools, and try my best to train people on them as they ask.

minimaul 4y ago

I really like this concept! It's something I regularly say to our juniors - if you have two ways to do something and one is much easier to debug later, it's probably a better choice. It's a nice extension of not writing unnecessarily overcomplicated code and keeping things readable.

bern4444 4y ago
Thank you! It’s easy to fall into this habit especially with chained methods where it looks so nice. I have to remind myself of this concept often as it’s just so easy to do things quick and dirty
PointyFluff 4y ago
Past Barry writes comments to Future Barry, so Future Barry knows what the fuck is going on and doesn't have to try and figure out the spaghetti-code Past Barry apishly bludgeoned into the keyboard with his penis-tipped meat-stumps. Both Barry's think the other is an insufferable asshole.
fragmede 4y ago
Kernighan's lever: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

WorldMaker 4y ago

From a slightly different perspective, and not entirely disagreeing with you but moving into a related discussion: as an industry we sometimes forget that we can build higher level debuggers just like we build any other higher-level abstractions. If the question is "how do we insert a console.log here?" (or a logging.log() to a file on disk. Or RS232 null modem command sequence plus log ASCII. Depending on the app and era) it's sometimes fine to say that question is too low level on specific output format and that we should be reaching for higher-level debuggers. I understand the problems that higher level debuggers take time for someone to build, install, or at least train on using, and that's often time that projects can't afford, but there can be huge benefits to Developer Experience if you build or find debuggers specific to your abstractions, especially in places like functional programming pipelines. (As some easy examples, I've worked with the Redux Dev Tools a few times and getting a "redux-eye view" of an application's data state is sometimes incredibly more useful than trying to add a bunch of console.logs into all your actions and reducers manually. Similarly, I've become a big proponent lately of using RxJS-Spy for RxJS work: it adds a single operator `tag('pipeline-name')` that is a no-op in Production builds and then gives you a great Dev-time API for observing [or debugger breaking] specific pipelines or pipelines filtered by regex of name, all without manually adding or removing `tap` and `console.log` in those same pipelines.) We don't always have to stick to lowest common denominator debug tools. We don't still need to make sure that we can pipe to our dev terminal over serial port to get our debugging done or log everything to plaintext files that are hard to manage. I think sometimes people forget that. Similarly, I do find a responsibility that if I write code that is best debugged with higher level tools, that I make sure to document those tools, and try my best to train people on them as they ask.