This T-SQL Tuesday, hosted by Argenis Fernandez (Blog|Twitter) is devoted to the question, “Are you a Jack-of-all-Trades? Or a specialist?” This question really hits home for me, on a number of levels.
(Aside: I have huge respect for Argenis – he’s smart, funny, no-nonsense, very accomplished. If you don’t follow him, do.)
If you have read any of my previous ramblings on this blog, you may know I was originally educated as an architect – the bricks and mortar kind, not the information systems kind. While I didn’t stay in that profession, I’m afraid it had a permanent influence on the way that I am wired. Architecture, especially architectural education, is grounded in a particular way of thinking about the intersection of design and engineering, which sticks with me.
A building is a problem with an unimaginable number of variables. There are so many that, for one building program (that’s the problem statement about what the building is supposed to be for, and how big, etc.) on one site, there is probably an infinite number of really good solutions. There are variations on structure, light, materials, function, climate, culture, history, on and on. A very good architect can make a building that works, keeps the rain out, and lasts, but at the same time is also inspiring, creative, and enriches the lives of the people who use it.
Contrary to popular belief, architects don’t do a lot of math. They don’t do the calculations for structural engineering, for example. In fact, in most places they are prohibited from doing it because they aren’t qualified. The skill that I think an insightful architect has is not engineering, but synthesis. From all the intertwined systems that make a building, structural systems, enclosure systems, mechanical and electrical systems, patterns of use, cultural influences, colors, natural light, the landscape, the architect can, through design, form a building into something that reveals and expresses those systems in a way that is not only functional but beautiful at the same time.
In order to do that, the architect does need to genuinely understand how those systems work, their internal logic, but perhaps in a different way than an engineer understands them. The architect has to “zoom out,” to understand how each system works at a macro level, and how it relates to all the other competing systems, interests and priorities that compose the larger problem of making the building. The architect’s understanding has to be accurate, without necessarily being microscopic in detail. The micro-level answers are available when you need them, by hiring someone or by doing research -- and the world is just too large and complicated to literally know it all.
Put another way: the hack architect either willfully stuffs a building into some predetermined form, or is ignorant or uncaring about making something, and settles for cheap, expedient corner-cutting. The skilled architect can synthesize the functions of the building, the site and the building’s construction into something elegant and beautiful, by understanding something about how each of those things work.
So, what has all this got to do with the topic at hand? I would like, in my small way, to work in IT the way the serious architect designs buildings. It’s interesting to think about whether or not working that way is a specialty – and I don’t really have an answer. But I have found that zooming out, taking an interest in related systems, helps me tremendously as a DBA. Sometimes it’s not the micro details of other systems that matter, but spending the time “getting” the logic of other systems, languages, interfaces.
Example: Windows, Storage, Failover Clusters. To me it just seems natural to want to know more about the systems that my SQL Servers are running on. I’m not a very experienced Windows guy, and when I go and see the good ones present, I am humbled and amazed. But I have certainly tried to get some macro-level understanding of these other systems as a way to get better at my own job, and I’ve learned how to build things like failover clusters ground-up.
That brings me back to the title of this post. “Not my job” is actually an interesting and nuanced concept. On the one hand, there are a lot of things I really don’t know about, and many I know barely enough about to be dangerous. I came late to this profession and I’m still a novice. I think it’s important to recognize that fact, in the same way the architect needs the engineer, and not create havoc imagining that I know more than I do. In short, I need other people who really know things. That’s the positive version of “not my job.”
Of course, there’s the other interpretation, where “not my job” is really code for “I can’t be bothered,” or, “that’s not interesting.” That attitude I don’t get. There is very little in this world that is not interesting in some way. Architects tend to be interested in everything.
I will leave you with two of my favorite buildings in the world, and a thought: these are made of the same steel, stone, wood and concrete as other buildings – what is it that makes them so amazing?
Have a look at Louis Kahn’s iconic Salk Institute and Kimbell Art Museum