sauceop

5 ms·

1.
by sauceop 7y ago
I feel like a lot of semver purists have never maintained software with a lot of downstream dependencies. The gray area about what is a breaking change is huge and it's hard to usefully improve software without making changes that are
2.
by sauceop 8y ago
Agreed, I think the issues you're touching on are fundamentally difficult problems that don't have a single solution. For example. * storing complex data and supporting multiple access patterns efficiently (like joins) is hard and
3.
by sauceop 8y ago
The open source projects that are most threatened like this are the more complex infrastructure software that doesn't naturally get build as a side-effect of other work. If you look at a company like Red Hat, they're focused on bu
4.
by sauceop 8y ago
If you're running IT for a major corporation and you have an issue with your OS that prevents your business from operating, what do you do? Hope that your IT team figures out an issue they've never seen before in code they have no
5.
by sauceop 8y ago
It's a free-rider problem - if large cloud companies fork every successful open source infrastructure project, don't contribute back, and pull away a significant chunk of users, then there's a lot less incentive for other com
6.
by sauceop 8y ago
It depends on how important you think it is to optimize for future readers or maintainers of the code. I weigh that pretty heavily and a do think relatively minor style issues impose a tax once they're pervasive in a codebase. Tooling
7.
by sauceop 8y ago
We had a senior engineer (who sadly moved on to a different company) periodically give a talk to new hires about good code review practices to set expectations and ground rules. Some of the key points: * Authors are expected optimize for re
8.
by sauceop 8y ago
I don't have your context, but if the changelist author is writing multithreaded code where there's no way that a reader can convince themselves of the correctness, then my heuristic is that the burden is on the author to improve
9.
by sauceop 8y ago
Consistency of code style does matter, up to a point, to people reading and understanding the code. As you suggest, setting up ground rules and tooling helps Code authors who don't see the value in consistency of code are potentially a
10.
by sauceop 8y ago
The approach that I've seen work is to have high standards for code, but communicate the expectations upfront and make sure that code reviews are grounded in those standards (for new people, this means over-communicating, but it become
11.
by sauceop 8y ago
Speaking as someone who makes a living contributing to open source, it's a frustrating trend that the major cloud providers (Amazon being the worst offender) have decided that it's in their interests to take open source projects a