loading...

re: The Curse of the IDE VIEW POST

FULL DISCUSSION
 

Some notes:

Semi-non-sequitur: It might also be worth noting from a team perspective that it's a good idea to not bind your project to a particular IDE. Rather, you should bind only to the build engine/compiler you're using. This allows people to use the IDE of their choice and avoid committing things like gitignore files, ide specific config, etc. This is how it works at Amazon, if anyone was wondering where I've encountered it in the wild.

Second note: print debugging, while ok and definitely a valid approach at times, is something I've come to recommend against due to a seeming inability of devs on my team to clean up their debug time instrumentation. In lieu of this, I encourage them to write unit tests to compartmentalize what they're analyzing and think through it completely. Even if the test is thrown away it allows for local symbolic debugging with simulated data and has the added bonus of requiring you to think through the process. It takes slightly more time on smaller projects at less sophisticated orgs that can be built and run locally, significantly less time in orgs with greater vertical integration in the build management system and organizationally managed dependencies that render local build and execution functionally impossible.

Thank you the article, I definitely have many points of agreement with your overall philosophy.

 

Shoot, I actually added some functionality into the print wrapper I wrote for my company's utility library, which allows certain messages to be flagged as "debug only". That way, when the "verbosity" is set to high, they'll print, but when its normal or below, the debug messages won't even be parsed!

But, yeah, leaving those in is definitely a valid problem. Still, a decent code review process should catch them.

code of conduct - report abuse