4 ms·

>Is the code well-written? Read some of it. Does it look like the authors have been careful, conscientious, and consistent? Does it look like code you’d want to

>Is the code well-written? Read some of it. Does it look like the authors have been careful, conscientious, and consistent? Does it look like code you’d want to debug? You may need to. This, 10,000x. I've repeated a similar mantra many, many times, and it's one of the most important reasons I refuse to use proprietary software. You should consider no software a black box, and consider the software you chose to use carefully, because it's your responsibility to keep it in good working order.

bunderbunder 8y ago
Making it someone else's responsibility to keep it in good working order is the value proposition behind (good) proprietary software: You give them money, they give you a support contract. For a company with more money than development resources, or even just a company whose development resources can be more profitably focused elsewhere, this can be a quite reasonable trade to make.
- vharuck 8y ago
  If a company behind proprietary software goes belly up, there's no support. But there are always companies or even freelance devs who can be paid to support open source code.
  - IggleSniggle 8y ago
    Proprietary _and closed source_. We make use of open source (but not open license) proprietary software on my team.
taeric 8y ago
That said, realize that a lot of what people think is important when it comes to reviewing code is iffy, at best. Consider, git.[1] Odds are extremely high that this does not fit any style of most startups. Now, you could take that as an argument against many startup stylings, but that is not necessarily my intent here. To their credit, they have a very exhaustive coding guideline that is fairly open to breaking rules when need be.[2] [1] https://github.com/git/git/blob/master/wt-status.c https://github.com/git/git/blob/master/wt-status.c [2] https://github.com/git/git/blob/master/Documentation/CodingGuidelines https://github.com/git/git/blob/master/Documentation/CodingG...
- intertextuality 8y ago
  To be fair, have you ever had a problem with git that wasn't a pebkac error?
  - taeric 8y ago
    I believe we are echoing each other. That is, I am asserting most metrics people use for intrinsic quality of code would likely mark git as something they would not want to support. And yet it is proving to be very reliable.
ummonk 8y ago
That isn't an argument against proprietary software. It's an argument against software that doesn't provide its source.

bunderbunder 8y ago

Making it someone else's responsibility to keep it in good working order is the value proposition behind (good) proprietary software: You give them money, they give you a support contract. For a company with more money than development resources, or even just a company whose development resources can be more profitably focused elsewhere, this can be a quite reasonable trade to make.

vharuck 8y ago
If a company behind proprietary software goes belly up, there's no support. But there are always companies or even freelance devs who can be paid to support open source code.
- IggleSniggle 8y ago
  Proprietary _and closed source_. We make use of open source (but not open license) proprietary software on my team.

taeric 8y ago

That said, realize that a lot of what people think is important when it comes to reviewing code is iffy, at best. Consider, git.[1] Odds are extremely high that this does not fit any style of most startups. Now, you could take that as an argument against many startup stylings, but that is not necessarily my intent here. To their credit, they have a very exhaustive coding guideline that is fairly open to breaking rules when need be.[2] [1] https://github.com/git/git/blob/master/wt-status.c https://github.com/git/git/blob/master/wt-status.c [2] https://github.com/git/git/blob/master/Documentation/CodingGuidelines https://github.com/git/git/blob/master/Documentation/CodingG...

intertextuality 8y ago
To be fair, have you ever had a problem with git that wasn't a pebkac error?
- taeric 8y ago
  I believe we are echoing each other. That is, I am asserting most metrics people use for intrinsic quality of code would likely mark git as something they would not want to support. And yet it is proving to be very reliable.

ummonk 8y ago

That isn't an argument against proprietary software. It's an argument against software that doesn't provide its source.