I had the privilege, once again, to attend An Event Apart in Boston this year. It's a phenomenal conference. If you're at all interested in the web and/or making things for the web, I can't recommend it enough.
It tends to leave me with a revitalized sense of inspiration, as well as provide a great time for self-reflection while helping me to realign my perspectives and priorities.
The point that was made
One of the things that stood out to me was a presenter who said (paraphrased):
Knowledge of the technologies is taken for granted
I can't recall, with certainty, who said this. I think it was Dan Mall.
At any rate, what he was talking about, in context, was that what differentiates web designers and developers from one another is no longer knowing how to program in different languages or hack browsers to pieces; that the "web guru" was no longer a thing.
In other words, the hypothetical scenario goes like this: you're at a job interview explaining your potential value and it no longer matters how many technologies you can claim proficiency in. It's already assumed by the employer that you can pretty much work in any technology that you're presented with and that you'll be bringing some new ones to the table. Instead, the employer is interested in how you have used technology to solve actual problems.
My initial reaction to this was YES!!
Finally! In many ways, my entire professional career has can be characterized by "flexibility with technology". I'm always trying to learn new stuff, in order to have more and better tools in my toolbox when I come across an actual problem to solve. Furthermore, I tend to work in such a way that I never even discuss the technologies being used when speaking with stakeholders (I don't really like the term "stakeholders" here... I just couldn't come up with a better one).
In summary, I'm typically very end-product focused; what problem needs to be solved and what end product will solve that problem. The rest of it is just details. Important details - to me - but details nonetheless.
After bringing to a boil, simmer for 10 Minutes
Sometimes, all it takes is someone telling me my own opinion to make me disagree with it. I wouldn't go that far in this case. I think end-product focus is still the right mindset to have. However, it makes me think a little deeper about the actual lineup of events here. Does it really not matter whether a designer/developer knows a particular technology or set of technologies? Is it really the case that employers should be given the leeway to expect a wide breadth of technologies/methodologies/perspectives be in the toolbelt of any given employee?
After further consideration, it seems to me that the technology used in developing web projects is the fastest evolving part of working on the web - and therefore the most difficult to keep up with. Consider some of the basic components of a website. Writing/copywriting changes a little here and there but generally evolves much more slowly, as it is part of overall culture and language. Good design is supposedly "timeless" (and I agree, particularly excluding aesthetic treatments) and therefore should by design be slower to change. Backbone technologies like servers and networks? Sure, there are upgrades but what's really the new "web server"? nginx? that goes back several years. And, I'm using the same router I bought from Verizon 10 years ago to power my home network.
How many new frontend web development frameworks have been released in the last week?
Consider responsive web design. The idea that "content should be accessibly anywhere by anyone" (the underlying principle that drives responsive design) is a globally acceptable idea - and not a new one. The text and images being displayed on responsive sites? Generally the "same" writing and pictures that have been displayed on the web since the 90's.
What's the actual new piece of responsive web design? It's the developmental technologies that make it possible.
Machiavelli would be proud
Faced with this disparity, I ended up arriving at the same conclusion as Dan but getting there differently. I don't think it's that employers, clients, and the like consciously believe that their team members should all be well versed in all the new technology. Instead, I think they (a) simply don't understand how much there is really being released on a daily basis and (b) aren't equipped to understand what the various pieces mean. At that point, it's kind of like fearing the unknown - except it's not actually known that it's unknown.
If you can't describe a problem to someone, you really can't ask him or her to care about it. It's therefore somewhat reasonable that designers and developers simply be assumed to understand the rapidly changing technologies and to converse solely about the "business problems" (these are scare quotes). It's actually a form of trust.
It's a lot like the car you drive or the medicine you take. You assume someone, somewhere, has empathized with your "business problem", even if you are utterly unequipped to understand how they fixed it.
So no, I didn't end up changing my opinion here. Still very end-product focused. Still inclined to believe that we (designers and developers) need to know how to do lots of different things, even if those we are beholden to don't know we know those things or don't know we need to know those things.
I think I've just arrived at a place of slightly more empathy for people who assume away the learning of technology.
One more thing
All of this is also to make one very important point.
Every once in a great while, you will be faced with a situation where the person you are speaking with can have the technology explained to him or her. He or she is equipped to understand what the hell you are talking about, if you take the time to explain it.
Just because, generally speaking, people don't understand the technology, doesn't mean that all people exist at either one end of the spectrum (techie) or the other (non-techie). It's a continuum.
Sometimes, you will be able to explain the technology. The challenges. The small victories. At those times, do so.