Sheeri dot com
The She-BA
Array
Syndicate
Sysadmins, Developers and DBAs
Nov
29
I think the briefest way to sum up the difference between a good developer mindset and a good sysadmin mindset is "a good developer thinks, 'how will this work?' and works accordingly. A good sysadmin thinks, 'how will this break?' and works accordingly."
Developers think in terms of "edge cases" and "off by 1" errors, which start from a default of things working. This is good as a design skill; developers need to think algorithmically, pondering a main way of something functioning and then dealing with anomalies.
However, sysadmins tend to install systems and maintain them with scripts, as opposed to building new software -- usually. Sysadmins deal with systems when anomalies happen, so they must have a mindset of "how will this break?" vis-a-vis -- "how will this break and how can I be notified of the breakage before my boss/the customers call?" which leads to "what if the notification system breaks?"
Now, a DBA leads a double life. In fact, DBA has come to mean "database professional". There are plenty of folks who use DBA when in fact they're great Database Programmers, who can code their way around any problem but haven't touched a config file and never have GRANTed anyone access. On the other end of the spectrum are folks like me, who fiddle with stored procedures but are great at administration.
I've always thought that "database professionals" bridged the gap between Systems and Development, almost by sheer need. I wonder if that's true for any "major application professional" such as an Apache/Tomcat/Resin/Jboss administrator.
What do you think about the different qualities of Sysadmins, DBAs and Developers?
Interesting thought,
Interesting thought, Jay!
Back when I was running my own Internet Marketing company, I wore all hats -- software developer, database architect, database admin, sysadmin. I was forced to learn how to optimize MySQL operationally as traffic pounded my sites. Got real imtimate with the my.cnf file, replication, and all sorts of other details that I "never needed to know" as a pure developer.
Ironically, I am currently learning how to be an Oracle DBA. But my role there will be quite limited -- merely a "DBA", not a developer, as Oracle is required by a third-party tool we are using at my shop.
But on the MySQL side, I am doing it all -- schema design, database administration, and sysadmin stuff. I am having to understand how the entire network constellation of servers interact with the application and how that interacts with the databases to diagnose site outages, site latency issues, and the like. It is quite complex, and quite a challenge. I am actually relying on my knowledge of complexity and queuing theory in my attempts to understand the network dynamics. Even though I am not solving equations per se, the understanding of the mathematics actually helps.
If you want to be a boring Oracle DBA, you have to work in a large bureaucratic establishment. There, you can rest in your pride that the Peter Principle can dominate your existence. But in a small shop, you really need to be more flexible and wear many hats; there is just no getting around that.
Also intriguing is that
Also intriguing is that Oracle DBAs tend to see themselves (IMHO) as more of a strict DBA than MySQL DBAs, who tend to come up through a developer mindset, get slammed with administration requests and must learn through trail and error...
It's rare you hear a MySQL DBA say "all I do is administer MySQL databases", whereas I think there is an inherent pride within the Oracle DBA camp that they are strictly Oracle DBAs...
Just a thought,
Jay
Nail, meet Hammer. I was
Nail, meet Hammer.
I was waxing poetic on this very topic the other day with a co-worker. Our developers are pushing to implement certain functionality across our customer base. I keep shooting them down by asking simple questions like "Does it conform to these standards?", "How do we monitor for success and failure?" and "What happens when...?" to which they step back, scratch their heads and go back to their desks.
The same goes for DBAs. I know some developer DBAs who can write SQL and stored procedures in their sleep but forget their their local tnsnames.ora file was pointed to a production database when they ran the install script which starts out with a "DROP DATABASE foo;" statement. I can setup MySQL databases in less than 5 minutes, manage growth from 100 megs to 100 gigs without breaking a sweat...but I still have trouble writing JOINs.
There is a great divide between Administrator and Developer (systems and database.) We all cross each others boundaries from time to time and that's a good thing. The important thing to do is humble yourself when you cross over so you don't end up with foot-in-mouth disease.
I certainly agree that DBA
I certainly agree that DBA has become a much more flexible term than sysadmin... I'm labeled the DBA at my company, which puts me half on one side and half on the other. For one, I'm the developer people come to when they have MySQL programming questions (complex queries, weird errors, etc), plus I handle all the GRANTs and such. And largely that's what a small company needs. I'd hesitate to call myself a genuine administrator, though, largely because I'm not much as far as configuration goes. I tend to learn by necessity, and the fact is that none of our sites really get enough traffic to warrant delving into configuration and optimization that much when my time is more often spent on actual web application development. For me, DBA isn't really my job, it's just one more task tacked onto the stuff I already do.
That said, I've got the MySQL certification study guide and am slowly trudging through it, so maybe I'll land in the true administrator category one of these days.