Nevertheless, Heidi Waterhouse Is Technical

I don’t code for work right now.

It’s important that you understand that.

I travel the country and the world talking to people about key concepts, best practices, new ways of moving forward. I’ve keynoted conferences. I’ve sat in enough technical talks that if they were college credits, I would have an extra couple degrees. I read dozens of articles and books about technical topics every month. I learn from, consult with, and teach technical people and coders every workday.

I don’t code.

Not-coding doesn’t make me less-than-technical. It doesn’t destroy my industry expertise in software development lifecycles, architectural choices, accessibility, human factors engineering, resilient organizations, devops, networking, or team dynamics.

My job as a developer advocate is to make sure that developers outside and inside my company are getting their messages through, are being heard and respected and transmitted. Emily Freeman calls herself a “human router”, and that seems like a good description. My personal variant of developer relations is about connecting, not creating.

When I interviewed for this job, I gave a presentation and had a pretty standard interview, and talked about my 20+ years of experience in software and later, one of the interviewers said, “I didn’t realize until we were done that she didn’t code.” He was a bit surprised, because I hadn’t struck him as non-technical.

I’m technical as all get-out. I’m not coding. Please, for the sake of all the other technical people you know, don’t assume coding is a perfect proxy. It’s not. Systems thinking doesn’t mean you need to build systems.

Coding is one way to be technical. We reward it pretty highly. We assume that it’s pretty much the hardest of the skills in technology. And people who can code assume that because it’s the hardest and because they can do it, they are the smartest/most important people in an organization.

I think that there are a lot of skills and jobs we need. We need empathy to build the right things, and design to build them to be usable. We need marketing to help explain why people should chose them and sales to help people understand what the business case is. We need HR to help us resolve the problems that inevitably arise when humans try to do things together, and to make sure our power imbalances are as humane as possible. We need technical writing to help people understand how something is supposed to work, and support for when it doesn’t work that way. We need QA, not just to write test scripts, but to understand the way things can break that are not as predictable. We need security to help us remember that it’s easier to design and build something correctly, rather than expeditiously. We need the office managers who deal with making sure we have all the stuff we need to do our job and also our office snacks. We need IT, because even if we code, that doesn’t mean we understand the intricacies of SSO, or want to spend hours sorting out bandwidth contracts. We need recruiters to make sure we have enough co-workers to meet our goals. We need management to help us sort out priorities and to know what’s happening in the world as well as our projects. We need boards to help steer a company and keep it from overcorrecting in any direction, and we need the money people to tell us what we have and what we can spend and to set reasonable limits on our investments.

Could a coder learn to do some or all of these tasks? Maybe. Some of them are pretty specialized and take years of work to learn, but it could be done. Does it make sense to have everyone try to be a specialist? Maybe not. Oh, sure, early on, we should all try to support a project however we can, but as an organization gets bigger, we get to specialize, go deeper instead of broader.

So when you talk about technology organizations, remember that everyone has a technical specialty, and it’s only sometimes code, but it’s all part of the whole.

I don’t code. Nevertheless, I am technical.