3 ms·

mostly tests while doing implementation, but not 100%. however, I've started working on a project with others, and am becoming a bit more adamant on "this need

mostly tests while doing implementation, but not 100%. however, I've started working on a project with others, and am becoming a bit more adamant on "this needs tests". Codebase had none after a year, and the other dev(s) are far more focused on code appearance than functionality. Fluent interfaces, "cool" language features, "conventional commit" message structure, etc are all prized. Sample data and tests? None so far (up until I started last week). I've had push back on my initial contributions, and I keep saying "fine - I don't care how we actually do the code - change whatever I've done - just make sure the tests still run". All I've had is criticism of the code appearance, because it's not in keeping with the 'same style' as before. But... the 'style' before was not testable, so... there's this infinite loop thing going on.

hackerm0nkey 7y ago
yeah, that's the problem. If they don't get the value of what a test gives them, and then the focus shifts to aesthetics and conventions, etc... Personally when I review code, I look for the test, I need to find a way to tell me why that code exists and a proof that it works.
- lowercased 7y ago
  I had this issue with a different client about 6 months ago. I understand there are 'coding styles' that some companies stick with, and I'm not strictly opposed to them. I do bristle when I'm presented with the 'one true way' from devs who spend all their time on one project, or one tech stack, or one company. I jump around a lot, and multiple companies have "the one true way", and the conflict. Processes around commits, flow, commenting, etc - these vary more than some people would care to admit. In response to that, I've started to care and focus more on tests and sample data to illustrate the core issues, changes and value for an issue. You want to change the code from 4 lines in to 1 4-line chained fluent interface to match other bits of the code, or to try out your new builder syntax? I really really have grown to not care too much - as long as I have some tests to demonstrate when something stopped working (or when our understanding of the project changed).

hackerm0nkey 7y ago

yeah, that's the problem. If they don't get the value of what a test gives them, and then the focus shifts to aesthetics and conventions, etc... Personally when I review code, I look for the test, I need to find a way to tell me why that code exists and a proof that it works.

lowercased 7y ago
I had this issue with a different client about 6 months ago. I understand there are 'coding styles' that some companies stick with, and I'm not strictly opposed to them. I do bristle when I'm presented with the 'one true way' from devs who spend all their time on one project, or one tech stack, or one company. I jump around a lot, and multiple companies have "the one true way", and the conflict. Processes around commits, flow, commenting, etc - these vary more than some people would care to admit. In response to that, I've started to care and focus more on tests and sample data to illustrate the core issues, changes and value for an issue. You want to change the code from 4 lines in to 1 4-line chained fluent interface to match other bits of the code, or to try out your new builder syntax? I really really have grown to not care too much - as long as I have some tests to demonstrate when something stopped working (or when our understanding of the project changed).