What does it mean to be “technical”?
When I’m interviewing for a job, I draw a distinction between “technical” and “code-y”. Code-y means that you can read and write a coding language that counts as “real” to the interviewer. (No one is impressed by your grasp of HTML, but they won’t say why it doesn’t count.)
When an interviewer says “technical”, they are usually shorthanding “code-y”.
I think that’s a limited view of what “technical” could mean in different contexts. You can be a perfectly effective sysadmin by knowing a lot of networking and installation, and maybe a bit of Powershell. You can be soaked in the minutia and theory of AuthN and AuthZ without writing code about it. You can administer hugely complex knowledge management systems using GUI. You can understand the constraints of developers, the theory of team topologies, and the progression of the software development lifecycle, but you may not be “technical” in the way interviewers are looking for.
Employers get to want what they want. It’s no good arguing about whether it’s the right thing.
But I want you to remember that you can be technical without coding.
- I don’t code, but I can explain the difference between committing on trunk and committing in branches and what that does to your workflows and risk profiles.
- I don’t code, but I understand the difference between RBAC and just-in-time security provisioning, and why you might want both or neither.
- I don’t code, but I can ask questions about the technical problem your solving, how that applies to a business problem, and then teach people to make those points over and over again.
- Also, I’ve forgotten more about using specialized text layout tools than Markdown has dreamt of.
I’m not upset when employers decide they want someone who can build demos and fix bugs and do all the other things as well. That’s what they think their job opening is shaped like. I recently saw job listing for a technical writer who could read and write two modern programming languages. Ok! I prefer it when people are up front about what they want.
I’m upset because conflating code-y and technical means that a lot of technical people who could do the job really well are filtered out based on a lazy habit of thought.
So what should you do?
If you’re a technical person, own that, even if you don’t code. Don’t apologize for not having that specific skill when you have so many others.
If you’re hiring, ask yourself what you actually need in a position, and why. What is the value of a college degree, or a coding test, or a writing test? Is it relevant to how the job will actually go day-to-day?
Software, as an industry, is lazy. That mostly works in our favor. We create automation and tools to take shortcuts for us. We try to make the machines do as much work as we can, and we reuse everything possible rather than rewriting it. But sometimes we fall into the habit of “best practices” without thinking about what that means in our context.