I do feel confident as a multi year DBA to continue support the SQL Servers I develop SSIS Packages for. Still not an issue to set up Ola's Maintenance Scripts, configure the SQL Server properly and the likes however lately the customer would love if I - ontop of managing and developing for their SQL Servers - would be able to produce C# Code, too.
Yes it's part of SSIS but honestly: I can make SQL Servers fly but creating C# Code which aswell flies on SQL Server is a completely different story therefore I actively refuse to learn C#. It's not like I haven't told from the start right away "I don't do C# because I don't know" but in this case it is about debugging some crap to make it work as an ISV Alternative which on top was started years ago.
Uhm, no… really absolutely no thank you that would mean for this customer for instance I can't tell him anymore how fancy SQL Server 2019 Big Data Clusters might be within their own environment, C# brings it's own new features now and then, just around the corner is .Net Core 3.0 I've just recently read so if I do both I'll be at best mediocre in both things at some point in time which I don't want to end up personally because then you really are replaceable.
No I don't do OnCall rotations anymore which was a constant part of pure DBA roles but yeah I can make all your old SQL 2008 Code and packages not just run on SQL2017+ but aswell do the actual migration and setup of the new environment, no matter if it's a "simple" DB Engine only Installation or if it's part of an application with a multi-hop scenario, I can make it work from SQL Server (and IIS) perspective but knowing enough about Windows, SQL and Active Directory (and some minor Oracle querying, too) makes me enough of a one stop shop for "DB things".