Developers – how much operations work are you doing?
DBAs – how much development do you do?
The Separation of Duties
For most of us, we stick to our assigned job role. Developers write code and then throw it over the wall for the ops team to put in place. If there’s a problem, there is inevitably finger pointing. Eventually a developer gets over to an operations person’s cube and the problem gets solved.
It’s rare that we see any cross disciplinary skill sharing.
In Origin of the Species, Darwin notes that the finches in the Galapagos have become very specialized, depending on the island where they were found. The finches were so specialized that Darwin originally miscategorized a subspecies of finch as a wren. He goes so far as to say:
Seeing this gradation and diversity of structure in one small, intimately related group of birds, one might really fancy that from an original paucity of birds in this archipelago, one species had been taken and modified for different ends
What Do Birds Have To Do With Work?
Darwin’s finches all had very different beak sizes and shapes – each finch’s beak had adapted to a different food source. Even though they’re all finches, they worked in very different environments.
What about you? How specialized are you?
I consider myself a developer – I’ve spent most of my career writing applications. Some of those applications focus largely on SQL Server. But I can also configure HA/DR solutions, set up hardware, and plan storage deployments.
One of the problems with overspecialization is that it becomes difficult to survive if your environment changes.
Avoid Overspecialization
I’m a big fan of mixing job roles. Developers should provide operational support for their features. Operations staff should take part in developing tools or even features for the application. Having a well-rounded set of skills makes it easier to survive when your environment changes.
14 Comments. Leave new
Truer words never spoken. The lack of unity can cause bad results.
Developers and DBA should work closely together during the entire application development life cycle. I’ve seen shops where resentful developers treat DBA as some sort of arrogant bureaucrats who pronounce picayune “rules from the mountaintop.” I’ve seen some DBAs who perfectly fit that description.
If DBA realizes that developers are trying to deliver a sound app, and developers realize that DBA can help them make the app perform optimally, and that database is the foundation of almost all business apps, perhaps the end result will be something that impresses the end users greatly, resulting on job security for both.
I agree as well. One barrier to this is often management’s wanting to increase separation of duties, citing SOXS as not giving one person too much power. I am a DBA with experience as a developer and one of my biggest issues is that the DBA team is not consulted until after a solution is deployed. I would love to integrate more with the development side and help in the design of solutions. I’m trying to bridge the gap.
So, specialization is for the birds…
Totally agreed – learning more about different roles never, ever makes you worse at your job. I actually go one step further than just rounded roles in technology, but I periodically have my DBAs and developers go over to our call center and jack in with the agents that actually take customer calls. They don’t handle any calls themselves, but it provides tow important things:
– The technical people get to see their products in action. There have been plenty of times where a developer is aware of an issue but just hasn’t put the time into fixing it because they haven’t seen the impact, or where it’s not even reported anymore because it’s so common, and the person in IT interprets this as “I guess it doesn’t occur anymore – case closed”. It’s amazing how much putting their users and actual told in front of them puts emphasis on what needs to change. We’ve also had some great features come out of those conversations and out of a better understanding of how the tools are used.
– If IT people don’t ever talk to the actual customer (the person who gives you money), they can begin to forget who their customer actually is. You might make neat tools and use new technologies or upgrade to new versions of your systems, but if you’re not solving a problem or making life tangibly easier for the person who pays the bill or the person who talks to them every day, you need to take a serious look at what you’re spending your time building. Make sure everything you do is in direct support of having a tangible impact on the customer’s experience.
I’ve always been an advocate of shadowing and cross-training as much as it’s possible – not just to make people flexible if the company changes, but because it leads to faster problem solving and better products.
Agree, as Developer I love programming applications that helps users to do easier, faster and better their work, but I’m a closeth DBA and for me is perfect to know both sides and is helpful.
I think DBAs and Developers must have knowledge about the other area, and must work together developing applications with the vision to do a helpful application with the best perfomance.
Also is good to say, specialization in only one technology is not good for DBA or Developer… just saying…
Bingo!!
In my present position I’m developer, DBA and deskside support all rolled into one. I come from many years of first-level help desk and field support. Users have a completely different perspective on software than developers or DBAs. Plus being able to see both the front end and back end of a solution provides invaluable insights I don’t think I would have gotten otherwise. I often look at something I’m creating and think, “Gee, if I change this table or procedure a bit and then tweak the front-end code here and here, I can get a much better solution.”
Many times it means I don’t use the latest gospel-according-to-some-blogger or OO design guru techniques or the latest cool framework from Microsoft. My end users really don’t give a flying hairy fig whether or not I use Repository Patterns, EF, Linq-to-SQL, DDD or anything else as long as they can get their work done in a reasonable time frame.
I see too much near-slavish devotion to faddish rules or ideas and not enough thoughtful evaluation of the strengths and weaknesses of varied approaches to solving a business problem and picking an appropriate solution.
I’ve been working as a DBA/SQL Developer for over 15 years. Only in my first 3 years of work was things separated. Then I moved to a smaller metro area with smaller companies. Since then, I’ve had to know working knowledge of almost all corners of IT so that the databases and servers stay up and running for my development work.
So in my experience, it’s a mix of whether you work for a huge company or a small company, mixed in with whether you work in a big metro that tends to have bigger companies or small metro, than tend to have smaller companies. Also let’s through in I’ve done a lot of development for Data Warehouse apps and the like. So maybe they through DW ppl in a corner and let us fend for ourselves, since most of the DW users are insiders (read cost center).
So while you say avoid specialization, I have would also say avoid being a jack of all trades… because now I have a fear of actually having to be specialized and not knowing if I could succeed in that environment. So I have to choose my job opportunities carefully to avoid someone who expects a DBA or someone who expects a developer.
Amen. Have you convinced Brent, yet? He always argued with me when I say the same thing.
Like most who read things like this, I’m a production DBA; however, I do a lot more than that. I pretty much own the Report Server and handle all the complex report writing for that. I’ve written a highly customized scheduling tool for it as well that avoids the mess of subscriptions and negates the need for Enterprise to have data driven descriptions. I own the database servers from the minute they arrive until the day they are put to sleep, so I install the OS, rack n stack ’em and even run my own cable. I’ve spent nearly twenty years dealing with complex apps in complex environments and that has given me a lot of good experience that really has value. I’m not much of a programmer, but I can usually read and understand what the code is doing and find a problem in it when asked. We are moving to the VM/SAN world and now I’m going through formal training for both. I think this last item is a real gift because this is where things are going and it will never look bad on a resume.
The biggest thing to keep an eye on in all of this is to do your best to avoid being a jack of all trades, but a master of none. When I solely focus on SQL Server Administration I retain knowledge like a sponge. The thing is, once you have things running smoothly you shouldn’t have to be neck-deep in that on a daily basis and that means there is time to do other things. As I spend more and more time on other things “memory pressure” purges what I knew in and out from my mental buffer to make way for what I’m doing now. Sometimes I have to go look up things I really should be able to recite on demand.
The Internet is full of experts and perfect people, but I’m not one of them. I struggle with trying to be good at everything. I rarely (can’t recall the last time) see anyone else admitting to this. It’s great to be able to do a lot of different things, but for me, there tends to be a price and the price is that something else will suffer. I guess it could be said that the upside to being able to do different things is that it is better than being a one trick pony.
I’m a huge fan of what i’ve heard called “T-shaped people” – you have a broad, but shallow, knowledge base and you dive deeply into one or two areas. This kind of specialization with a solid understand of other knowledge areas seems to work well in many other industries. Even though I mainly do SQL Server performance tuning work, I know enough about many different technologies to have a conversation with practitioners and translate SQL Server terms into someone else’s world.
Unfortunately the industry loves putting people in boxes. Developer/DBA/scripter/Engineer/team leader is a pretty hard sell in the jobs market.
You are expected to be some kind of specialist that recruiters can hang a label on.
Which sucks…
We’ve always been huge fans of building up personal networks. That way, when it’s time for a new job, you don’t have to rely on a recruiter putting you in a box and selling you to someone. You can just hit up your network and find the right job for your growth path.
I have funny feelings about this.
I feel a little multi disciplinary because I went from computer tech to sales to help desk to report writer to SQL developer to SQL admin.
But I often have to look at looking at new and interesting topics from the perspective of, “Is this going to provide me value than focusing on a deep dive in something directly related to being a DBA?” Because SQL is where I’m planning to stay.
I think it comes down to a little like reading. We can read non fiction all day but the real benefits come when you take time to unwind with a completely unrelated fiction book.
I agree – it’s all about what’s relevant to your job and your future career path. Being unaware of what the dev team is doing, or in capable of effectively communicating with them, certainly sounds like it could be problematic for the job, though.