[ad_1]
Zoe Landon describes herself as a front-end web developer, entrepreneur, and general oddball. When she’s not doing design and research for Marketo, she works on the music discovery project RCRDList, plays drums, and writes stories. Her first novel, The Latte Segment, was released in February. She knows a little something about words, which is the subject of her OSCON talk: Technology: so easy your lawyer can do it.
I asked her about it.
Computers process rules. Lawyers process rules. Why do lawyers have such a hard time with computers?
Lawyers aren’t computers, for one.
The trope of the technophobic lawyer is a strange one, but it makes sense when you consider the depth of a lawyer’s work. Between research, memorization, specialized language, and argumentation, lawyers bear a massive cognitive load. (Doctors have a similar situation, and from having worked at a company in the medical space, doctors do have a degree of technical resistance as well.) When technology is expressed solely or primarily through jargon instead of familiar language or metaphor, it’s treating tech as a separate idea that requires distinct learning. Many people who may be valuable contributors to tech projects lack either the interest or cognitive room to deal with that, so it creates a wall that doesn’t need to exist. Consider the efforts to make EULAs and copyright agreements more human-readable; doing the same for technology would reap similar benefits.
(As a note: more and more lawyers are replacing low-tech tools with computers like iPads, a form factor and OS designed top to bottom for ease of understanding.)
How do you convince someone that using jargon unnecessarily doesn’t automatically make one superior?
It’s always a matter of reading the person. For some, using jargon to feel superior is a feature, not a bug. That’s a hazardous attitude, but you’ll always find someone like that. For the rest of us, I feel that being made to experience the problem is a good way to create an understanding of it. In my case, I’m an author, so I’ve sought out literary and linguistic jargon that most programmers haven’t. So, if I need to illustrate the point, I’ll start throwing that around. It’s not a bad thing if developers don’t understand linguistic jargon—you don’t need it to be successful—but once someone finds themselves in the position where they’ve lost understanding due to jargon, it’s much easier to step back and highlight the problem.
Why is it important to you that technology be approachable?
It’s important for everyone. There’s been plenty of evidence that heterogeneous dev teams and companies perform better, so there’s a business case there. The generally accepted reason is that a diversity of viewpoints helps to catch problems and shortcomings before they happen. With open source projects, as they grow, they run the same risk of problems caused by narrow viewpoints. They become more complex, and thus harder to explain. So, they’re open to the same improvements.
Forcing yourself to step back and explain a project in the most approachable terms possible can highlight points where you either contradict yourself or made something needlessly complex. It makes sure you have enough understanding of your own work. Jargon can be useful—you do, eventually, need to be specific most of the time—but it can obfuscate as well.
If attendees only take one thing from your talk, what do you want it to be?
I want developers to be more aware of language. It’s really easy to fall into that trap of assuming what’s familiar for you is familiar for everyone, and of course that’s not the case. That amount of self-awareness isn’t much, but it makes developers much stronger collaborators.
Which OSCON talks are you looking forward to the most?
I’m looking forward to I am your user. Why do you hate me?. For one, I’m always up for a good rant, but it also focuses on user-friendliness and user experience. I feel like that’s a vital competency set for developers, so I want to hear more ideas on the subject so I can work on bettering myself there whenever I can.
[ad_2]
Source link