Oh absolutely, I would welcome some way of sponsoring such projects in general. I just meant to highlight that for this particular feature and project, there is already a form of sponsorship happening.
When it comes to Wine, aren't they already doing this? Steam develops Proton in cooperation with CodeWeavers, who are the main sponsors of Wine, and parts of that work is upstreamed to the Wine project. The NTSYNC patch from what I can tell was also submitted by a CodeWeavers employee, so it doesn't seem far-fetched to say that Steam probably contributed to making this happen in Wine.
That is an interesting argument. Do you believe that the same would apply to humans? I.e. if someone wishes to minimize the suffering of humans, is the logical conclusion that they should pursue omnicide?
FWIW the "Why?" page does a good job (IMHO) of what it is and what it's trying to achieve. Well-written, although perhaps not exactly concise. https://docs.endatabas.com/appendix/why.html
Oh that one - yeah I've always steered clear of DataContractJsonSerializer. Never understood why they did it so weird.
To be fair, RFC 3339 wasn't even published back when this class was implemented (in .NET 3.5) so I guess they just went with whatever worked for their needs. ¯\_(ツ)_/¯
This is just my very personal and subjective experience, which may or may not apply to your working environment since I've no idea how many developers or teams you have or how your responsibilities are defined. This is at least what I've learnt so far in my environment:
- Be transparent about your decisions, motivations and opinions. People will come to you for advice or suggestions for what to do, and if they don't understand your thought process that causes unnecessary friction.
- Document everything in writing publicly (except confidential/sensitive info, naturally) - decisions, designs, ideas, proof-of-concepts. This will be helpful both to your fellow engineers since they can access this information on their own without you having to explain it to them every time they ask, and also helpful to you to recall the context in which you did something. I find myself often going back to notes I wrote months or even weeks ago, to remind myself of e.g. the motivation for why a decision was taken. Having it public also forces you to write in a clear, structured and professional manner since you're writing for a broader audience.
- In terms of studying, formulate a vision for where you think your software should be within 1, 2 or 3 years, and spend time researching what options can take you there, learning how they work, and so on. I've found InfoQ to be a pretty good resource for keeping tabs on what others are doing in the field.
- Be patient. Be prepared to repeat yourself multiple times, sometimes to different people, sometimes to the same people. Be prepared to communicate a lot, and keep in mind to tailor your message depending on who you're communicating with.
- Learn to let go of details. You will see code and solutions pushed out that you perhaps don't fully agree with. Take a step back and consider if it's really that important or if it's good enough. If something gets pushed that really isn't up-to-par, be humble and consider that you might not have communicated the requirements clearly enough.
- Make sure to understand the business side of the company, and always take that perspective into account when making decisions. You might from a technical perspective think a piece of software is in desperate need of refactoring, but from a business value perspective it might not make any sense. Be sure that you agree yourself with those kinds of decisions (i.e. don't blame "the business") because you'll likely find yourself having to explain and champion them to others who disagree with them.
- I realized now that all of the above is mostly "soft skills" and have very little to do with technical skills or training. Which I suppose is the biggest learning I've had so far - for me the biggest gap by far was (and still is) mostly about communicating, working with others, and taking the broader needs of the company into account and not just the technical aspects.
Exactly this. Treat the DB schema as you would any typical API schema. A lot of the techniques used for evolving application APIs can be used for sprocs and views as well, e.g. versioning for breaking changes, adding optional parameters or new result fields for non-breaking changes. Fundamentally I don't think there's much difference between say, a DB schema defined with sprocs/view or an HTTP schema defined with OpenAPI. Both describe an API contract between two remotely communicating processes, the former case just happens to use a SQL dialect/transport to do it.
C# didn't either, it was introduced in C#/.NET 2.0. As I've understood it, Java chose type erasure to stay backwards compatible with older JDK versions, whereas .NET instead chose to break compatibility with 1.x and force dependents to target 2.0.