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. ¯\_(ツ)_/¯

What's proprietary in it? It follows ISO 8601-1:2019 and RFC 3339 according to the docs.

- 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.

Just my 2c - hope it can be helpful to someone.

Could you elaborate why this would be the case?

For me personally, when I had a lot less experience the attraction was mostly a feeling of accomplishment and satisfaction that I could make a machine do exactly what I envisioned in my mind. As I accumulated more and more professional experience, the source of my satisfaction became increasingly distant from the actual code itself, e.g. analyzing a business need and identifying a technical solution that met it became more satisfying than writing the actual code itself. 10+ years down the line now and in my current role I very rarely write any production code. To the extent that I miss it, it's probably mostly down to nostalgia. I typically get more satisfaction from working with strategic technical problems, enabling developers, doing high-level designs, liaising between tech and other departments, etc.

So TL;DR - yes, it's perfectly normal to find non-coding software development activities more gratifying :)