June 8, 2015 at 7:57 am
Vanessa.Grimes (6/8/2015)
@Grasshopper "Developers are knowledgeable about narrow topics. They think in tiny bits and move from bit to bit in the process of creating software." That's a bit condescending don't you think? There is no need to denigrate an entire group of people to show how much better DBAs are. If we are to take a lesson from Phil's discussion, it is that there are multiple areas of expertise that should be working together, and no one group is better than all the rest, because it takes all the groups: development, DBAs, server admins, security & network experts, etc, to make a viable product.As a developer who has done a stint as a DBA for a couple years, I've learned that you can't be everywhere at once, and that a truly good developer has a wide scope and can see the big picture while also recognizing their own limitations. I am definitely better suited to being a developer myself, and while I may be great at designing relational tables, writing complex queries and analysis cubes, I work ~with~ our DBAs by getting their input on my design ideas, and relying on their expertise in storage and performance tuning. If all developers only thought in tiny bits, all software would be cr*p. Good software comes from developers that do have a wider skill-set, do think long-term, and do recognize the functional boundaries of their abilities and work with other teams to bring an idea to fruition.
-VG
Well said. THAT's absolutely the key. That's why I sit right in the middle of the Developers. We're a team and help flows easily and quickly in both directions. And I agree... the Developers that I work with know much more that "tiny bits". To be honest, they many times seem to have as good handle on the big picture as some of the managers.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2015 at 2:34 pm
There will always be a need for people who are deep subject matter experts in critical systems, whether database, network, etc. That said. We need to spend less time being defensive about our jobs and more time understanding why DevOps people think they can take over and do better. In many cases it's because they can. Most database teams are hopelessly behind the curve in terms of automation, manually configuring each individual box. No CI/CD. Etc. Meanwhile DBAAS technologies are improving by leaps and bounds and are able to handle an ever larger slice of the use cases out there with less administrative overhead than traditional standalone RDBMS. If you want to preserve a role for centralized database management in your organization, then you need to do everything you can to make sure you are seen as a resource, not a barrier by the dev teams. The DevOps guys have nice toys. Steal them.
June 8, 2015 at 3:28 pm
Jeff Moden (6/7/2015)
The best communication methods and systems in the world are totally useless unless a company adopts a development and maintenance policy that few companies seem to implement and can be summarized in just one word... Discipline.There have to be correct and adequate company standards and then everyone in the company must follow them in a disciplined manner or they simply won't work.
So much this, it's amazing how hard it is to convince some developers they need to do basic things like migrate from dev to test(and then actually test it there) then to production despite how many times things have broken when they don't.
June 9, 2015 at 2:48 am
Vanessa.Grimes (6/8/2015)
@Grasshopper "Developers are knowledgeable about narrow topics. They think in tiny bits and move from bit to bit in the process of creating software." That's a bit condescending don't you think? There is no need to denigrate an entire group of people to show how much better DBAs are. If we are to take a lesson from Phil's discussion, it is that there are multiple areas of expertise that should be working together, and no one group is better than all the rest, because it takes all the groups: development, DBAs, server admins, security & network experts, etc, to make a viable product.As a developer who has done a stint as a DBA for a couple years, I've learned that you can't be everywhere at once, and that a truly good developer has a wide scope and can see the big picture while also recognizing their own limitations. I am definitely better suited to being a developer myself, and while I may be great at designing relational tables, writing complex queries and analysis cubes, I work ~with~ our DBAs by getting their input on my design ideas, and relying on their expertise in storage and performance tuning. If all developers only thought in tiny bits, all software would be cr*p. Good software comes from developers that do have a wider skill-set, do think long-term, and do recognize the functional boundaries of their abilities and work with other teams to bring an idea to fruition.
-VG
This all the way.
June 9, 2015 at 6:40 am
For some reason I kept hearing "by the time a man thinks his father may have been right he has a son who thinks he's wrong".
Back in the 1980s I had a young (though older than me) and enthusiastic business manager proclaim that IT staff were going to be obsolete because any clued up business person could do all that was necessary on a PC.
The fastest way to learn what something does is to try and change it. Sometimes you just have to let them have their car crash.
June 9, 2015 at 8:35 am
David.Poole (6/9/2015)
For some reason I kept hearing "by the time a man thinks his father may have been right he has a son who thinks he's wrong".Back in the 1980s I had a young (though older than me) and enthusiastic business manager proclaim that IT staff were going to be obsolete because any clued up business person could do all that was necessary on a PC.
The fastest way to learn what something does is to try and change it. Sometimes you just have to let them have their car crash.
That's one of my favorite teaching methods for someone that has a hard time getting over themselves. "Give them the opportunity to fail". That should NEVER be confused with the backstabbing low-life method of setting someone up to fail. It means that if there's no danger to the data or the server, let them try their way and be there to kindly and thoughtfully pick them up and help them dust off when they fail. Yeah... it does sometimes take a fair bit of extra work that you might not have time for but I've made some rather powerful allies out of previous "enemies" that way. Most of the time, you only have to do it to someone once and most of the time, it's well worth it.
And, to be sure, it might be a lesson learned for me because they might be right. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 25, 2019 at 11:07 am
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".
September 25, 2019 at 12:00 pm
question - what is meant by 'Napoleonic idea'?
September 25, 2019 at 3:06 pm
The introduction of self serve online trading back in the late 90's changed the role of stock traders and personal financial advisers somewhat - but it didn't lead to their demise. The same goes for cloud hosted databases and the role of the DBA. It's becoming more about the data and less about the hardware, files, and backup tapes.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 26, 2019 at 3:49 pm
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.
This really resonates with my situation. Thank you for sharing this. I used to feel the same way and I still do to an extent. Sql and SAS were the two platforms I worked with happily for over 15 years. Then one day I had an idea to create a data model of a cooking recipe that could be used by different applications. After tinkering with Sql for a while it became apparent the whole challenge was in getting the applications built. When you look at the landscape from that perspective all the tooling and frameworks are going the other way. Meaning from C# code they treat Sql database as a "persistence layer" that's just an implementation detail. Until at least a few years ago Microsoft used to give lip service to something they called "Sql First". Not really anymore tho. Everything is "Code First" and their documentation always pushes the Entity Framework. Anyway, focusing on C# hasn't done much to modernize my Sql skills tho I'm doing my best to catch up. You mentioned a new version of .NET Core is coming out. That's really the best platform ever invented for running enterprise type application Sql. Hopefully we'll be in a position soon to open source some of the C# libraries and make it a lot easier to build api's based on Sql data models. In the end I learned C# to make better set based solutions. Did I end up mediocre in both? Well, there is no "end" coming soon hopefully and I only focused on a few narrow niches. For the most part the multi skilled developer is a myth because people have their preferences to how they go about things. Set and non-set based people are generally set in their ways.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
September 26, 2019 at 7:31 pm
I am a C# developer that creates web applications and Windows services that use SQL Server and DB2 databases. I can design database tables with PKs and FKs as part of the application design process; but I am not a DBA that maintains the servers, the backups, and the other database responsibilities.
I was contacted through my LinkedIn profile about an open position for a C# developer. However, based on the job description and requirements, they were looking for a "Jack of all Trades" person. They wanted a C# developer, DBA, networking guy, and sysadmin, for new development and also maintaining their servers, databases, and existing applications. I responded with a "No thanks." At other places where I've worked, including my current employer, the developers, DBAs, sysadmins, and networking are divided into separate areas of responsibility. We interact with each other, but each have their area of responsibility.
September 27, 2019 at 7:32 pm
@Phil Factor
I guess we both have much the same views about this, but express it differently. You seem to think that when I say you can combine several tems to make one team that I mean merge into one team with one shared management structure for the two groups of people, but what I actually mean is that you get communication working between the teams so that they can collaborate effectively - I've seen the horrors that can arise when the comms/networks team , the app programs development team, the database team, and the security team all have their own projects and don't really communicate with each other - it is inevitably a disaster. I've also seen the situation where those teams are actually merged to get for example developers and DBAs together in one team, but nothing is done to get them to really communicate with each other, and that too is inevitably a disaster. Stopping or preventing such idiocies was an important part of my jobs in the last 13 years before I sort of retired. The only way things will work right is to have teams that are specialised, not generalised, but also have communication between those teams operating so well that they deliver super performance because they collaborate properly with people in other teams with quite different skills. And it's rather difficult to have that when the apps development team's leader thinks DBAs are a waste of space, wants to forbid the use of stored procedures, and allow execution only of SQL queries whose text is constructed by c++ code written by people who don't believe injection can really happen so they don't check any input, and believe that their app code must always be allowed to run with administrator privilege, and the database server should only allow SA (no unprivileged users) and use of SA privilege must not require a password, and it's just as difficult if the database team leader has a matching set of anti-developer beliefs (and just plain impossible if each of the team leaders regards the other team as a waste of space and pushes that fiction onto their subordinates).
Tom
August 21, 2021 at 3:36 am
This was removed by the editor as SPAM
August 21, 2021 at 5:11 am
This was removed by the editor as SPAM
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply