We’re Not Paid to Code
Close to the Metal
I had a conversation with a friend on how Cucumber can be used for testing.
His contention was, it’s more a novelty than anything. So what if your customers or other people can read what the test is doing? It’s not worth spending that time doing that.
My response was: I’d agree, if that were all it were for. But it’s not–it actually helps you by abstracting away the test code so you can focus more on getting the test written quicker, in a way you can understand.
His response was: But I want to get my hands on the code itself. I don’t want to have all that stuff hidden away somewhere, it just feels so… detached.
To which I said: We’re paid to solve problems, not to code.
We Are Problem Solvers
Developers solve problems using code. But you will never find a job description for a dev to come in and just write code. There’s always some kind of business need–somebody needs something, and code is the means to that end.
Test automators also solve problems using code. The problem in this case is we need software that tests software.
But there’s no rule that says you have to be writing a lot of code, in order to do it.
Value Add vs. Lines of Code
A good way to gauge how well you’re doing the job is asking: how much value am I adding?
Here’s a good example: Let’s say you have two people that do test automation.
One person writes the automation directly, in whatever native language is used. The other uses a tool to help abstract away most of the code.
The value add of the second person comes from:
- how fast the automation can be written
- how easy it is to understand
- how much the “Truck Factor” increases
- how easy the automation is to debug, refactor or extend
Mo’ MLOC, Mo’ Problems
There are a couple tenets I live by in this field: Every line of code has to be maintained and Every line of code increases the surface area
There’s still a stigma against test automation code in places. It’s treated like second-class code.
But it’s not. Code is code regardless of who’s writing it.
As such, the same standards apply to it.
Every line of code has to be maintained means, every line of code will eventually have to be touched, debugged, refactored, read and eventually phased out. The more you have of it, the longer it will take to do each of these steps.
Every line of code increases the surface area too. The more code you have, the higher the likelihood of there being a bug somewhere. This is particularly painful when the test automation code itself is where the bug lives.
Businesses care about either making or saving money. Code costs money. The more you have, the more it costs.
Get Off My Lawn, Kid
Maybe I’ve just mellowed out over the years.
No I take that back. Not maybe. I have for sure mellowed out.
I’ve been where my friend is. It’s cool to make a computer do what you want it to do. It’s also a great feeling to scratch an itch with a slick algorithm. It tickles.
And I can think back on projects I’ve worked, and remember what kind of code I wrote, to just bang out a solution, not caring how many lines (or how readable) the code was.
I kinda hope they’re not still using my code at the first tech job I had.
But I’ve been doing this for almost 10 years. And in that time I’ve learned: in business, it’s more important to solve the problem as simply as possible.
It’s a huge mental shift to learn that not all solutions require code, but it’s a learnable thing.
Sometimes you can just talk with people. Sometimes there’s already something written. Sometimes a small amount of code can do the heavy lifting for you.
Very rarely does it require a ton of code to solve a problem–and I would posit that, if your solution does require that much code, the problem hasn’t been broken into small enough pieces.